The 5 stages of CTO & the CTO Career Chasm

Unsurprisingly, there are different types of CTOs for the various stages of a startup. What makes a CTO strong in one stage might turn into a weakness two stages later, and vice versa.

I’ve been a CTO for the last sixteen years in half-dozen companies, from 1-person shows to 150+ people startups. In talking with many of my peers and based on my experience, I created a broad map of the strengths a CTO needs at each stage and what they should or shouldn’t prioritize.

I looked at Chris Yeh and Reid Hoffman’s Blitzscaling five stages of growth of a business as a way to frame the differences between CTOs. Blitzscaling is an excellent book, although I wouldn’t add it to the must-read column for CTOs. In the book, Chris and Reid define the five stages as:

  1. Family stage: Less than ten employees
  2. Tribe Stage: Tens of employees
  3. Village: Hundreds of employees
  4. City: Thousands of employees
  5. Nation: 10,000+ employees

Just by the nature of startups and how they evolve, there are ten times fewer startups as the stage progresses. In other words, there are ten times more startups in the Family stage than in the Tribe stage.

Since we are also talking about tech companies, software engineers’ headcounts are usually more than 50% of the team. That’s until they reach the Village stage, where other roles like sales, customer success, support, go-to-market, and administrative functions grow at a faster pace than engineering — which is what you’d expect of a successful business.

The Family CTO

To be the CTO of a Family (startup) means the startup has at least two people, the CTO, and the CEO. This person is also likely the founder. With very few exceptions, the CTO will be the person who kicked off the project and wrote the first lines of code.

This CTO tends to be technically strong and wear all the hats. Full-stack is not enough to describe their work because it would limit them to technology. This CTO is full-stack on engineering, full-stack on product, full-stack on design, full-stack on growth hacking, full-stack on IT, full-stack on customer support. Basically, the product and engineering team in a one-man/one-woman show. They are not necessarily great at most of those things, but they know enough to get by.

To be great at this role, this CTO needs not to be afraid to roll-up their sleeves and do whatever it needs to get done to move the product forward. They need to be proactive, pragmatic and execute in light of extreme uncertainty and ambiguity. They are telling the story while writing the story!

At this stage, the CTO shouldn’t be spending time adding processes to the organization, optimizing the recruiting engine, or spending too much time learning how to be a better manager or a better leader. Without a product that a) is in the market, and b) customers are using it, everything else doesn’t matter.

A superstar Family CTO is focused and fast. Focus is needed because there is nothing worse than a blank canvas. When you can do whatever you want, and everything is possible, it’s so easy to get distracted by all the shining lights. Being fast is important because you need to minimize time-to-market to start the learning process as soon as possible. The difference between launching a beta version of a product in 3-months vs. 9-months could be life or death.

The Tribe CTO

Going from a Family CTO to a Tribe CTO is probably the most challenging transition of all the stages. To expand Geoffrey Moore’s terminology, it’s the CTO Career Chasm. It’s the hardest because it requires a mindset change from feeling a sense of purpose from the work by your own hands to the work by the hands of others, with you leading them. I’ll elaborate more on this topic below.

Once an organization gets to tens of people (the Tribe), communication starts to breakdown. In the early days, the ideological approach of no-meetings, no-specs, every email includes everyone, and let’s not worry about what we are building next month breaks down. Growing from a handful of engineers (likely with no PMs) to a team of a few dozens of engineers and a handful of PM means you need to add more rigor to the Agile methodology in place. It’s the start of teams being formed and named, the first layers of management, and a company org chart. It also means that you’ll face the biggest challenge of every startup, recruiting. The tactics of recruiting a handful of people don’t work when you need to hire 20–30 people.

These CTOs will also struggle in how to communicate with their own organization. They might reach engineers directly, bypassing their managers, and causing significant disruption to people’s feeling of ownership and autonomy.

At this stage, the CTO can still maintain knowledge of everything that’s happening, potentially even adding some hands-on value here and there. They can point to each person on the team and fairly accurately tell what they are working on that week. They know when each major feature is rolling out. They contribute actively to planning, including helping break down feature scope and architecture, participate in design review or user research, and guide team members on implementation.

The superstar Tribe CTO holds an excellent balance between product, technology, management, and leadership. They are excellent at mentoring and coaching their team through difficult situations, particularly around people-problems.

It would be premature for the Tribe CTO to start thinking about deploying more advanced organizational systems practices. It’s essential to keep the boundaries of teams and their responsibilities malleable. Allowing teams to collaborate and letting a “free-market” of information flow is necessary to maintain agility. It’s not about having chaos in communication, it’s about being not so rigorous when people skip a step.

Adding a more formal performance review process is essential. Employee engagement and retention starts to become a topic of high importance. There will be pressure from the team to add a proper career ladder, competency matrix, and career paths. Some CTOs get excited about this work, but when the rubber meets the road, they realize all the pitfalls of adding a career ladder. The cost-benefit it’s just not worth it unless they’ve done it before. Better wait until the startup is a Village.

The Village CTO

The transition to a Village CTO is not as hard as the one from a Family to a Tribe CTO; they crossed the CTO Career Chasm. How the CTO approaches the role and the knowledge and skills they need to develop are different, but my experience is that it’s a more natural progression. They only need to make sure they don’t miss the change in the beat.

The Village CTO shouldn’t be building any product themselves (or the company has a different problem). They are managers of managers and possibly managers of executives. On the one hand, there is a seniority level in the organization that makes everything run more smoothly. On the other hand, teams can become territorial, siloed, or operating with their own set of values, principles, and goals.

