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? |
Before You Sign
The moment before you accept the CTO role is the moment of maximum leverage. Every term you fail to negotiate now becomes a term you will wish you had negotiated when the relationship changes — when the VPE is hired above you, when the board composition shifts, when the company is acquired and your unvested equity is on the table.
The first principle is non-negotiable: the company’s lawyer is not your lawyer. José Ancer, a startup attorney, states it with an analogy that should end the discussion: "The family therapist does not represent one spouse or the other. She represents the family, as an entity." The company’s counsel represents the entity — the corporation — not the founders as individuals.[17] Naval Ravikant, founder of AngelList, is blunter: "Don’t just go with the lawyer that the VCs insist upon. These lawyers will work with the VC on a hundred financings and with you on only one."[18] Hire your own employment attorney. The cost to review a startup employment agreement or offer letter is typically $750 to $1,250 for a flat-fee review, rising to $3,000–$5,000 if negotiation support is required.[19] This is the best investment you will make in the entire role.
What to negotiate depends on whether you are a co-founder or a hired CTO. The structures are different and the leverage is different.
For the co-founding CTO: the equity split is the first conversation. Y Combinator’s advice is that equal splits are usually the right answer: "This is a case where the simple solution — to just split it equally — is probably the best one." Michael Seibel adds the diagnostic: "If you aren’t willing to give your partner an equal share, then perhaps you are choosing the wrong partner."[20] Wasserman’s research shows that 73% of founding teams set the equity split within a month, most of them permanently — and premature splits are among the most common and most consequential mistakes founders make, because they "tend to plan for the best that can happen" and assume early commitment levels will persist.[21] Beyond the split: establish a founders' agreement that covers reverse vesting (four-year, one-year cliff is standard), IP assignment, decision-making authority, a conflict resolution mechanism, and termination provisions. The UPenn Law Entrepreneurship Clinic provides a free annotated template that covers all of these.[22] Do not skip the conflict resolution clause. You will need it.
For the hired CTO: think in percentages, not share counts. Mary Russell of Stock Option Counsel advises: "Think of yourself as a late-stage founder and negotiate for a specific percentage ownership in the company."[23] Appendix C provides the benchmarks: a hired CTO at Series A typically receives approximately 1.0% (Index Ventures data), with a four-year vesting schedule and one-year cliff. The critical negotiation points beyond the equity number are: double-trigger acceleration (partial or full vesting if the company is acquired and you are subsequently terminated — investors prefer double-trigger over single-trigger, so push for it early); an extended post-termination exercise period for vested options (the standard 90 days is insufficient for ISOs with AMT exposure; negotiate for 12 months or longer); severance terms (six to twelve months of salary and benefits, triggered by termination without cause or constructive dismissal); and the scope of any non-compete and non-solicitation clauses.[24]
For both: negotiate the title-authority gap. The CTO title without authority over technical decisions, hiring, and architecture is a title without a function. Define in writing — in the offer letter, the employment agreement, or the founders' agreement — what decisions the CTO owns, what budget authority they hold, and what their reporting relationship is. The CTO who accepts a title on a handshake and discovers six months later that the CEO makes all technical decisions has accepted a role that does not exist.
Vadim Kravcenko, who writes the "No-Bullshit CTO Guide," provides the equity benchmarks for the gap between the two scenarios: a CTO working for no salary should expect 25–35% (co-founder level); a CTO at full salary, up to 5%; a CTO at 50% salary, between 7% and 15%.[25] The numbers scale with risk. The CTO who takes below-market compensation is making an investment, and should understand the implied value of that investment using the framework in Appendix C.
|
AUTHOR: What you negotiated when you joined CorralData — or what you wish you had negotiated. The reader who is about to accept a CTO role for the first time needs to hear from someone who has done it, including the things you got wrong. If there were terms you did not negotiate that you later wished you had, those are the most valuable sentences in this section. |
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.’`"[26]
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."[26] 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."[26] 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."[26]
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."[26] His warning: "Most CTOs who burn out don’t see it coming. They’re too busy coping to notice the pattern."[26]
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.
Frequently Asked Questions
-
How do people become startup CTOs?
Most startup CTOs arrive through one of three paths — co-founder default (you were the technical one), battlefield promotion (the company grew and you were the most senior engineer), or growth overtaking (you joined as a developer and the startup expanded around you). Formal preparation for the role is extremely rare. The accidental CTO is the norm, not the exception.
-
What is an accidental CTO?
An accidental CTO is someone who received the title without formal leadership training or deliberate career planning for the role. They were typically the best or only engineer at a startup, and the title followed the responsibility. This is the overwhelmingly common origin story — most CTOs did not set out to become CTOs, and the absence of preparation is the universal condition, not a personal failing.
-
Do you need a computer science degree to be a CTO?
No. While many CTOs have technical degrees, what matters far more is adaptability, willingness to learn beyond engineering, and the ability to grow with the company. The CTO role demands skills — people management, business communication, strategic thinking — that no computer science programme teaches. Self-taught developers, bootcamp graduates, and career-changers have all become successful CTOs.
-
What is the typical background of a startup CTO?
The typical startup CTO was a senior engineer or technical co-founder who got the title because they were the most technical person in the room when the company was small. They usually have strong hands-on engineering skills but limited formal management or leadership training. The role finds them rather than the reverse, and their first year as CTO is spent learning a job nobody fully defined before handing it to them.
-
Can a software engineer become a CTO?
Yes — in fact, most startup CTOs were software engineers first. The challenge is not the starting point but the growth required. Moving from engineer to CTO means developing skills in hiring, team management, business communication, board presentations, and strategic planning. The engineers who make the transition successfully are those who recognise early that the CTO role is a leadership position that happens to require technical knowledge, not a senior engineering position with a better title.