Introduction: The Role Nobody Prepared You For

The startup CTO role is the most consequential and least understood position in the technology industry. Nearly 80% of successful technology companies have either a founding CTO or a technical CEO.^[1] The CTO builds the product that the company sells, hires the team that builds the product, designs the architecture that constrains the product’s future, and translates between the engineering organisation and the business leadership that funds it. Every other function in the company — sales, marketing, finance, operations — depends on what the CTO’s team produces.

And yet. No standard training exists for the role. No professional certification. No established curriculum. When Andy Skipper founded CTO Craft in 2017 and asked CTOs how much formal preparation they had received, "the resounding answer was none."^[2] Seventy percent of CTOs come from software development backgrounds, and only 14% held a VP of Engineering role before taking the title — most arrive without prior experience leading an engineering organisation at the executive level.^[3] The CFO has accounting credentials. The General Counsel passed the bar. The CTO has whatever they happened to learn as an engineer, and discovers on the job that engineering is the smallest part of what the role demands.

The role transforms completely every 18 to 24 months. The CTO who was effective at five engineers discovers that the job at twenty engineers is a different job — one that requires hiring skills, process design, and cross-functional communication rather than code. The CTO who mastered the twenty-person team discovers that the job at fifty people is different again — organisational architecture, board communication, and strategic planning. Each transformation requires the CTO to let go of the skills that made them successful at the previous stage and learn a new set of skills they were never trained for, often without a mentor, a peer group, or even a clear description of what the new stage requires.

The result is predictable. Noam Wasserman’s research on more than 10,000 founders shows that 52% of founder-CEOs are replaced by their third financing round, with nearly three-quarters of those replacements being involuntary.^[4] No equivalent large-scale study tracks founding CTOs specifically, but the structural dynamics — a role that transforms faster than the person holding it, a board that evaluates business outcomes rather than technical quality, a co-founder relationship that compounds unresolved tension — apply to every founding executive.

Adelina Chalmers, a CTO advisor who has coached dozens of startup CTOs over more than a decade, provides the most specific data on why CTOs are replaced. Her finding, drawn from working with CTOs and interviewing their investors: "100% did NOT get fired because of their technical skills." Instead, 70% were fired because they could not communicate with the board and other non-technical leaders, and 30% because they were not strategic enough.^[5] The core insight of this book follows directly from that finding: the thing that determines whether a startup CTO survives is not their architecture, their code quality, or their technical judgment. It is their ability to translate technical reality into business language — and their willingness to operate as a business leader, not just a technical one.

The burnout data suggests the role is taking a toll beyond career risk. The LeadDev Engineering Leadership Report 2025, surveying 617 engineering leaders, found that 22% were experiencing critical burnout and an additional 24% were at moderate burnout levels — nearly half of all respondents in the danger zone. Only 21% were categorised as healthy.^[6] The CTO Craft community survey found that 97% of CTOs reported experiencing loneliness in the role.^[7]

This book covers the full scope of the job: the technical decisions, the organisational design, the business communication, the co-founder relationship, the personal survival. It is not a DevOps manual. It is not a management theory book. It is a field guide — written by a working CTO, for working CTOs, about the actual experience of building technology companies from nothing.

This book is for three people.

The first is the founding CTO — the technical co-founder who chose the stack, wrote the first commit, and now manages a growing team while trying to maintain the architecture they built and the relationship with the CEO who depends on them. This person is in Stage 1 or 2 of the four-stage model. They are experiencing the first transition — from building to leading — and are not sure whether the disorientation they feel is a personal failing or a structural feature of the role. It is structural. Chapter 2 will make that clear.

The second is the scaling CTO — the person who has survived the early stages and is now managing managers, communicating with the board, and discovering that the job has less to do with technology and more to do with people, politics, and business strategy than they expected. This person is in Stage 2 or 3. They are effective but exhausted, and they suspect that the thing they are optimising for — engineering quality, team velocity, technical excellence — may not be the thing that determines their survival. They are correct. Chapter 10 will explain why.

