The Four Stages of a Startup CTO

Throughout a startup's journey, the role of the CTO goes through four different stages, and each stage requires different types of leadership. Knowing what stage you are in and where the focus should lie is key for both the CTO and the founder.

Below I’ve modeled the four key stages that a startup, and consequently that a CTO goes through. And while the actual numbers can differ between companies, the stages are usually the same.

In this blog post, I will do a deep dive into each archetype, with a discussion at the end where I provide advice for founders (should you even hire a CTO?) and aspiring CTOs.

The Coder - Getting shit done

At the very early stages, the CTO is mostly responsible for writing code. This CTO is most likely a co-founder and usually writes the very first lines of code. At this stage, it’s all about getting to market, and no task is too small.

This CTO needs to be technically strong. Language choices, platforms used, original architecture, lightweight analytics tools, frontend, backend. You name it. The CTO needs to be able to deliver on all points, since there isn’t anyone else to lean on, and often without being an expert in most of them.

Focus on getting the first paying customers and speed of iteration is more important than getting things just right. Launching in 4 months instead of 8 months could be the difference between traction and an early grave. Speed is life and the CTO needs to understand this to be able to ruthlessly cut scope and keep processes as light as possible.

It’s tempting at this stage to start cleaning up and focusing too much on Good Architecture™️. That’s all good and well if you have a steady stream of revenue. But it will matter less if the company iterates too slowly and the company needs to shut down.

As the company raises its initial rounds, the Coder CTO now gets the added responsibility of hiring the first developers. They should ideally be senior enough that the CTO doesn’t have to micro-manage them. Again, focussing on speed. If possible, these hires should be people they have worked with before, as it avoids the Storming Stage, where a lot of conflict takes place, of forming a team.

With limited resources, a lack of clarity on where the product is heading and nobody on call if a server goes down on a Saturday night, the risk of burnout is very real. Having a system for getting the most important thing done first every day is crucial. Remembering to get enough sleep is even more important. Seriously. Get some sleep.

The Manager - Getting people to work together

The Manager is still very much in the code but now starts to delegate responsibility for larger parts to other people in the team, with sub-teams as a consequence. It will become impossible to look at all pull requests, taking the CTO further away from the day-to-day.

Technical work will be more focused on rework, rather than getting to market, as the shortcuts that were taken to be able to launch fast no longer cut it. Instead of moving fast and breaking stuff, the CTO is now delegating a lot of the work, preparing the team(s) for scale. With this, team performance becomes more interesting than individual performance.

As more and more responsibilities are delegated, the Manager is responsible for getting people to work together in a way that doesn’t slow down the team too much. I say too much because you will slow down at this stage. More people needing to communicate will lead to longer lead times.

Reducing slowdown comes down to two things - Communication and hiring. It’s critical to only bring on A-players for all roles, as these are the people who will eventually become your leaders.

Effective communication means coaching and mentoring people. If you are an introvert, this can be a real challenge. Especially since the rest of the company battles their own challenges, such as sales, which means the whole company might get stuck in this stage for a long time.

One or two of your original team members might even start feeling disconnected as they go from being part of everything to only focusing on a single part of the system, leaving the company as a result.

While difficult at times, people leaving at this stage is part of preparing for the next step. Just as there are different stages for the CTO, developers also have their preferred stage. As long as there are good processes in place, including processes for documentation, it will be fine.

The Director - Leading leaders

This is where the largest shift in the CTO’s journey takes place. The company is now entering the growth phase and everything that has been growing linearly until now starts growing exponentially instead. The CTO starts to disconnect from the roots (the writing code) to focus on leading leaders.

Technological challenges also shift at this stage. Security and privacy now become real concerns, and it’s no longer acceptable to skimp on GDPR compliance. If the CTO wants to stay close to the technology the role usually evolves into one of R&D and exploration, while the engineering managers handle the day-to-day. If the CTO is more interested in people and processes, the CTO might instead focus more on building the business side of the organization.

This is also where it’s common to bring in a VP of Engineering, to help lead hiring and processes around staff. As the CTO stops thinking about hiring individual developers to hire leaders and building a culture that attracts the very best leaders.

The main challenge with this stage is that the tools that used to work well no longer work. Managing every situation is no longer an option (there are just too many people). Instead, a shift needs to happen where the CTO lets go of the tactics (short-term actions) and instead focuses on strategy (long-term goals).

A challenge at this stage is that communication between teams and even organizations risks halting, with siloing as a result. Again, what used to work no longer works and the processes (instead of the code) are what needs a lot of rework. This becomes especially clear in organizations where Engineering and Product become separate organizations entirely.

There is also a challenge in lack of clarity at this stage, but this time it’s clarity about the long-term vision around both product and internal processes.

The Strategist - Leading with values

