About 5 years ago, I had a conversation with my CTO that amounted to this. He told me paraphrasing, "I'm a one trick pony. I take companies from this size to this size and when I'm done, I move on to the next. I'm very good at this and I'm happy doing it." Plus he made a lot of money doing so. I'd worked with him at two companies and it clicked that he had a playbook and he ran that playbook at each new company. He refined the art of going from this stage a to stage b.
I really took it to heart and changed what I thought about career progression. I'm probably a builder/scaler I def get bored in the maintenance phase.
Maintenance/optimization is an interesting stage: on one side, there you mostly need to execute by playbooks rather than be creative. Is it boring? On the other side, it is the stage where you need the most skill and expertise: you actually need to know all those playbooks, and standards, and regulations, and best practices, and war stories. There you stand on the shoulders of giants and establish connection between today and many centuries of others experience. You do need to innovate still, but that is now an intricate art of balance between not wrecking the ship and still being relevant. Is _that_ boring? I don’t know. I want to try it closer to my retirement.
> You do need to innovate still, but that is now an intricate art of balance between not wrecking the ship and still being relevant. Is _that_ boring? I don’t know. I want to try it closer to my retirement.
It's probably experience bias but the maintenance phase orgs I have worked for were more like warehouses that kept systems on shelves and let them rot until all the customers bled away. These were mostly growth by acquisition PE companies. It was like working at a fruit stand selling only rotten fruit. We were never given time, budget, or resources for even basic modernization. Everything was firefighting. One team after acquisition, lost their devops team, and let their pipelines degrade over 5 years to the point they couldn't deploy anymore. I've seen on-prem solutions deployed 20 times to a VM across 50 VM's and called cloud. It took a weekend for the team to deploy (10-15 people because support had to manually test every env because it was so fragile). They also tend to attract and retain talent that is done learning and growing. I had an Ops Engineer at one of these orgs tell me in 2023 that no one told them they had to learn Docker. They know what they know, and they push back on anything new which in turn drives away engineers that do want change. Everyone knows it's broken but no one will commit any resources to fixing it. The business doesn't care as long as they are retaining.
It's minefield and even when they talk about how committed they are to change during the interview you walk into fortified silos and no support or budget to break the deadlock.
>you actually need to know all those playbooks, and standards, and regulations, and best practices, and war stories.
The way I see it is these companies need it, but it is impossible to satiate that need, so they must find the next best thing.
If you have a project with 500 individual contributors or even just 50, it is impossible for one person, even geniuses, to understand and comprehend the whole. It is also impossible to staff all those positions with top talent at scale.
Raw talent and engineering is replaced with heuristics and policies and red tape.
It becomes like sailors operating a ship made with forgotten technology. They each have superstitions and operational knowledge about their little part, but nobody has the ship schematics.
Similarly, there probably isn't single person on the planet that could fully explain how a modern computer works in detail.
>If you have a project with 500 individual contributors or even just 50, it is impossible for one person, even geniuses, to understand and comprehend the whole.
It is impossible to know every detail, but it is certainly possible to understand and comprehend it. The ability to zoom out and zoom in is essential for senior leadership (even if some people appear unfit based on this criteria). Of course it works only if your organization is… ehm… organized and doesn’t look like a bunch of unicorns of all sorts and colors, so that you can extrapolate the methods of work of one team to another.
> Similarly, there probably isn't single person on the planet that could fully explain how a modern computer works in detail.
This will be the downfall of modern society. When nobody remains who understands all the tech we rely on it's only a matter of time before the whole house of cards comes down.
What's fneascinating is that build -> scale -> maintain is a similar lifecycle to a human: create and pivot quickly with fluid intelligence and high energy at first, then settle into your lane and grow, and then use your accumulated domain-specific knowledge and wisdom that no one else has, at a slower pace.
But the progression is not necessarily the same time scale for the product and the person. Maybe it was in the past, before computing.
Clearly this basic idea crops up in numerous forms. Part of the point of this specific scheme is that it is circular: once a given thing has reached the town planner stage, it has become some combination of pervasive and dependable and well-understood, ready to be used as one of the foundations for future exploration.
I've been a builder for a lot of my life but the last 10 years I've worked as an optimizer. The interesting thing about that is the work and playbook I used in the past is more of just a standard industry practice now. I used to do an audit and find a ton of low-hanging fruit and go from there. Nowadays, there's a lot less to correct and I have to think in different ways to provide true value.
I really took it to heart and changed what I thought about career progression. I'm probably a builder/scaler I def get bored in the maintenance phase.