The startup CTO growth cycle

UPDATE 15/09/21: Illustrations have been updated to show stages based on team size and ARR on instead of funding stage only. CTO avatars are now 50% male and 50% female (to balance gender bias).

One of the biggest challenges startup CTOs face is changing jobs every time their company reaches a new growth stage, roughly every 18 months. For a founding CTO, if everything goes well for their startup, they will go from coding most of the time to being completely out of the code in 5 years or less! This level of change is challenging if CTOs don't anticipate their future responsibilities and the associated skills.

That's why most founding CTOs tend to step out during their company's growth, either to focus on R&D or to leave the company altogether. While I understand the need for some to focus only on the tech side, without the annoyances of people management and some of the politics that come with growth, I believe startups would benefit tremendously from having their founding CTOs even after reaching unicorn status. When a startup hires a "seasoned" executive to take over as CTO, they inevitably lose their DNA since the new CTO comes in with their playbook and, usually, some of their former lieutenants.

I've put together the below Startup CTO Growth Cycle to help CTOs anticipate these changes and prepare themselves for the next version of their role. The Startup CTO Growth Cycle is a model to anticipate responsibilities and expectations of a startup CTO at each stage of their company's growth. I've modelled 4 distinct stages based on team size, Annual Recurring Revenue (ARR) or funding stage.

I hope this framework will help CTOs project into who they can become in several years and understand how they can still help their company, even if they don't code anymore. Also, while there is no one-size-fits-all CTO for every startup, this framework can be helpful as a starting point.

Stage 1 - The Maker

Before making serious revenue, or raising their first serious round of funding, the CTO spends 70% of their time (or more!) coding the product. They spend some time meeting with prospective users or coordinating with their co-founders. But they essentially code, code, code. This period is usually very straightforward and immensely rewarding for the CTO. Almost everything depends on their ability to build usable features fast, and they get to "stay in the flow" most of the time.

Stage 2 - The Expert

Hurray! After months of trial and error, the startup has finally found its product-market fit. Users are enough to convince early-stage investors to raise a first round of funding, or even better, revenue is enough to make the first hires. At this stage, the CTO has to recruit their first developers and usually hire in areas where they don't feel comfortable or don't necessarily want to do.

Because the team is larger but still manageable (less than ten developers), the CTO can still code around 40% of their time. But now, they have new responsibilities: training new developers on the code base, answering questions, reviewing pull requests and putting together simple workflow processes. Depending on the time spent training new developers and writing good documentation, CTOs can easily fall into the "oracle trap", where they spend most of their time answering questions from team members.

Stage 3 - The Manager

Everything is now going faster. Users are flowing in and, to cope with the demand, the team needs to grow. The CTO is now in charge of a 15+ people team with front-end and back-end developers, some core services developers and even a DevOps person. With so many developers in the tech team, it is unreal for the CTO to spend more than 10% of their time on the codebase.

They're now the team manager, and like any manager, their mission is to set and achieve team objectives by enabling individual team members to give their very best. To do so, they have to spend almost 50% of their time improving team members through one-on-one meetings, training and coaching. They spend the rest of their time coordinating with other team leaders (like the product team) and crafting tech strategies to achieve the company's objectives. One of the skills required for this CTO is to understand business objectives enough to translate them into technical objectives that their team will execute.

Stage 4 - The Executive

At this stage, if the company has continued executing their plan flawlessly, it should be raising a massive round of funding. Usually, the CTO hires a VP of Engineering to help them manage a now very large team (50+ people). At this stage, the CTO completely "owns" their C-level title and their responsibilities resemble those of the other C-levels: crafting visions and strategies, representing the company publicly, talking to important customers, participating in board meetings by being the technical contact for investors.

There are many flavours of CTO-VP of Engineering relationships, but the one I find the most interesting is the one where the CTO acts like a country president and the VPE like the country's prime minister. In this model, the VPE is responsible for executing the CTO's vision and managing the teams. Some CTOs like to use the regained freedom from operations to build an R&D team and overlook their work on the side.

Much more could be said about these CTOs, and I hope this framework can be a starting point for many CTOs to start thinking about their role and how to anticipate their future responsibilities. What do you think?