The 5 archetypes of CTOs

Revisiting a famous paper from 2002 and adapting it to the reality I've been observed in the past two decades

Back when I was getting started in my first role as a CTO I remember reading an insightful article from Werner Vogels - Amazon CTO - on the different types of CTO roles that he published in 2007.

In his article, he identifies 4 main types of CTO, largely modeled around those identified in a 2002 paper by Tom Berray and Raj Sampath.

A couple of decades later, the situation has evolved while retaining a crucial aspect: There isn't a single definition of a CTO role as it's very context-dependent.

Today's article is a humble attempt at updating the classification shared by Vogels in 2007 to adapt it to the reality of the tech industry today.

Let's have a look at the 5 archetypes of CTOs that are commonly found in today's industry.

The 5 Archetypes of CTOs

🏗️ The Co-Founder CTO

This one seems to be the most common job posting on LinkedIn when you search for a “CTO”. It's also the kind of job offer that tends to confuse the most experienced CTOs who are looking for a new job.

I often refer to it as the “Glorified Tech Lead”, let's see why.

A person with this role is often the technical co-founder and therefore the first member of the tech team.

Their initial role is to build the first few iterations of the product, a task that involves making a lot of technical decisions.

They usually build up a team of a handful to a dozen people throughout one to two years, typically leveraging their network as the key means to attract new talent.

Most of their job is focused on doing technical work, with a bias towards short-term decisions as time-to-market considerations are crucial.

They spend the best part of their time writing or reviewing code, setting up infrastructure components, or testing new solutions.

People management is often limited to a minimum due to the small size of the team.

Organizational design is mostly a non-concern as they'll often be leading a single team, that will eventually be split in two when it becomes too big to be manageable for a single person.

When this happens, the CTO will often lead one of the two sub-teams, while delegating the task of leading the other to one of their most senior engineers.

The key traits of this CTO archetype are:

• Emphasis is on technical skills and hands-on coding

• Laser-focused on getting business ideas off the ground quickly

• Limited requirements in terms of organizational design and people management

• Usually manages only Individual Contributors

When the team and the business become too big to keep operating under the same paradigm, this CTO archetype is usually faced with a choice: accept that their role will become less hands-on and more focused on leadership, or decide to hire someone to take on the CTO role while they keep focusing on hands-on work.

In both cases, the organization will be moving towards the next archetype: The Scale-Up CTO.

📈 The Scale-Up CTO

The scale-up CTO moves away from the parading of “I'm building things” towards the paradigm of “I’m building teams and processes”.

Due to the inevitable problems caused by growing the team to a larger size - typically between 20 and 100 engineers - a lot of the CTO work focuses now on organizational design and its natural implications for architectural decisions.

This CTO archetype will need to find a healthy balance between focusing on strategic long-term decisions and ensuring that day-to-day tactical execution is proceeding smoothly.

As they usually manage managers, they will need to spend a significant amount of time coaching and mentoring people who might be leading teams for the first time.

They will find leverage in establishing clear and effective processes across the entire organization, pushing for engineering principles and practices that ensure a good balance between speed and quality at scale.

They'll often introduce standards, processes, and metrics to provide a mix of guidance and visibility.

They will invest time in areas that sit outside of the boundaries of technical systems: recruitment processes, performance reviews, budgeting, etc.

This CTO archetype is still very technical, but will generally focus more on big-picture technical decisions - Architecture, Practices and Principles, Key Technology Vendors, etc - rather than getting their hands dirty with the codebase regularly.

The key traits of this CTO archetype are:

• Focuses more on organizational design

• Balances long-term strategic decisions and tactical execution

• Establishes processes, metrics, principles, and standards

• Still very technical though not systematically hands-on with the code

When the engineering team reaches the size of multiple hundreds of engineers, the complexity of the business and the underlying organization often requires a shift toward the next archetype, The Strategic CTO.

🧭 The Strategic CTO

At this level, the CTO will spend a significant amount of their mental energy on strategic topics, while ensuring that execution is properly delegated and taken care of. To ensure smooth execution, they often rely on multiple layers of management: VPs, Directors, etc.

With the increased distance from “where things happen”, this CTO is faced with the challenge of becoming disconnected from the reality on the ground. It therefore becomes crucial to establish both processes and tools to mitigate this risk.

This CTO archetype will spend a lot of time setting the overall direction for the company together with the whole executive team, taking full responsibility for the tech agenda and charter.

They will spend a lot of time communicating the vision and the strategy to the company to ensure clarity and alignment. They will often hold all-hands meetings or AMA sessions with their teams to provide a mechanism for collecting questions and concerns from the organization.

Most of the tactical work will be delegated to the various VPs responsible for different areas, though they will need to constantly make sure execution is meeting expectations in terms of quality, throughput, and velocity.