This moment is where organizational systems kick in. Knowing where to draw the lines of ownership and responsibility becomes critical to success in this role. Being able to manage a low level of politics is necessary to build healthy teams. It’s also essential to keep everyone driving towards the bigger goal and creating the space for teams to align on progress and dependencies.

The superstar Village CTO will use all their strengths to keep things together. More than ever, they need to embody, champion, and, when necessary, enforce the company values, cultural norms, technology, and process convergence. It’s as if the job is nothing more than repeating those things and helping people understand that teams need to work for the company’s benefit, even if it means sacrificing their own goals.

It might be the time where engineering and product part ways and become their own, entirely separate organizations. If they were part of the early team, the Village CTO needs to decide if they will be the CTO of the engineering organization or the CPO of the product organization. And, in some cases, they become neither. They stop leading either organization, and they work on exploratory work, strategy discovery, or very long-term initiatives.

Being a Village CTO means the business is working. You don’t get to 100+ employees on the backs of investors’ money. At this stage, technical debt starts to hold back the business. Whatever technical decisions and implementations were made many years ago are not scaling anymore. The worst kind of village CTO is the one that wants to recreate everything from scratch. That could mean the end of the business after a massive failed project. Thankfully, this is a rare occurrence.

The City CTO

The City CTO manages a team of hundreds of engineers. They have VPs supporting them, and these VPs are organizing their teams in the way that’s best for them. The job tends to be a lot more strategic. A lot more about setting guiding principles, consistently repeating the organization’s values and vision, and defining goals that will impact 1–3 years from now. The City CTO is the CTO of several Village CTOs.

An organization of that size has a strong culture embedded into each employee’s work DNA that even small changes become monumental efforts. Changes in direction, changes in process, org changes, etc. It becomes harder to accept failure or acknowledge that a strategy wasn’t the best one. Once you persuade two dozen people that they should row to the island in the North, and halfway there, you realize that’s the wrong island, it’s tough to turn the ship around. Just the suggestion that you might have to change direction might cause a handful of people to abandon the ship, a handful of people to start rowing even faster, and a bunch of folks questioning the ability of the leadership to make decisions.

The culture of the organization will be the defining factor of the skills of this CTO. Is it an engineering-driven, product-driven, or sales-driven organization? Is it an organization that fosters transparency and candor or one that’s highly political and manipulative? Is it an organization that values experimentation & lessons-learned or one that is risk-averse? Is it a consensus-driven organization or an owner-driven organization? Is it a data-driven organization or a gut-driven organization?

The Nation CTO

The Nation CTO is… unique! The reality is that there are fewer than 20 of those people in the world, and when the size of the data set is so small, you can’t define what the role is. However, you can abstract a few things that all the CTOs have in common.

The Nation CTO is not a CTO of City CTOs. It’s not unusual for them not to have the entire engineering organization under them. Some top tech companies, where these folks reside, have a history of having and not having CTOs. Can you name Google’s CTO? What about Apple’s CTO? In other words, they are not critical to the success or proper functioning of the business. In reality, once the company crosses a specific size, no single individual is critical.

The CTO Career Chasm

We talked about the five stages of CTO; we should also talk about the struggles of some CTOs of moving from one stage to another. I’ve seen many CTOs who couldn’t go from a Family CTO to Tribe CTO.

CTOs hit their ceiling because they don’t want to or can’t do the job’s hands-off and people-management aspects. The CTO Career Chasm happens when a CTO can’t move from being a chef in the kitchen working the stove, chopping, and plating to be someone away from the kitchen, focusing on hiring, coaching, and guiding other chefs.

The Family CTO most likely got there because of their technical prowess. Because they were able to combine things and have insights others didn’t see before. Their identity is strongly associated with writing code and making things with their hands. At this point, they have to decide if they want to “take another job” as a Tribe CTO. A job they are inexperienced and likely underqualified to do. I have never seen a Family CTO deliberately make the decision to continue being the CTO; it just happens.

I’ve seen CTOs, managing hundreds of engineers, acting like they are a Family CTO. That’s not what the organization needs! It only happens because they are the company’s founder, and the CEO doesn’t have the courage (or the understanding) to tell this person they are not doing their job. Success hides a lot of flaws in people and organizations.

Once a CTO finds their footing and purpose of being a Tribe CTO, the challenges and obstacles they will face will be new, but at this point, it’s not about redefining one’s identity and purpose in life. It becomes easier to move through the stages. There is still a lot of knowledge to be acquired, skills to develop, and lessons to be learned.

In the same way, some engineers pursue an engineering management role to realize that’s not what they want to do with their life; some CTOs become the CTOs of large teams only to realize what they want is to be a Tribe CTO, managing a few dozen people. That’s because it’s easier to move the ship; it’s easier to have a more significant influence and impact, both on people and the business. Coincidentally, it’s also where there are more job opportunities for CTOs. Nearly all the CTO open positions that you can find on LinkedIn are Tribe CTOs.

The exception is that there are many job opportunities for “CTOs” for the Family stage business, but the fact is that the founder/CEO is not really looking for a CTO. They are looking for an engineering or product leader. If that’s what you are looking to hire, I wrote a post on the topic.

Here’s a list of books and resources that I recommend for each CTO stage. So we are clear about these recommendations, I’m not endorsing 100% of what’s in these books, but I believe they provide a good starting point for those CTOs to uncover more of what they don’t know.

Books for Family CTOs

Books for Tribe CTOs

Books for Village CTOs

Books for City CTOs

📬 If you have thoughts about this piece, shoot me an email even if you disagree with me.

Marcelo Calbucci

Marcelo Calbucci

I'm a technologist, founder, geek, author, and a runner.

Book time with me