The CTO job is one of the least well-defined roles in the technical world. That is not sloppiness in the industry. It is a real consequence of how the work is put together, and you can only navigate it once you can see the parts.
Fournier’s approach is to skip the title and list the roles senior technical leadership can play. Companies then combine them by need.
Nobody holds all seven. Some people can play several, some only one or two, and some companies do not need all of them filled. At a large enough company every one of these breaks down and has to be looked at division by division.
The titles come from which roles get bundled. These are Fournier’s observed combinations, and the same title appears in several of them.
Columns are the seven roles above, in the same order.
| Title it usually carries | R&D | Strategy | Org | Exec | Face | Infra | Business |
|---|---|---|---|---|---|---|---|
| CTO, or Head of Engineering | ● | ● | ● | ● | |||
| CTO, Chief Scientist, Chief Architect, sometimes CPO | ● | ● | ● | ||||
| VP of Engineering, General Manager | ● | ● | ● | ||||
| CTO or CIO, possibly VP of Technical Operations | ● | ● | ● | ||||
| Head of Product or CPO, sometimes CTO | ● | ● | ● | ||||
| CTO or Chief Scientist, usually a cofounder | ● | ● | |||||
| VP of Engineering, sometimes Chief of Staff | ● | ● |
Read down the columns and two things show up. Organization never appears without execution, because designing teams you cannot hold to delivery is a broken half of a job. Execution appears without organization once, in the product row.
And CTO appears in five of the seven rows, with no single role common to all five. The R&D row and the infrastructure row share nothing at all. It is not one job with variations, it is several jobs sharing a word.
Fournier gets the negative definition out of the way first, and it is the part worth memorizing.
CTO is not an engineering role. It is not the top of the technical ladder. It is not the natural progression an engineer should aim for across a career. It is not a job most people who love coding, architecture and deep technical design would enjoy. And the CTO is not necessarily the best engineer in the company.
That is four sentences aimed at one belief, which tells you how often she has watched it cause damage. The belief is that the ladder continues upward through the same kind of work. It does not. It ends, and a different ladder starts.
Her definition: the CTO is the strategic technical executive the company needs at its current stage of evolution.
Both adjectives carry weight. Strategic means thinking long term, planning the future of the business and the things that make that future possible. Executive means taking that thinking and making it operational, by breaking down the problem and directing people to execute against it. Strategy without the executive half is a document. Execution without the strategic half is a delivery manager with a bigger title.
The CTO is an executive first and a technologist second. The reason is access, not status. You are meant to shape business strategy through the lens of technology, and you cannot do that from outside the room where the business problems get named.
The last edge is the one to watch. Other executives will always have ideas and needs for technology. Part of the job is protecting the technology team from becoming a pure execution arm for those ideas, with no room for its own.
Fournier sets her model against a specific alternative: that the CTO should focus on purely technical issues, as the chief nerd.
Under her model, a CTO must find where the biggest technical opportunities and risks for the business are, and go at them. If that means a quarter spent almost entirely on recruiting, retention and process, that is not a detour from the job. That is the job, because that was the most important thing for the technology team at the time.
This is what makes the role hard to evaluate from outside, including by the person doing it. There is no fixed activity you can point at. The same week of work is excellent or negligent depending on what the company’s actual constraint was.
Two things, and they both happen before you have any authority to change anything.
Find out which combination you were hired for. Not from the title and not from the job description, which is written to attract rather than to describe. From what the CEO says the company’s next year depends on, and from which of the seven roles nobody is currently playing.
Then check it against what you want to do. The gap between the role you were hired for and the role you enjoy is where most CTO unhappiness lives, and it does not close by itself. Somebody who took the job because it was the next rung will find that the ladder went sideways.
The next lesson takes the most common source of confusion in that taxonomy, the line between CTO and VP of Engineering, and makes it precise.
Source: Camille Fournier, The Manager's Path, Ch. 8 'The Big Leagues'
Answer to reveal the explanation. Nothing is scored.
1A recruiter tells you the company wants a CTO who will 'own the technical vision'. What have you learned about the job from that sentence?
Fournier's point is that CTO is one of the least well-defined roles in the technical world. The same title covers a technical cofounder, a promoted VP of Engineering, someone with no direct reports, and someone running all of engineering. 'Technical vision' does not narrow it. Finding out which combination they mean is the first task, not an optional clarification.
2Fournier says the CTO is an executive first and a technologist second. What is her reason?
The ordering is about access, not status. Technology decisions get their value from which business problem they attack. If you are not in the room where those problems are named, your technical judgment is being applied to a question someone else already chose for you.
3A CTO spends a quarter almost entirely on recruiting and interview loops. By Fournier's model, what is the right reading?
Fournier sets this against the idea of the CTO as 'chief nerd', focused on purely technical issues. The CTO's work is whatever the biggest technical opportunity or risk for the business currently is. Sometimes that is an architecture. Sometimes it is that you cannot hire fast enough to build one.
4Which pair of roles does Fournier say almost always travel together?
Organization owns staffing and structure; execution makes sure the work gets done. Splitting them gives you someone who designs teams they cannot hold accountable, or someone accountable for delivery who cannot change the team. Together they are the core of a VP of Engineering, which is the next lesson.
5You are the strongest engineer on a 12-person team and are offered the CTO role. What does this lesson say the offer is?
Fournier is blunt: CTO is not an engineering role, not the top of the technical ladder, and not a job most people who love coding and deep technical design would enjoy. Being the best engineer is close to irrelevant evidence either way. It is the most common reason people take the job, and the most common reason they are unhappy in it.