Chapter 2: CTO by Accident
may my mind stroll about hungry and fearless and thirsty and supple and even if it’s sunday may i be wrong for whenever men are right they are not young
may my heart always be open to little
Vadim Kravcenko was a senior software engineer at a small Swiss startup when the Head of Development had a disagreement with management and left. Kravcenko pushed hard for the role — five long meetings to convince the leadership team he could handle it. He got the title. And then: "I felt out of place and didn’t really know what to do, as I was always a dev, so it took me quite a bit of time to really understand what I needed to be doing."[1]
David Mack, co-founder and CTO of SketchDeck, a Y Combinator-backed startup, describes the same disorientation from the other direction — not a battlefield promotion but a founding role that nobody defined. "Founding a startup is an upside-down version of traditional employment," Mack writes. "Initially you’ve no idea if the company will take off nor if it’ll ever turn into a full-time job, then as it grows you keep on being thrust into new and different jobs. You can accumulate responsibility faster than you can learn how to harness it."[2]
These two accounts — the developer promoted into the CTO chair overnight, and the founder who drifted into the role as the company grew around them — represent the two most common paths to the startup CTO title. Neither involves preparation. Neither involves training. Neither involves a moment where someone sits the new CTO down and explains what the job actually is.
This chapter is about that absence — the fact that almost nobody who holds the CTO title at a startup was ready for it, and that this is not a personal failing but the universal condition of the role.
Three Paths, No Map
The research reveals three distinct ways people become startup CTOs. None of them involves applying for the job.
The first is co-founder default. The startup has two founders: one who handles the business, one who handles the technology. The business founder becomes the CEO. The technical founder becomes the CTO. The decision is made in a conversation that takes less time than most architecture reviews. Stephan Schmidt, who has coached more than 80 CTOs, calls this "often the worst way to move forward."[3] His reasoning: "The role of the CTO changes a lot over a short amount of time. From an individual contributor writing code, to a DevOps person, to a process person, to a hiring manager, to a manager of managers — often the first one in the company, with no guidance and help, to a strategy person in the first twenty months. The chance that your first hire can make the journey is slim — and the decision to make that hire CTO feels random."[3] Schmidt adds the practical warning: "Giving a title is easy, taking the title away is difficult. Giving a child a lollipop is easy, taking it away is impossible without drama. Same here."[3]
The second path is battlefield promotion. The previous technical leader departs — through burnout, co-founder conflict, or a better offer — and the most senior remaining engineer steps up. Kravcenko’s experience is the archetype. One day he was writing code and submitting pull requests. The next, he was responsible for the team, the architecture, the hiring, and the relationship with the CEO. "Sadly you will not be able to work alone anymore," Kravcenko reflects. "The whole workflow of getting a task, doing the task, submitting the job for review without zero human interaction is gone."[4] The stress, he discovered, was categorically different from anything he had experienced as a developer: "If you think you had stress when you couldn’t fix a bug or couldn’t finish enough tasks during a sprint, think again. Now you will be the shield for your developers, so everything negative to your team will go to you."[4]
The third path is growth overtaking. The CTO did not change. The company did. Mack describes this trajectory: the startup grows, the team grows, and the CTO who was effective at five people discovers that the job at fifteen people is a different job — one that involves hiring, firing, process design, and people management rather than code. "Stepping aside from pure technical decisions, the life-blood of being a CTO is people management," Mack writes. "The majority of your day-to-day will be managing, leading, hiring and firing people. I’ve had to learn all of this on the way and it certainly could have been smoother."[2]
CTO Academy, a training organisation founded to address the preparation gap, identifies two archetypes of the accidental CTO: "the tech founder of a fast growth start-up who quickly finds that growth is outsprinting his or her skill set" and "the senior developer who has been rapidly promoted ahead of schedule but without the necessary rounded skills to cope."[5] The common thread: "They can feel out of their depth and the imposter syndrome looms large as they’re suddenly in the spotlight."[5]
Mostafa Khattab, who was rapidly promoted to CTO at Wakecap Technologies in Dubai, kept a diary of the experience. His account captures the psychological weight that arrives with the title: "The real psychological impact was knowing that now I was responsible for everything and of course, I was also now responsible for everyone in these technical teams." His response was the one that most accidental CTOs default to: "I worked all the day and night, a big mistake, I was leading by day and coding by night which was the cause of mistakes and a real strain on my mental and physical health."[6] The pattern — attempting to do the old job and the new job simultaneously, sleeping less rather than delegating more — is the accidental CTO’s first and most dangerous instinct. It works for weeks. It fails within months.
Kravcenko identifies the specific habit that the new CTO must break: "Desire to do everything yourself. Of course, you can do it better. Of course, you can do it faster. But your time is limited, and other more critical tasks at hand need to be prioritized."[4] The engineer’s core strength — the ability to solve problems personally, by writing the code — becomes the CTO’s core liability. Every hour the CTO spends solving a technical problem is an hour not spent on the activities that only the CTO can perform: hiring, communicating with the CEO, designing the team structure, and making the architectural decisions that will constrain the system for years.
|
AUTHOR: Your path to CTO at CorralData — which of the three patterns does it most resemble? Was the title part of the founding agreement, or did it emerge as the company grew? What was the moment you realised the job was different from what you expected? |
No Training, No Precedent
When Andy Skipper founded CTO Craft in 2017, he began by interviewing CTOs about their experience entering the role. "Speaking to several members of the forum about their experience as new CTOs, it’s no surprise that almost all felt thrown in at the deep end and were given responsibility for anything and everything — even things they weren’t good at."[7] When he asked how much formal training they had received, "the resounding answer was none."[7]
The practitioners Skipper interviewed confirmed the pattern independently. Harel Malka, founder of Glow Digital Media, described the CTO transition as "a rollercoaster of a learning curve — mainly, letting go, delegating and understanding that the CTO role can be like the three blind men feeling an elephant story — everybody sees things differently." Alistair Stead, CTO of Kamet, said he needed "a framework of support to help me identify the places to focus my efforts and show progress."[7] Marcus O’Connell, a freelance CTO, wanted "guidance and discussion on relevant best practices for technical leadership and development processes, perhaps access to other experienced CTOs to discuss ideas with."[7] Each was describing the same void from a different angle: there was no map, no curriculum, and no community.
The answer should not be surprising, but consider what it means. The CFO has accounting credentials. The CMO has a marketing background. The General Counsel passed the bar. The CTO — the person responsible for the technology that the entire business depends on, the team that builds it, and the architecture that constrains its future — has no equivalent qualification, no standard curriculum, and no professional body that certifies readiness. The CTO arrives in the role with whatever they happened to learn as an engineer, and discovers on the job that engineering was the smallest part of what the role demands.
Will Larson, who has held engineering leadership roles at Digg, Uber, Stripe, Calm, and Carta, names the systemic problem: "Software engineering management, particularly in Silicon Valley, is exceptional for how inexperienced the typical manager is, and how little training we provide for this critical role."[8] His own experience was representative: "I first started managing in a vacuum, quickly becoming the only engineering manager in a struggling startup, and making it up as I went. I was a terrible manager, and I’m grateful for the folks who put up with me during that period."[8]
Camille Fournier, former CTO of Rent the Runway, frames the gap as a definitional problem. "The challenge with defining CTO is that if you look across the folks who hold that title you will see many different manifestations. Some are the technical cofounders. Others were the best of the early engineers. Some focus on the people and processes of engineering. Others focus on the technical architecture, or the product roadmap. Some CTOs have no direct reports, others manage the entire engineering organization."[9] The role has no standard definition because it has no standard preparation. Each CTO invents the job from scratch, inheriting whatever the previous occupant left behind — or, more commonly, starting with a blank page.
Fournier’s most important insight for this chapter: "CTO is not an engineering role. CTO is not the top of the technical ladder, it is not the natural progression for engineers over the course of their careers to strive to achieve."[9] The engineer who becomes CTO has not been promoted. They have changed careers — from building systems to leading an organisation that builds systems. Schmidt puts it with characteristic directness: "This isn’t a promotion — it’s a career change."[10]
Larson, writing the preface to his 2024 book The Engineering Executive’s Primer, identifies the specific moment when the training gap becomes most acute: "As an engineering manager, you almost always have someone in your company to turn to for advice: a peer on another team, your manager, or even the head of engineering. But who do you turn to if you’re the head of engineering?"[8] The question is not rhetorical. The CTO who has a problem with no obvious solution — a failing architecture, a co-founder conflict, a team that is not shipping — has no internal escalation path. The CEO does not understand the technical dimension. The board does not understand the day-to-day reality. The engineering team cannot be told that their leader is unsure. The CTO is, for the first time in their career, truly alone with the problem.
Kravcenko captures what the career change feels like from the inside: "As a software engineer, I imagine you were never taught the art of taking things under control and delivering a product, at least I didn’t learn this at university. It was mostly about bits and bytes and writing assembly by hand."[11] His solution — the same solution that every accidental CTO discovers — was to learn on the fly: "Most of the stuff in the series comes from my personal encounters with the issues described. I had to learn things on the fly."[11]
|
AUTHOR: Your preparation — or lack of it. Did your AI background at Manchester prepare you for the CTO role, or did it prepare you for a different job entirely? What was the biggest gap between what you knew and what the role required? |
Who Holds This Job
The CTO population is narrow in ways that matter for both the reader and the industry.
Zippia’s analysis of more than 8,600 CTO profiles in the United States finds that 92% are men and 76% are white, with an average age of 51 at established companies.[12] At startups and scale-ups, the population skews younger — CTO Craft’s 2023 survey of 600 global engineering leaders found 55% aged 36 to 45, with 23% aged 46 to 55.[13] Korn Ferry’s analysis of the top 1,000 US companies found that women hold fewer than one in five CIO or CTO roles.[14] At European venture-backed startups, the numbers are starker: a 2018 Atomico study found just one female CTO out of 175 at VC-backed European tech companies.[13]
These numbers describe a population that is overwhelmingly white, male, and in their late thirties to mid-forties. They do not describe a population that should be overwhelmingly white, male, and in their late thirties to mid-forties. The CTO Craft 2024 compensation survey reveals one consequence of this narrowness: male CTOs received 2.3 times the equity cash value of female CTOs — a gap that compounds over the lifetime of a startup.[13] The EEOC’s 2024 analysis of the high-tech workforce found that the representation of Black workers at 7.4% was "virtually unchanged from 2005 to 2022."[15] The pipeline is not fixing itself.
The gap between who holds the CTO title and who could hold the CTO title is one of the industry’s most consequential structural failures — and the "accidental CTO" pattern is part of the mechanism. When the CTO is chosen by default (the most technical co-founder), by battlefield promotion (the most senior remaining engineer), or by growth overtaking (the person who was already there), the selection criteria are proximity and seniority, not capability. The people with proximity and seniority in most tech companies are, overwhelmingly, white men. The path to the CTO role was never designed. It was inherited — and the inheritance reflects the demographics of who was already in the room.
The educational profile reinforces the pattern. Zippia finds that 64% of CTOs hold a bachelor’s degree and 21% a master’s — but the Stack Overflow Developer Survey shows that 49% of developers learned to code at school, while 82% rely on online resources.[16] The CTO role requires skills — people management, board communication, financial literacy, organisational design — that are not taught in computer science programmes and are rarely acquired through self-directed online learning. The accidental CTO is not just unprepared for the role. They are unprepared in ways that their education and career path did not equip them to recognise.
The reader of this book is statistically likely to fit the demographic profile described above. The responsibility that comes with fitting the profile is to recognise it as a structural artefact, not a meritocratic outcome — and to build a team and a culture, as Chapter 11 will describe, that does not reproduce the same pattern.
|
AUTHOR: Your perspective on the demographics of the CTO role — as someone who studied AI at Manchester and came to the role through journalism-adjacent data work and startup experience. Does the demographic profile match your experience of the CTO community? What does the narrowness of the population mean for the healthcare vertical specifically? |
The Loneliness Starts Here
Schmidt, writing from his experience coaching CTOs, identifies a feature of the accidental CTO’s experience that most guides overlook: the isolation begins immediately. "Nobody talks about CTO loneliness," he writes. "`It’s not in the job description. It’s not in the leadership books. But when I coach CTOs, it comes up constantly. Not in the first session. Usually by the third or fourth, when trust is built. ‘I feel completely alone in this.’`"[17]
The loneliness is structural, not personal. Schmidt traces its mechanics: "Before being a CTO, they could talk to peers about their problems, they could bubble up problems they could not solve to their boss. The CTO is the first position they could get fired because the CEO just lost trust — not because of their performance. Political games set in — and you’re alone."[17] The engineer who became CTO has lost their peer group (they now manage their former peers), lost their escalation path (there is no one above them to absorb technical problems), and gained a set of concerns — about the business, about the board, about the co-founder relationship — that they cannot share with their team without creating anxiety.
Schmidt’s formulation captures the paradox: "You speak a different language. Half your job is translation. Explaining technical reality to people who don’t want to hear it. Explaining business constraints to engineers who think product is the enemy. You’re the bridge. Bridges are lonely places."[17] The imposter syndrome, he notes, is a rational response to the situation: "Most CTOs got here through technical excellence. Now you’re doing a job you were never trained for. Managing people, navigating politics, presenting to boards. Every day feels like a test you didn’t study for. And you can’t admit it."[17]
Chapter 15 will address the loneliness and burnout dimensions in depth. Here, the point is simpler: the isolation is not a sign that the CTO is doing something wrong. It is a structural feature of a role that sits at the intersection of technical, business, and people challenges with no natural peer group inside the company. Knowing this from the beginning — naming it before it becomes a crisis — is the first act of self-preservation.
Schmidt describes the feedback loop that connects isolation to burnout: "It starts with overwhelm. Too many decisions, too many people, too many fires. You work longer hours to keep up. The longer hours cut into relationships. Fewer relationships means less support. Less support means more stress. More stress means more burnout. The cycle accelerates."[17] His warning: "Most CTOs who burn out don’t see it coming. They’re too busy coping to notice the pattern."[17]
Schmidt’s own path into the CTO role illustrates the absurdity of how the title is often acquired. "I started in the 90s in an internet startup as a developer. After some time, my boss told me to hire more students — so I became a manager. When I had to go to a trade fair and talk to Oracle and IBM, I asked my boss for a business card to look more professional, and a job title. He told me to choose one."[10] The accidental CTO is not a modern phenomenon. It is as old as the startup itself.
|
AUTHOR: Your experience of isolation in the role — even briefly. Did it arrive immediately or build over time? Is the "bridge" metaphor accurate to your experience of translating between the technical and business dimensions at CorralData? |
The accidental CTO is the norm, not the exception. The person who arrives in the role prepared — with management training, leadership experience, a clear understanding of the job’s scope, and a peer network to draw on — is the rarity. The rest of us learn on the fly, making mistakes that feel personal but are structural, experiencing isolation that feels unique but is universal, and carrying a title that describes a job nobody fully defined before handing it to us.
This book is the playbook that does not exist. Chapter 1 provided the map — the four stages of the CTO’s evolution. This chapter has named the starting condition: you are here, you were not ready, and almost nobody else was either. Chapter 3 addresses the first and most consequential challenge of the role: the relationship with the person who gave you the title.