Chapter 1: The Coder, the Manager, the Director, the Strategist

Evan Cooke, co-founder of Twilio, put the problem bluntly at First Round’s CTO Summit in 2024: the enormous scope of change in the CTO role does not get enough recognition.^[2] Cooke described it as three careers compressed into one tenure. The first career is the engineer — in the code all day long. The second is the manager — one morning you wake up and realise your entire day is meetings, you are managing 20 or 50 people, and you are buried in one-on-ones and recruiting. The third is the executive — you have finally hired a VP of Engineering, and now you are confused about how to continue moving the business forward with the same momentum.^[2]

Daniel Jarjoura, who runs a ten-week experiential course for startup CTOs, quantified the cycle: a founding CTO changes jobs every time the company reaches a new growth stage, roughly every 18 months. If everything goes well, a founding CTO goes from coding most of the time to being completely out of the code in five years or less.^[3] The 18-month figure is an approximation — hypergrowth compresses it, slow burns stretch it — but the underlying dynamic holds. The company does not pause and announce that it has entered a new stage. It grows, and the CTO’s job transforms around them whether they are ready or not.

The ambiguity is not new. When Werner Vogels, Amazon’s CTO, wrote about CTO role types in 2007, he opened by quoting Nathan Myhrvold, the former CTO of Microsoft, who when asked to define the role responded with a two-word answer that still resonates: "Hell if I know."^[4] Vogels was drawing on a 2002 paper by Tom Berray and Raj Sampath that attempted to classify CTOs into four archetypes — Infrastructure Manager, Technology Visionary, External-Facing Technologist, Big Thinker — none of which quite captured the startup version of the role.^[5]

Two decades later, the taxonomy has sharpened. CTO coach Viktor Nyblom identifies four sequential stages, each triggered by the company’s growth, each requiring fundamentally different skills.^[6] Jarjoura’s research independently maps almost the same stages, adding the quantitative dimension of how much time the CTO spends writing code at each one.^[3] The convergence is striking. Two practitioners working from different client bases arrived at essentially the same model:

Sources: Nyblom (2023) for stages, company size, and revenue ranges; Jarjoura (2021) for coding time allocation.^[6][3]

Each stage has a distinct failure mode — a trap that catches CTOs who have mastered the current stage but not yet recognised that its demands are shifting.

The Coder is the founding builder. Vadim Kravcenko described the stage with the candour of someone who lived it: "In 2017, I found myself stepping into the shoes of a CTO for the first time. I joined a small startup as a senior developer, and before I knew it, I was handed the reins of the tech team. Having the CTO title sounded cool, but in reality, it was more of a tech lead role."^[7] That gap between the title and the daily work is characteristic. The CTO at this stage writes code, does DevOps, handles security, interviews candidates, fields customer support tickets, and makes architecture decisions — often all in the same day. Speed-of-iteration is the survival metric. Nyblom is direct: launching in four months instead of eight could be the difference between traction and death.^[6] The trap at this stage is premature optimisation — investing in elegant architecture when the product does not yet have revenue. The CTO who spends three months building a microservices infrastructure for an MVP that may pivot next quarter has confused engineering quality with business survival.

The Manager emerges when the team outgrows what one person can coordinate. Sub-teams form. Pull request review becomes impossible to do solo. The CTO’s job shifts from writing code to getting other people to write code together — and the difference between those two activities is larger than it appears from the outside.^[6]

The technical work itself changes character. At the Coder stage, the CTO writes greenfield features and makes architecture decisions. At the Manager stage, a growing proportion of the technical work is rework — paying back the shortcuts taken for speed during the Coder stage. The CTO is still writing code 40% of the time, but the nature of that code has shifted from building to maintaining, and the other 60% is consumed by training developers, reviewing pull requests, documenting processes, and conducting the hiring that the growing team demands.^[3]

Jarjoura identifies a specific failure mode at this transition that he calls the "oracle trap": the CTO, who built the original system and knows it best, spends most of their time answering questions rather than building systems that answer questions. Documentation is insufficient, knowledge is locked in one head, and every decision waits on the bottleneck.^[3] Some early team members leave during this stage — they joined a startup where they were part of everything, and now they are part of one thing. Nyblom normalises this: developers, like CTOs, have a preferred stage.^[6]

