I have heard another version of this classification: people are either builders, or scalers, or optimizers, but rarely combine the traits. They are good for different stages of the company growth. Builders are good at the most risky and innovative stage from founding the company to getting first customers. Scalers know how to become big and profitable. Optimizers squeeze the juice and keep moats deep.
I think there are only 2 types of people: those who buy into schemas that divide people into between 3 and 16 groups with cool names and those who don't.
Your schema doesn’t account for companies that only have a management tack or an ic track with no opportunity for someone to sometimes lead teams and sometimes make technical decisions. I think you’ll find it’s better if you simply encompass the natural numbers.
According to Gödel's incompleteness theorems, there never exists a complete set of types of people, because there’s always one more type — people writing about those types.
I think this explains the trouble at my current company. We're a couple years into the scaling phase and it's become clear that our CEO is a builder and doesn't know how to scale.
I don't think he understands that and there's really not anything I can do about it but move on.
There was a show (if someone has the reference please add it) where these business guys were discovering chefs and working to turn their restaurants in to franchises.
There was a huge wake-up call as they kept working with this brilliant chef who all but refused to write down recipes, share processes, or do anything but run his restaurant the way he always had. He just couldn’t see that going from restaurant to franchise was an entirely different thing than running a great restaurant.
If I remember correctly, ultimately despite a bunch of different creative approaches, they had to back off.
I think about that a lot when businesses want to go from building to scaling.
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.
Just found the talk on YouTube ( https://www.youtube.com/watch?v=WazqgfsO_kY ). Thank you! It expanded on the basic idea of "cost of failure" very well. I've tried to argue his points with mixed success, but now I can point to a talk given by someone who cut his teeth at Facebook.