Whenever someone mentions Leading At Scale, this is the stage they are talking about. The engineering organization has now grown from tens of people to hundreds of people and The Strategist CTO sits at the very top of the battlefield. Leading now means leading Directors who are responsible for internal organisations with their budgets, targets and hierarchies.

The Strategist's primary responsibility is to ensure that the company is staying ahead of the competition and that its technology strategy aligns with its long-term business goals, creating and revising goals that span over multiple years. The sheer number of projects running in parallel means the CTO has to take a step back and let the Directors lead while still setting the tone for the company as a whole.

This means leading with values and leading through an explicit culture. Where culture previously might have been about engineering practices and individual people, the organization now needs processes to work as a Product-driven culture a Sales-driven culture or an Innovation culture.

While the seeds for the type of culture the CTO wants should have been planted in previous stages, there are no free lunches and the culture constantly needs to be nurtured and pruned so that it grows in the direction you want. The way the Strategist does this is through incentives, how feedback is given, and how hiring and (more importantly) firing is done.

Responsibilities at this stage include allocating a budget to R&D and managing entire business units. This means creating multi-year strategies, where it might be unclear if the right decision has been made until several years have passed.

Many of the technical decisions at this stage will be of the Build or Buy nature. In previous stages "Buy" would mean buying software (e.g. ElasticSearch) to solve a specific problem. At this stage, the CTO is buying other companies. This means the stakes are higher, as the decision to buy the wrong company to integrate into the existing product.

The main challenge that the Strategist faces is to keep the pace of innovation high enough as internal bureaucracy and politics also grow. I’ve seen companies employ Heads of Innovation, but to me, this just signals that the CTO is the wrong person for the current stage (or the wrong person altogether).

What does this mean for you?

If you are a founder who is recruiting a CTO you know that it is a challenge. The very first question you should ask yourself though is whether or not you need a CTO. If you have just started the main focus should be on the code, so it might be enough to hire a lead developer who has a broad enough skillset to solve all your technical problems.

As the company grows you could either choose to promote the lead developer, hire a Head of Engineering or hire a Manager-type CTO. This choice depends a lot on the people you have in the company and how likely it is to find the right CTO for your company. Choosing to wait with hiring a CTO is not just about buying yourself time to find someone. You are also buying yourself time to figure out which stage you are in and what type of CTO you need.

If you do decide to go for a CTO, it is extremely important to know what stage the company is in, because hiring the wrong stage of a CTO could cost a startup time and resources. So before you go out and start reaching out on LinkedIn, take a look at what the company truly needs.

An option to consider if you are “between CTOs”, or if you are in the Coder or Manager stage, is a Fractional CTO. These Fractional CTOs are mercenaries who usually specialize in a particular stage. Bringing on one of these could buy the time needed to find a truly great fit who can stay for many years and grow with the company’s needs. But they can also be brought in to perform specific tasks such as preparing the company for technical due diligence before a Series A or just to work alongside an existing CTO to level up their skills.

In the same way that company leaders need to know what stage they are in to know what to recruit for, if you are an aspiring CTO you need to know where you are, to be able to take the steps needed to get where you want to go.

Most job ads I’ve seen are for Manager-type CTOs, and a good way to gain the experience needed for this role is to join a fast-growing startup at the Director stage as an Engineering Manager or maybe VP of Engineering. These tend to be similar to the Manager CTO in terms of day-to-day responsibilities, and shadowing a great CTO will give you insight into the job that you just can’t get anywhere else.

Another great way to gain experience is of course to join a non-technical founder. Every day I see non-technical founders posting on Twitter or Reddit asking where to find a Coder for their revolutionary new idea. Just make sure you vet the person thoroughly before jumping in. This is a long-term commitment, so you need to feel comfortable working very closely with this person for +5 years.

If you are reading this as a first-time CTO, it might be helpful to join a MasterMind group with CTOs of a similar level. Maybe even find a coach specialized in coaching CTOs. Having a support group of people going through the same thing or who have recently been where you are can be a huge help in dealing with mental struggles and avoiding common pitfalls.

Wrap up

With that I hope you now have a better understanding of the CTO role at different stages of a startup’s lifecycle. That said, no two startups are the same, and so no two CTO jobs look the same. There will always be nuances depending on what the product is, what skills the other leaders in the company have, if the CTO is more introverted or more extroverted etc.

This blog post also assumes some sort of software-based company on a Venture Capital path, so the numbers for each stage will probably differ quite a lot for bootstrapped companies and non-software based (e.g. hardware, DTC fashion). The stages of the CTO role should still be generally correct though.

Lastly, I am putting together a CTO coaching offering, so if you are a first-time CTO, if you are working with a coach or if you are considering getting one I would love it if you would reach out to me via Twitter, LinkedIn, or email.

In any case, I hope you enjoyed this look into the four stages of a CTO.

Until next time!

/Viktor