The Director is where, in Nyblom’s words, the largest shift in the CTO’s journey takes place.^[6] The company enters its growth phase. Linear growth becomes exponential. The CTO disconnects from code to focus on leading leaders — not engineers, but the managers and team leads who manage engineers. Security, privacy, and compliance become real concerns; GDPR compliance, for instance, can no longer be skimmed over with a checkbox. Two paths emerge: if the CTO wants to stay close to technology, an R&D or exploration role; if more drawn to people and process, the business side of the organisation. It is common to bring in a VP of Engineering at this stage, and the timing of that hire matters enormously — too early and the CTO loses ownership before the organisation needs the structure; too late and the CTO burns out trying to manage at a scale their methods cannot support.

The core problem is that the tools that used to work — managing every situation directly, staying close to the code, making all the decisions — no longer work. Communication silos form between teams. Processes, not code, need rework. A shift from tactics to strategy has to happen, and the CTO who resists it becomes the organisation’s bottleneck at a scale where bottlenecks are fatal.^[6]

The Strategist leads an engineering organisation of hundreds. Directors report to the CTO with their own budgets, targets, and hierarchies. The CTO’s primary responsibility is ensuring technology strategy aligns with long-term business goals — multi-year goals, not sprint goals. Build-versus-buy decisions at this scale mean acquiring companies, not choosing libraries.^[6] The challenge is maintaining innovation pace as internal bureaucracy grows. Nyblom offers a blunt diagnostic: if a company employs a Head of Innovation, it signals that the CTO is the wrong person for the current stage.^[6]

The model is a simplification. Real companies do not announce when they have crossed from one stage to the next. Revenue ranges overlap. Team sizes vary by industry — a healthcare SaaS company at €10M ARR may have a much smaller engineering team than a consumer social product at the same revenue because the sales cycle, compliance burden, and customer concentration are different. But the simplification is useful precisely because most CTOs have no map at all. A rough map beats navigating blind.

The stage model implies a progression: Coder to Manager to Director to Strategist, each a step on a ladder. Sergio Visinoni, a CTO practitioner, offers a correction.

Visinoni identifies five CTO archetypes, three of which map to Nyblom’s stages: the Co-Founder CTO (roughly the Coder), the Scale-Up CTO (the Manager), and the Strategic CTO (spanning the Director and Strategist).^[8] The common progression runs through those three. But Visinoni adds two archetypes that the stage model misses.

The first is the Tech Visionary CTO — a role in which the CTO does not manage the engineering team at all. A VP of Engineering handles execution. The CTO leads a small team of skilled engineers focused on evaluating new technology, prototyping, and feeding the organisation with technical insight. This is not a failure to progress through the stages. It is a deliberate lateral move. It also requires high organisational maturity: egos, as Visinoni notes, can easily get in the way.^[8]

The second is the CIO Disguised as CTO — a role found in companies where technology is a support function rather than the core product. The CTO works mostly with vendors and integrators, builds little custom technology, and focuses on keeping costs low. This is less an archetype than a diagnostic: if the description fits your job, the problem may be the company’s relationship with technology, not your capability.

The point is not that Visinoni’s model is superior to Nyblom’s. It is that the CTO path has legitimate branches. The ladder is real, but so are the side doors. Brockman’s career — as we are about to see — is the clearest demonstration of what happens when a CTO is self-aware enough to take one.

Greg Brockman joined Stripe in 2010, when the company had roughly five people. He designed the server architecture, built the credit card vault, and produced the internal abstractions that the company’s early product ran on. He also — organically, without planning it — accumulated responsibilities that had nothing to do with code: recruiting, culture-building, making the company’s first T-shirts. He described it later as having a strong vision of the environment he wanted to be part of, and being willing to do whatever was needed to create it.^[1]

By 2013, the accumulation had become the job. He was spending his time on one-on-ones, recruiting, and organisational shaping. The Tuesday burnout cycle was the symptom, but the underlying condition was structural: the role he had grown into was, in all but name, the VP of Engineering role. He had not set out to become a people manager. The company’s growth had drafted him into it.

He faced what he described as a choice between the technical route and the people route. His answer was candid: he had never found anything he loved more than writing code.^[1] Rather than force himself into a role that drained him, he hired someone who wanted it. After 18 months of meeting professional managers, Brockman found Marc Hedlund, who went through a four-day interview process of back-to-back one-on-ones with all 25 engineers. Once Hedlund was in place, Brockman transferred his one-on-ones. Then recruiting. Then he looked at what was left and realised the role he had developed organically was almost entirely the standard VP Engineering role.^[1]