The third is the CTO who is wondering whether it is time to leave — either because the role has outgrown them, because they have outgrown the role, or because the cost of staying has become higher than the cost of going. This person is in Stage 3 or 4. They need Chapter 16’s framework for departure, Chapter 15’s burnout diagnostic, and Chapter 17’s long view of what comes after.

The book is organised around a four-stage model of the CTO’s evolution, introduced fully in Chapter 1:

Stage 1: Coder. The CTO writes most of the code. The team is small — often just the CTO. The job is building the product. This is the stage that most CTOs were trained for and the stage they will spend the rest of their career grieving.

Stage 2: Manager. The CTO manages the people who write the code. The team is growing. The job shifts from building to hiring, from coding to reviewing, from solving problems to ensuring that other people can solve problems. The CTO’s calendar fills with one-on-ones. Their IDE gathers dust.

Stage 3: Director. The CTO manages managers. The team has layers. The job becomes process design, cross-functional communication, and organisational architecture. The CTO spends more time in meetings with the CEO, the board, and the sales team than with engineers.

Stage 4: Strategist. The CTO owns the technical vision and its communication to the business. The job is translation: converting engineering reality into board-level language, converting business strategy into engineering priorities, and making architectural decisions that will constrain the company for years. The CTO at this stage may not write any code at all.

Each stage requires the CTO to let go of the activities that defined the previous one. Each transition involves a kind of grief — the loss of the identity that made the CTO effective at the stage they are leaving. And each transition is a point at which the CTO must honestly assess whether they want to make the next jump, or whether the role has outgrown them — or they have outgrown the role.

The book follows this arc but is organised by problems rather than stages, so the reader at any stage can open to the chapter most relevant to their current situation.

Part I — The Map (Chapters 1–3) orients you. Chapter 1 establishes the four-stage framework. Chapter 2 normalises the "accidental CTO" experience — the fact that almost nobody who holds this title was ready for it. Chapter 3 addresses the CEO-CTO relationship, the single most consequential dynamic in the startup. Read Part I first regardless of your stage. It takes less than an hour and reframes everything that follows.

Part II — Building and Shipping (Chapters 4–9) is the operational playbook. Technical decisions as business decisions (Chapter 4). Technical debt as a strategic instrument (Chapter 5). Shipping velocity as competitive advantage (Chapter 6). Managing the pressure to move faster (Chapter 7). Working with product (Chapter 8). Measuring what matters (Chapter 9). This is the section you will dog-ear and return to. If you are in Stage 1 or early Stage 2, start here after Part I.

Part III — The Gap Nobody Talks About (Chapters 10–12) delivers the book’s core insight. Chapter 10 argues that the business acumen gap — not technical skill — is what gets CTOs fired. Chapter 11 covers building and leading the team. Chapter 12 addresses the AI transformation and what it means for the CTO’s role. If you are in Stage 2 or 3 and feel the ground shifting beneath you, this is where the book becomes different from every other engineering leadership book you have read.

Part IV — Surviving and Evolving (Chapters 13–17) addresses the personal and existential dimensions. The identity crisis of leaving code behind (Chapter 13). The operating rhythm that keeps you sane (Chapter 14). The loneliness and burnout that the role produces (Chapter 15). Knowing when to step aside (Chapter 16). Building something that outlasts you (Chapter 17). If you are in Stage 3 or 4 — or if you are at any stage and feeling the weight of the role — read Part IV. It contains the content you did not know you needed.

By the end of this book, you will have the frameworks, language, and self-awareness to navigate every stage of this role — or to recognise when it is time to hand it to someone else, and do so from a position of strength.

The role does not get easier. But the disorientation — the feeling that you are the only person who has experienced this particular combination of pressures, that there is no playbook, that nobody warned you — that part ends here. There is a playbook. There are people who have been through it. And the fact that you are reading this book means you are already doing the thing that most CTOs fail to do: treating the role as a discipline that can be studied, practiced, and improved, rather than an identity that must be performed.

The week described at the beginning of this introduction is not a failure. It is a Monday through Friday in the life of someone doing one of the hardest jobs in the technology industry. The question is not whether weeks like that will happen. The question is whether you have the frameworks to navigate them, the relationships to sustain them, and the self-knowledge to recognise when the role needs you to change — or when you need to change the role.

Let’s begin.