As part of their role, they will often be involved in external facing activities, from speaking to conferences, investors, Board of Directors as well as being actively involved in M&A activities that involve the acquisition of technologies and technology teams.

This CTO will need to be fluent in business language while retaining its strong connection with the in-house technology as well as industry trends.

The key traits of this CTO archetype are:

• They operate with multiple layers of management below them (VPs, Directors, etc)

• Invest a lot of time communicating the vision and the strategy both internally and externally

• Think strategically, delegate most of the tactical work

• Frequently in active discussions with the board of directors, investors, strategic partners, etc

It's not uncommon to see a CTO progress through the first 3 archetypes:

Co-Founder CTO → Scale-up CTO → Strategic CTO

Though very common, this is far from being the only trajectory we observe in the industry. There are a lot of cases of successful CTOs who move back and forth from different archetypes in their career.

When the Co-Founder CTO is not able or willing to move on to the Scale-Up CTO model, in some cases we can see the occurrence of another archetype: the Tech Visionary CTO

🧠 The Tech Visionary CTO

This archetype roughly maps to the “Big Thinker CTO” from Werner Vogel's article mentioned earlier.

It is confusing as it moves away from the common understanding that a C-level role necessarily leads an entire division or function within the organization.

It can also create confusion at the level of responsibility boundaries between the CTO and the VP of Engineering, which can lead to waste or even unhealthy tensions within the organization.

With this model, the CTO is effectively a technically focused visionary software engineer who combines technical acumen with strategic thinking and leadership skills.

They don't manage the engineering team, which is often left to the VP of Engineering's responsibilities. As such, CTO and VPoE are often both reporting to the CEO and are peers in the executive team.

This CTO will leverage a small team of highly skilled software engineers to evaluate new technologies, prototype new solutions, and generally feed the rest of the organization with insights on key areas to invest in when it comes to architectural and technological choices for the years to come.

This setup is not without challenges though: the CTO will not have direct control on what the engineering team is building, and how. They'll need to leverage leadership and communication skills to be able to influence the rest of the company in the direction they consider the most relevant from a technological standpoint.

The relationship between the CTO and the VP of Engineering is crucial for this setup to work.

It's not uncommon to see the original Co-Founder CTO move into this type of role once the organization has reached the “scale-up” phase, as a way for them to keep focusing on what they do best, by enrolling the support of a newly hired VP of Engineering to take care of day to day execution, people management, career development, etc.

The key traits of this CTO archetype are:

• Has a VP of Engineering that focuses on running the team

• Focuses on the tech strategy and tech decisions through influence

• Very hands-on, spends a lot of time coding

• Sits alongside the VP of Engineering in the executive team

• Leads a small team that's focused on exploring the future technological keystones for the company

I've only encountered this setup a few times, and it usually requires a high degree of maturity both at the organizational level as well at the individual level for the key people involved. Egos can easily get in the way of such a setup with potentially ugly outcomes.

The last archetype is a bit of an oddity, but we should mention it for the sake of completeness: The CIO disguised as the CTO.

🛠️ The CIO disguised as the CTO

I've observed this archetype more frequently in companies that are not technology-driven or focused, but rather see technology as a support function. Usually, these companies operate with third-party vendors that provide the key components of the stack, integrated via an internal team that tends to be quite small.

Their focus is often split between “taking requirements” from other departments and trying to keep costs as low as possible.

There is nothing bad or wrong with the role of CIO or IT manager for such companies. I just want to mention that I've seen a certain tendency of title inflation, where these roles are advertised as CTO roles.

It's generally easy to identify these cases simply by looking at the details in the job offer or after the first screening call. Should you decide to embark on such a journey, you will likely need to plan to invest a significant amount of your energies in defining and clarifying what your role is supposed to cover in terms of responsibilities and skills.

The key traits of this CTO archetype are:

• Usually found at companies that think of Technology as their IT support systems

• They tend to focus on internal systems and supporting other departments

• Work mostly with vendors and integrators, build very little custom technology

Conclusions

There is often confusion about the nature of the CTO role and for good reasons.

There isn't a single definition of the role that can apply to the entire industry. Instead, we need to take into consideration what's required in different situations and contexts.

I like to think in terms of 5 different archetypes of CTOs:

1. The Co-Founder CTO

2. The Scale-Up CTO

3. The Strategic CTO

4. The Tech Visionary CTO

5. The CIO Disguised as the CTO

None of them are better or worse in absolute terms, they are just more or less relevant for specific types and stages of companies.

Though there is a common path of progression from 1 to 3, this is not the only possibility, nor it's to be considered the “best” approach in absolute terms.

As you might have different mental models for the role, I'm looking forward to reading about them in the comments.

See you all next week!