The delegation itself taught him something. He identified two approaches that work: delegate completely, or stay involved in all the details for one area. What does not work is what he called "sparse micromanagement" — jumping in to a random issue, overturning all the decisions, and then disappearing. That, he said, is universally the worst approach.^[1] Sparse micromanagement is the default behaviour of a CTO who has delegated in theory but not in practice — who has hired a VP of Engineering but cannot resist second-guessing. It corrodes trust faster than never delegating at all, because it is unpredictable. The team never knows which decisions are theirs and which will be reversed.

With management off his plate, Brockman expected a role vacuum. He went on what he called a "CTO vision quest," interviewing roughly 20 CTOs and VPs of Engineering about how they defined their jobs. He went in expecting every CTO to be the chief architect. To his surprise, he found only one who was. Everyone else saw themselves as facilitators of the technology organisation — coordinators, connectors, enablers — not the person writing the most important code.^[1]

This finding challenged a deep assumption. The engineer who becomes CTO typically assumes that being CTO means being the best and most important engineer. The vision quest data said otherwise. For 19 out of 20 CTOs, the role was organisational, not architectural. The one exception proved that the architectural CTO exists — but as a rare variant, not the default.

Brockman chose his own path anyway. He identified four ways to know what is happening in an engineering organisation: doing the work, talking to many people, observing the work, or planning the work. He realised he was doing none of them.^[1] He chose the first. He went back to code.

The insight he drew from the experience became one of the most cited observations in CTO practitioner literature: "It’s not about time management, it’s about energy management. It’s important to find activities that recharge you (independent of leverage) so that you have the energy to deal with the high-leverage draining stuff."^[1]

In 2015, Brockman co-founded OpenAI. The genesis was a dinner in August 2015 — Elon Musk, Sam Altman, Ilya Sutskever, Brockman, and others. The first office was Brockman’s apartment. The team showed up on January 4, 2016.^[9]

His initial role was instructive. He described it as doing whatever was needed to remove all non-research tasks from Sutskever’s plate. When Sutskever and John Schulman needed a whiteboard, Brockman got them one. This was the Coder stage stripped to its essence — not writing code yet, but clearing the path for the people who would. When engineering became a bottleneck on research, he and Sutskever swapped roles. Brockman went back to the code and built the Gym library, then Universe.^[9]

At OpenAI, he found a repeatable pattern that had first emerged at Stripe: focus single-mindedly on the software, shut out all distractions, work from wake until sleep. He operated on a block-time basis — a single meeting would kill productivity for an entire morning or afternoon. His rule: restrict meetings to early morning or after lunch, no more than three per day, no meeting blocks more than every other day.^[9] This was not anti-social behaviour. It was a CTO who understood the stage he worked best in, designing his schedule to stay in it.

His closing line in the 2017 blog post that described this arc: "What my role will look like from here, I have yet to define fully. I’m too busy coding."^[9]

The arc continued. In November 2023, the OpenAI board ousted Sam Altman; Brockman quit in solidarity; both were reinstated days later. In August 2024, Brockman took a sabbatical — his first in nine years.^[10] He returned in November 2024 as President, focused on key technical challenges, at a company now valued at $157 billion with 500 million weekly ChatGPT users.^[11] [REVIEW: Brockman’s current role and OpenAI’s valuation should be verified at time of publication — the situation was volatile through 2024.]

Mapped against Nyblom’s stages, Brockman’s trajectory is unusual. He moved from Coder (Stripe 2010–2013) to Manager (the Tuesday burnout period) to the threshold of Director (hiring the VP Engineering, doing the vision quest) — and then deliberately reversed. He never fully entered the Strategist stage. At OpenAI, he returned to the Coder stage and did his most impactful work from there.^[1][9]

Paul Graham’s 2024 essay "Founder Mode" — which argued that conventional management wisdom pressures founders into delegating too much, too early — maps onto Brockman’s experience.^[12] Brockman’s Tuesday burnout was the failure mode Graham describes: a technical founder forced into full management mode by the sheer growth of the company. The VP Engineering hire was the correction — not retreating from leadership, but finding the structure that let him lead from where he had the most impact.

