That "new job" is picking up new legos. Looking at what problems there are to solve. Which legos would fit the best.
In that article, point about "Fire people. Just do it!" means, that if there is some part of business that does not generate enough profit or other success, those people need to be "fired" or they should find another job in same or other company, so that job would generate enough profit. If those people are not "fired", then company will get less profit or go bankcrupt.
That "new job" depends, what customers actually need the most. Customers could say "faster horse" but can not imagine "auto" or other most efficient, easiest to use solution.
Sometimes with those legos, it's about picking only most important in use legos, making them work together, and then making many groups of legos working together, and groups of groups, while each lego has a failsafe way to recover from possible error scenarios.
Sometimes it's looking at what some most advanced competitors are doing, and imagining what way it could be hugely improved and simplified. Even better, going in completely different direction with more advanced solution, and leading the way.
Point with legos is, to not be too emotional about changing legos, job contents, etc. If there is a way to solve something completely, automate oneself away from job, and move to bigger different role with more advanced legos, just do it. With more advanced legos, it's possible to solve bigger problems.
The irony with that view is that what looks from the outside as a single lego may be viewed from the inside as something much more complex, because we're not talking about actual legos here.
Yes. Maybe some more concrete examples would help:
1) I built one company infra. At first, I figured out what software, servers, etc there was, documented it, upgraded various software, migrated email, etc. I was fired for some nonsense reason, but anyway, we are still friends.
2) I was doing some coding at some another company. Coding did not progress well, so they fired me. Good, it's OK for me.
3) I built Open Source software for many years. Maintaining, merging pull requests, etc. Adding new features, dependencies, etc. When adding each feature, fixing corner cases, so it all works together, many parts are intendependent of each other. Now I'm thinking which dependencies are not deprecated yet, is it possible to figure out how to upgrade all dependencies and upgrade to newest version of web framework. Or should I just figure out how to take in-use code, figure out what newest dependencies there is available, and rebuild whole stack again.
In that article, point about "Fire people. Just do it!" means, that if there is some part of business that does not generate enough profit or other success, those people need to be "fired" or they should find another job in same or other company, so that job would generate enough profit. If those people are not "fired", then company will get less profit or go bankcrupt.
That "new job" depends, what customers actually need the most. Customers could say "faster horse" but can not imagine "auto" or other most efficient, easiest to use solution.
Sometimes with those legos, it's about picking only most important in use legos, making them work together, and then making many groups of legos working together, and groups of groups, while each lego has a failsafe way to recover from possible error scenarios.
Sometimes it's looking at what some most advanced competitors are doing, and imagining what way it could be hugely improved and simplified. Even better, going in completely different direction with more advanced solution, and leading the way.
Point with legos is, to not be too emotional about changing legos, job contents, etc. If there is a way to solve something completely, automate oneself away from job, and move to bigger different role with more advanced legos, just do it. With more advanced legos, it's possible to solve bigger problems.