But the neat version of this story — "follow your energy, stay in the code" — is too simple. Chad Dickerson, former CEO of Etsy, has argued that founder mode only works for an exceptional few with the right conditions, and that without those conditions it becomes an excuse for bad behaviour.^[13] Noam Wasserman of Harvard has made the complementary point: founders who excelled at the early stages but lack what the next stage demands may be the ones who drive the company into the ground.^[13] Brockman’s return to code worked because he was self-aware about his strengths and because he hired the right person to cover his gaps. Without Marc Hedlund, the story ends differently.

The lesson is not "stay in the code." The lesson is that the four-stage model is a map, not a mandate. Some CTOs will progress through every stage. Some will find their optimal stage and stay there. Some will oscillate. The variable that predicts success is not how far up the ladder you climb. It is whether you understand which stage you are in, which stage the company needs, and whether those two things match.

CTO coach Viktor Nyblom reports that the transitions between stages are usually where his clients reach out to him — not the stages themselves.^[6] The data supports this. Adelina Chalmers, who has spent more than a decade helping startups secure investment, found that most founding CTOs are fired or moved sideways within three to five years.^[14] The reasons are specific and consistent.

At the Coder-to-Manager transition, the failure is identity. The CTO cannot stop coding. They built the system, they know it best, and writing code still feels like the most valuable thing they can do. Jarjoura’s oracle trap operates here: the CTO becomes the single point of knowledge, answering every question rather than building documentation and processes that distribute knowledge across the team.^[3] Hiring is delayed because the CTO believes they can still do the work of two or three engineers. Delegation is resisted because — as Brockman admitted — engineers struggle to distinguish "not the way I’d do it" from "bad."^[1]

At the Manager-to-Director transition, the failure is scale. The CTO is managing 50 people the way they managed 15 — through direct relationships, individual one-on-ones, and personal involvement in technical decisions. Nyblom is precise: the tools that used to work no longer work.^[6] The CTO needs to hire a VP of Engineering, build a management layer, and start leading through leaders rather than through individuals. Those who resist this transition become the organisational bottleneck at the exact moment the company can least afford one.

At the Director-to-Strategist transition, the failure is communication. This is where Chalmers’ data cuts deepest. The founding CTOs who were replaced or sidelined were seen by their boards as arrogant, as alienating the board with jargon, as failing to talk about the business outcomes of technology, as telling the board "you have to trust me" without ever making a business case, and as consistently under-delivering with no explanation or mitigation plan.^[14]

Cooke identified the same pattern from a different angle. He listed five failure modes facing later-stage CTOs: under-communicating technical challenges to non-technical colleagues, saying "no" too often, failing to transition to long-term planning, making poor senior hiring decisions, and failing to make effective use of their time.^[2] He traced all five to two root causes.

The first: not knowing fellow leaders — the CMO, the CRO, legal — well enough to understand what they need. Cooke’s recommendation was specific: meet with the CMO to support a conference, meet the CRO to understand the sales cycle, support legal on IP strategy. Build relationships with the management team as deliberately as you once built relationships with your engineering team.^[2]

The second root cause is subtler and more consequential: misunderstanding the needs of the company as it scales. Board meetings shift from product and engineering to sales and marketing as revenue grows. CTOs who interpret that shift as marginalisation have misread the room. Cooke offered a framework that deserves attention: as you build a company, you are generating predictability where it did not exist. Predictable growth leads to predictable revenue, which leads to predictable sales, which leads to predictable product, which leads to predictable engineering, which leads to predictable hiring.^[2] The board’s attention follows the predictability frontier — whichever function is the least predictable gets the most scrutiny. Early on, that is the product and the technology. Later, it is sales and go-to-market. The CTO who takes this personally — who sees reduced board attention as reduced value — has confused visibility with importance. Engineering is not less valued. It has become more predictable. That is a success, not a demotion.

The pattern across all three transitions is the same. The CTO optimised for the current stage’s demands and did not see the next stage’s demands approaching until they were already being evaluated against them. The transitions are not surprises — they are triggered by company growth that is visible months in advance. But they require the CTO to do something that is genuinely hard: give up the skills that made them successful and invest in skills they have not yet proven they can develop.

The mechanism is worth naming precisely, because it explains why smart, capable people fail at transitions that look obvious in hindsight. At each stage, the CTO’s value comes from a specific set of activities. At the Coder stage, value comes from writing code. At the Manager stage, from building and coordinating teams. At the Director stage, from setting strategy and hiring leaders. The activities that create value at each stage are not merely different from those at the previous stage — they are often in direct tension with them. The CTO who continues to write code at the Manager stage is not just failing to manage; they are actively competing with their own team for the work the team was hired to do. The CTO who continues to manage individuals at the Director stage is not just failing to set strategy; they are undermining the managers they hired by refusing to let them manage.

Each transition, in other words, requires the CTO to stop doing the thing they are best at and start doing something they have never done. The identity cost is real. The competence cost is real. And the only way to learn the new skills is to practise them before they feel natural — which means performing visibly worse at the new job than you were at the old one, for a period measured in months, while the company continues to grow and the board continues to evaluate.

Chapter 10 of this book examines the business acumen gap — the communication failures that Chalmers documented — in full. For now, the point is narrower. The stages are predictable. The transitions are predictable. The failure modes at each transition are predictable. What is not predictable is whether any given CTO will see the transition in time.

The most useful thing this chapter can give you is a diagnostic. The stages are not abstractions — they are observable conditions with specific indicators.

You are in the Coder stage if you write code most days, spending 70% or more of your time in the codebase. Your team is under 15 people. You are the primary decision-maker on stack, architecture, and technical direction. You handle customer support escalations personally. There are no engineering managers between you and the developers.

You are in the Manager stage if your coding time has dropped to somewhere between 10% and 40% and is still falling. Your team is 15 to 45 people, with sub-teams forming. You spend significant time on one-on-ones, hiring, and process. You review pull requests but cannot review all of them. Original team members may be feeling disconnected from the broadening organisation.

You are in the Director stage if you rarely write production code — less than 10% of your time. Your team is 45 to 250 people. You manage managers, not individual contributors. You have hired or need to hire a VP of Engineering. Security, compliance, and cross-team communication are major concerns.

You are in the Strategist stage if you do not write code. Your organisation exceeds 250 people. You lead directors with their own budgets and hierarchies. Your decisions operate on multi-year time horizons. Your primary challenge is maintaining innovation pace against growing bureaucracy.

The transition warning signs are more diagnostic than the stages themselves:

I have been in the Manager stage twice. The first time, I helped build Ready Set Rocket, a digital agency, from seven people to more than 50 — the full arc from a team small enough to fit around one table to one large enough that sub-teams formed, process became necessary, and the people who had joined when everyone knew everything started to feel the distance. The second time is now, at CorralData, where I am CTO of a healthcare B2B SaaS company scaling from $3 million to $6 million ARR. The transitions were familiar the second time — I recognised the oracle trap faster, knew earlier when to stop reviewing every pull request, felt the Manager-stage gravity pulling me away from code with less surprise. They were not painless. Recognition and pain are compatible.

I have also seen the later stages from the inside, though not from the CTO seat. At Codecademy, as an Engineering Manager, I watched the Director-stage challenges play out at close range: the shift from managing individuals to managing managers, the introduction of process that the early team resented, the growing gap between what the engineering organisation was doing and what the rest of the company understood about it. At the New York Times — a 3,000-person company with an engineering organisation of 500 to 1,000 people — I was a Senior Engineering Manager on the Storylines team. The Strategist stage at full scale looked different from anything the startup world prepares you for: multi-year planning horizons, budget politics, and an immense distance between strategic decisions at the top and the engineer’s daily experience at the keyboard.

I have not held the CTO title at every stage. But I have been inside the building at each one — not as an observer, but as someone whose work depended on understanding the stage the organisation was in. The model maps to real companies, with real friction at the boundaries.

The disorientation you feel — if you feel it — is not personal. The role changed. Not your competence. The job you were hired to do, or the job you assumed when you co-founded the company, has been quietly replaced by a different job with different success criteria. You are not bad at your job. Your job is new. And it will be new again in 18 months.

The stages are the map. But a map does not explain how you got to the trailhead. Most startup CTOs did not plan this career. There was no CTO track at university, no certification programme, no gradual apprenticeship. They were the best engineer — or the only engineer — and the title followed. The absence of preparation is not their personal failure. It is the universal condition. And what that accidental entry does to the person holding the title turns out to shape everything that follows.