Chapter 10: You’re Not Being Fired for Your Code
Most companies don’t die because they are wrong; most die because they don’t commit themselves. They fritter away their valuable resources while attempting to make a decision. The greatest danger is in standing still.
Only the Paranoid Survive, 1996
A CTO at a company of roughly 3,000 people had spent nine months trying to get his board to approve several million pounds of investment in a product redesign. Nine board meetings. Nine presentations. Nine versions of "no." He had the technical analysis. He had the risk assessment. He had the engineering plan. He had, by any reasonable measure, the right answer.
Adelina Chalmers, an executive advisor who has coached hundreds of engineering leaders over 13 years, reviewed his presentation and saw the problem within three minutes. The slides described embedded firmware, open-source software licensing, and architectural dependencies. The board was not evaluating a technical decision. They were evaluating a business risk — and the presentation gave them no language for it.[1]
Chalmers helped the CTO reframe the proposal in three dimensions: risk to the business if the redesign did not happen, impact on sales if it did, and impact on customer retention and acquisition. At the next board meeting, the CTO received full approval for every pound he had requested. The board’s response, as Chalmers recounted: "This is very different than everything you’ve told us in the last nine months."[1]
The CTO in that story was not incompetent. He was not arrogant. He was not failing technically. He had the right answer for nine months. What he did not have was the language to make the board see what he saw.
That gap — between what the CTO knows and what the CTO can communicate — is the single most common reason founding CTOs lose their jobs.
The Evidence That Converges
The technology industry circulates a statistic: roughly half of all founding CTOs are replaced by Series B. The figure sounds precise. It is not. The source traces to an unsourced practitioner newsletter.[2] A related claim — that 70% of venture capitalists have replaced a founding CTO at least once — cites a publication that does not appear to exist.[3]
No rigorous, methodologically transparent study measures founding CTO replacement rates by funding stage. This is a gap in the literature, not a gap in reality. What exists instead is something more revealing: a convergence of independent sources — practitioners, academics, and investors who have never cited each other — arriving at the same conclusion about why CTOs fail.
The closest empirical analogue comes from Noam Wasserman, a Harvard Business School professor who studied more than 3,600 startups and roughly 10,000 founders. His finding: 52% of founder-CEOs are no longer in the CEO role by the company’s third financing round. Of those replacements, roughly 80% are involuntary — the board made the decision, not the founder.[4] Wasserman’s research covers CEOs specifically, not CTOs, but the mechanism he identifies applies with particular force to technical co-founders: the skills that build the product are not the skills that communicate its value. The paradox is that success accelerates the problem. Completing product development shifts the company’s needs from building to scaling, and each funding round brings new board members who evaluate the founder’s capacity to operate at the next stage — not the current one.
Thomas Hellmann and Manju Puri, studying 173 Silicon Valley startups, reached a complementary conclusion: venture capitalists drive a "professionalization" process that systematically replaces founders with professional managers. The replacement is not driven by failure. It is driven by the structural fact that scaling requires organisational management and communication skills that founding does not develop.[5] Michael Ewens and Matt Marx, in the first study to establish a causal (rather than merely correlational) relationship between founder replacement and startup performance, analysed 11,929 VC-backed firms and found that replacing founders actually improves company outcomes — particularly when the replaced founder is a C-level executive who leaves entirely.[6]
Practitioners who advise CTOs directly confirm the pattern. AKF Partners, a technology advisory firm that has worked with approximately 500 companies over 17 years, names the specific failure mode. In their analysis of CTO terminations, they identify business acumen as "by far the most common reason for failure for chief technologists raised through the technical ranks." The pattern: the CTO’s peers complain that they do not trust the executive, citing a “failure to present opportunities, fixes, and projects in ‘business terms.’” AKF estimates that nearly 50% of senior technology executives are at-risk with their C-suite peers at any given time.[7] Their 2024 analysis adds data on tenure: CTO tenures average three to 5.5 years in the United States, with the most frequent termination reason being "a failure to build trust with the remainder of the executive team."[8] Heidrick & Struggles’ 2024 global survey of 364 digital and technology officers — a category that includes CTOs, CIOs, and CDOs — found that 45% have been in their current role for five or more years, but the turnover pressure is real: CTO Craft’s 2025 survey found 41% of engineering leaders are currently considering leaving their roles.[9]
Chalmers, working independently from a coaching practice focused on engineering leaders, identifies the same pattern from a different angle: "After talking to so many of them and their investors, I realised that there was a business acumen gap between the CTO and the board. This gap became more and more obvious as the company grew."[10] She catalogues three specific displacement patterns: the board asks the CTO to change their title to Chief Scientific Officer or Chief Architect so they can hire "a commercial CTO who’d be seen in a favourable light" by later-stage investors; the board asks the CTO to split their role into two, with a new hire handling the external-facing responsibilities; or the board asks the CTO to become "a technology advisor to the new commercial CTO."[11] Each pattern preserves the CTO’s employment while removing their authority — a slower death than termination but the same underlying cause.
Evan Cooke, co-founder and CTO of Twilio, a cloud communications platform, through its 2016 IPO, identified the same dynamic from inside the role. Speaking at First Round Capital’s CTO Summit, he named under-communicating critical technical challenges to the non-technical parts of the business as the first of five CTO failure modes: "They unintentionally leave people in the dark."[12]
Etienne de Bruin, founder of 7CTOs, a peer coaching organisation for technology executives, arrived at the conclusion through personal experience. He was fired in 2018. "I lost my job," he wrote, "because I confused being right with being understood. They’re not the same thing."[13]
Stephan Schmidt, who has coached more than 80 CTOs across three decades in software development, frames it as a structural requirement: "The CTO needs to be the bridge between business and technology, with one foot in business and the other foot in technology. Only the CTO can be that bridge."[14]
These are six independent sources — an advisory firm, a CTO coach, a public-company co-founder, a peer network founder, another CTO coach, and an academic researcher — spanning hundreds of years of combined experience across thousands of companies, none referencing each other, all converging on the same diagnosis. The founding CTO’s greatest risk is not a technical failure. It is a translation failure.
|
AUTHOR: A moment from your own experience belongs here — a board meeting where a technical initiative was misunderstood, a conversation with an investor where the wrong language was used, or an observation about how CorralData’s board dynamics have required translation skills you did not initially have. Even a brief anecdote establishes that the author is inside this problem, not above it. |
Five Ways CTOs Lose the Room
The business acumen gap is abstract. Its symptoms are specific. Five failure modes appear across the practitioner literature with striking consistency.
Jargon as a shield. The CTO presents technical work in technical language — embedded firmware, microservices, refactoring sprints — and the board hears noise. In Chalmers’ nine-month case study, the board was alarmed by the mention of open-source software — not because they opposed it, but because the CTO had never translated the licensing model into an intellectual property risk assessment. They heard "open source" and thought "who owns this?"[1] Schmidt provides the clearest before-and-after of this failure: "’`We need to refactor the authentication module’ means nothing to the CEO. ‘We’re spending 30% of engineering time working around problems in our login system, and it’s caused two outages this quarter’ — that they understand.`"[15] Jargon is not intentional exclusion. It is the CTO’s native language. The problem is that nobody told them to learn a second one.
"Trust me" without a business case. The CTO asks for investment — headcount, infrastructure, time — and when pressed for justification, retreats to authority: you have to trust the technical team. Chalmers names this explicitly: CTOs who insist the board trust them "without ever making a business case."[10] AKF Partners reports the board-side version of this complaint: the CTO “overly focuses on what is ‘cool’ rather than the things that create significant business and stakeholder value.” The executive peers’ formulation is blunter: "We don’t get why there are so many people working on things that don’t drive revenue."[7]
Under-delivery without explanation. Projects slip. Deadlines pass. The CTO does not explain why, does not warn in advance, and does not present a mitigation plan. Chalmers: "chronically under-delivering with no explanation, warning or proactive plans to mitigate the risk of not delivering."[10] This pattern erodes trust faster than the technical failure itself. A board can absorb a missed deadline. What a board cannot absorb is being surprised by one. The CTO who flags a risk three months before it materialises has built trust. The CTO who announces a delay the day before launch has destroyed it.
Losing relevance as the company scales. Cooke observed this at Twilio: "Board meetings that used to involve hours of product and engineering discussions instead start to focus on sales and marketing or strategy."[12] The CTO who experiences this shift will instinctively interpret it as marginalisation — the board is pushing engineering aside. The reality, Cooke argues, is that the company’s problems have changed. The board’s attention follows the least predictable function. If sales is the constraint on growth, the board will focus on sales. The CTO who fights for airtime instead of understanding what the new priorities need from engineering has misread the room.
The Alpha Geek pattern. The CTO hoards the most interesting technical work, allocates themselves the hardest problems, and treats engineering excellence as the primary measure of their value. Chalmers describes CTOs who "saw themselves as the Alpha Geek in the room who has all the answers, but not as a leader who guides people to find the answers considering the business case."[16] This is the terminal failure mode — the CTO retreating to the identity that feels safe (coding, architecture, technical depth) as the role demands something they have not learned (communication, delegation, strategic alignment). It connects directly to the stage-evolution model from Chapter 1: the Coder-stage CTO’s greatest strength becomes the Manager-stage CTO’s greatest liability.
These five patterns are not separate problems. They are five symptoms of one condition: the CTO is operating as a technologist in a room that requires a business executive. And they are progressive. Jargon and "trust me" arrive first — they are the communication habits of someone who has never needed to justify technical decisions to non-technical people. Under-delivery without explanation follows — it is what happens when the CTO has not built the communication rhythm that makes engineering predictable to the business. Losing relevance is what happens when the CTO does not understand why the company’s problems have changed. The Alpha Geek pattern is the terminal stage: the CTO retreating to the identity that built the company because the identity the company now requires feels like a demotion.
The progression matters because it means the gap is visible long before it becomes fatal. A CTO who catches themselves using jargon in a board presentation is seeing an early warning. A CTO who notices that the CEO no longer asks for engineering updates is seeing a later one.
Fred Wilson, a venture capitalist at Union Square Ventures who has been involved with more than 150 startups, provides the reframe that makes these patterns bearable. The founding CTO who cannot scale with the company is not a bad hire. They are a successful one. "You are firing someone for doing their job too well," Wilson writes. "They killed it and in the process got your company off to a great start and growing to a scale that they themselves aren’t a great fit for."[17] He identifies the most common founder error as excessive loyalty: sticking too long with a founding team member whose skills no longer match the company’s stage, because the personal relationship makes the conversation impossible.
Ben Horowitz, co-founder of Andreessen Horowitz, offers a diagnostic for the board member’s perspective: "If you have somebody who’s really doing the job, they’re teaching you about how the function should expand. If you’re giving them more ideas than you’re getting out, then that’s probably not going to work."[18] That test — whether the CTO is teaching the CEO about engineering’s needs or whether the CEO is telling the CTO what engineering should do — is the clearest signal of which side of the gap the CTO is on.
|
AUTHOR: Has the author recognised any of these patterns in themselves at CorralData — even briefly? One or two sentences of honest self-recognition would be the most powerful passage in this section. |
Why the Gap Is Structural, Not Personal
Telling a CTO to "learn business" is like telling someone to "be taller." It identifies the deficit without addressing the cause. Three structural forces create the business acumen gap in founding CTOs. Understanding them is the first step toward closing it.
The CEO gets the reps. The CTO does not. Jerry Colonna’s Reboot.io, which runs co-founder coaching programmes, identifies the single most important structural explanation. The CEO role forces board communication practice. The CTO role does not. In their framing: "The built-in requirements of the CEO position forces a growth that may not come otherwise: she has to pitch, do board meetings, etc. There are these things she must learn. Scaling is not optional. The non-CEO founder, who may or may not go on the pitch meetings for raises, may be there for board meetings but not put the deck together, is responsible for certain things but not the company as a whole in the same way the CEO is."[19]
By the time a startup reaches Series B, the CEO has delivered dozens of investor pitches, run quarterly board meetings for two or three years, and negotiated term sheets with sophisticated financial operators. The CTO may have attended some of those meetings, but they did not lead them. They did not build the slides. They did not field the hard questions about unit economics and runway. The CEO’s board communication skill was forged through thousands of hours of mandatory practice. The CTO’s was not — because the role never demanded it. The gap is not about talent or intelligence. It is about repetition. And unlike a technical skill, where the CTO can practise on their own time, board communication requires a counterparty: an actual board, with actual power, asking actual questions. The CTO who does not seek out that practice deliberately will not get it by accident.
Success triggers the replacement. Wasserman’s research reveals a paradox that most founding CTOs find counterintuitive: founders are replaced not primarily because they fail but because they succeed. Product development completion shifts the company’s needs from building to scaling. Each funding round brings new board members who evaluate the founder’s capacity to operate at the next stage, not the current one.[4] The CTO who built the product that attracted Series A investors will be evaluated by Series B investors on whether they can manage 50 engineers and present a technology strategy to a board — skills that writing the first version of the product did not develop and may have actively worked against. The intense focus, the bias toward building over communicating, the impatience with process — these are virtues at the founding stage. They become liabilities at the scaling stage. Hellmann and Puri frame the dynamic as a "professionalization" imperative: VCs do not replace founders out of malice. They replace them because the organisational requirements have changed and the founder has not changed with them.[5]
The technical identity resists the executive identity. The CTO was hired to build. Their professional identity, their sense of value, their credibility with the engineering team — all of it is rooted in technical depth, problem-solving, and the ability to write code that works. The executive role requires something different: breadth over depth, communication over construction, delegation over execution. Mark Suster, a VC at Upfront Ventures, states it plainly: "The best technologists often aren’t amazing people managers. Sometimes they are introverts."[20] Camille Fournier, former CTO of Rent the Runway, frames the identity requirement that most founding CTOs have never heard stated explicitly: "The CTO is an executive first, a technologist second."[21] Most founding CTOs have the order reversed. Nobody told them to flip it, and the role — unlike the CEO’s — does not force the flip.
The Alpha Geek pattern from the previous section is the defensive response to this identity threat. When the role demands communication and the CTO’s identity is built on coding, the CTO retreats to code. It feels productive. It feels like the work they were hired to do. But it is the wrong work — and the deeper the retreat, the wider the gap grows. Peter Levine, a general partner at Andreessen Horowitz, describes the preferred outcome of what he calls the "founder re-org": the technical co-founder moves to an individual contributor role — CTO, architect, evangelist — while someone with management experience takes over the scaling work.[22] But this outcome requires the CTO to accept that their highest-impact contribution has changed. That acceptance is not a management skill. It is an act of self-awareness — and it is the same skill that separates the CTOs who survive from the CTOs who are replaced.
|
AUTHOR: The author’s own reflection on this structural gap would ground the argument. Did the CEO at CorralData develop board communication skills faster? Is there a moment where the author recognised the exposure differential and decided to compensate for it deliberately? |
The Board Meeting Translator
The gap is structural. The remedy is practical. No comprehensive framework for translating technical work into board-ready language exists in the current literature — a gap this section fills by synthesising the advice of practitioners who have each solved a piece of the problem.
Reframe every initiative as a business investment. The CTO who says "we need to refactor our authentication system" is making a technical request. The CTO who says "we’re spending 30% of engineering capacity working around a system that has caused two customer-facing outages this quarter — resolving it frees that capacity for the feature pipeline and eliminates a reliability risk that is costing us renewals" is making a business case. The content is identical. The language is not.
Chalmers’ method is to translate every technical proposal through three lenses: what is the risk to the business if we do not do this? What is the impact on revenue if we do? What is the impact on customer retention and acquisition?[1] Apply these three questions to the nine-month board presentation and the answer is obvious — the CTO had the analysis for all three, but he presented the technical rationale instead. Chalmers also recommends a diagnostic question that every CTO should ask their non-technical executive peers: "What metric are you measuring that engineering can help you improve?"[23] This single question shifts the CTO’s relationship with every other department from "what do you need us to build?" to "what business outcome can we improve together?"
Speak in outcomes, not outputs. Engineering-native metrics — velocity, code coverage, sprint completion rates — have no meaning outside engineering. David Subar, a technology leadership consultant, states it directly: "Velocity is completely the wrong thing to discuss with CEOs."[24] The board does not care how many story points the team completed. The board cares about three things: where is engineering capacity going, is the investment producing business results, and what are the risks. Will Larson, in The Engineering Executive’s Primer, provides the conceptual frame: the CEO "manages through inspection" — they want the CTO to measure something, set a goal, and share progress against that goal. Execution against goals is a proxy for engineering leadership quality.[25]
The translation is concrete. "We completed 47 story points this sprint" becomes "the feature pipeline is on track — the three features committed for this quarter are at 70%, 50%, and 30% completion respectively." "We reduced our CI pipeline time by 60%" becomes "engineers can now ship a fix to production in 18 minutes instead of 45, which means customer-reported issues are resolved the same day instead of the next." "We paid down technical debt in the authentication module" becomes "we eliminated the system that was causing two outages per quarter and consuming 30% of backend engineering time." The information is the same. The frame is different. And the frame determines whether the board sees an engineering team doing engineering or an engineering team producing business value.
The CTO who presents DORA metrics to a board that has never heard of DORA has confused the measurement with the message. The metrics work from Chapter 9 is the raw material. The translation is the skill this chapter teaches.
Build predictability. Cooke’s framework, developed during his time as CTO of Twilio, provides the connecting logic between engineering work and business confidence. "As you build a company," he writes, "you’re essentially generating predictability where it didn’t exist."[12] He constructs a chain: predictable growth requires predictable revenue, which requires predictable sales, which requires predictable customer acquisition, which requires a predictable product delivered predictably — which requires predictable hiring and retention. The CTO’s job in the boardroom is to demonstrate that engineering is a source of predictability, not a source of surprises. The velocity infrastructure from Chapter 6, the metrics from Chapter 9 — these are not just engineering tools. They are the evidence of predictability. When the CTO presents them as such, the board sees an executive who understands how their function connects to the business.
Cooke’s insight extends further, and it resolves one of the most common emotional injuries CTOs experience during scaling. He observed at Twilio that when board focus shifted from product to sales, the engineering-first CTO felt marginalised. But the shift followed a logic: the board’s attention goes to the least predictable function. If engineering has become predictable — if the CTO has built the infrastructure, the metrics, and the communication rhythm that make it so — the board’s attention will move to wherever predictability has not yet been established. That is not marginalisation. It is success. The CTO who understands this reframes the loss of board airtime from a threat to a signal that their work is landing. The CTO who does not understand it fights for relevance in a room that has already granted it.
Over-communicate bad news. Brad Feld, a venture capitalist and co-author of Startup Boards, states the principle: "There should never be any new information shared during a board meeting and you should never be selling to your board."[26] The CTO who presents a surprise problem in a board meeting has already lost the room — not because the problem is unsolvable, but because the surprise signals that the CTO either did not see the risk coming or did not trust the board enough to share it. Both interpretations erode confidence.
The inverse is equally powerful. The CTO who flagged a risk in an email two months ago, shared a mitigation plan one month ago, and is now presenting the outcome — whether it resolved or escalated — has built the most durable form of board trust: reliability. The content of the update matters less than the pattern. A board that knows the CTO will surface problems early can absorb bad news. A board that suspects the CTO is hiding problems cannot absorb any news at all — because every positive report becomes suspect.
This is the inverse of failure mode three. Chalmers’ "chronically under-delivering with no explanation" is what happens when the CTO does not follow Feld’s principle. The remedy is not better project management. It is a communication habit: flag early, update regularly, present mitigation alongside the problem.
|
AUTHOR: A specific example of translating a CorralData initiative — ideally a before/after — belongs here. "Here is how I would have presented our AI copilot migration as a technical project. Here is how I presented it as a business investment." This is the section where the working-CTO authority is most directly at stake. |
Leaving on Your Own Terms
The chapter has spent four sections naming a problem and a remedy. This section addresses the question the reader has been silently asking: what if it is too late — or what if the remedy succeeds, and the CTO faces a different question altogether?
William Hockey co-founded Plaid, a financial data infrastructure company, in 2012 during his senior year at Emory University. He served as CTO while the company grew to a $2.65 billion valuation and roughly 300 employees. In June 2019, he published a public essay titled "Transitions" — a word that founding CTOs rarely use voluntarily.[27]
Hockey had planned his departure over approximately two years. His method was deliberate: he gradually removed himself from day-to-day projects, tested whether teams could operate without him, and stepped in only when the test revealed gaps that needed closing. He described it to the Plaid team in an internal letter: "Over the past couple of years I have known that there would come a point at which I would choose to move to a purely strategic and advisorial role. And during the past year, I have started to work towards this goal."[27] His benchmark for knowing the transition was ready: "If I’ve done my job well, the following weeks, months, and quarters shouldn’t feel any different for anyone."[27]
The essay itself was an argument for normalising what the industry treats as a taboo: "In tech, it has historically been taboo to talk about founders or executives transitioning to different roles inside companies. Leadership transitions need to become a bedrock of any company that desires to endure across decades."[27] Hockey’s statement was not a resignation letter. It was a precedent — a public declaration that a founding CTO choosing to leave is not a failure but a leadership act. He framed the founder’s job in terms that echo this chapter’s argument: "As a founder, I believe it is my job to empower everyone who works at the company — sometimes this means holding multiple roles throughout the lifecycle of one’s company."[27] He subsequently founded Column, a nationally chartered bank that powers fintech infrastructure. By early 2026, Column had reached roughly $200 million in revenue with 110 employees and no outside funding.[28]
Renaud Visage offers the other model. He co-founded Eventbrite, an event ticketing platform, in 2006 and served as CTO for 15 years — surviving every growth stage from founding through IPO and beyond. His method was not to cling to the CTO role as conventionally defined. It was to continuously reinvent it. Every six months to a year, he identified "whatever was the biggest hurdle to our growth that I could solve with a small team" and moved himself there.[29] He did not protect a title. He did not hoard management authority. He prioritised impact over position. His advice to other founding CTOs: "Find your value inside a growing organization. It’s more important to be fulfilled and work on things you really enjoy rather than keeping a title for posterity’s sake and being miserable every day."[29]
Hockey and Visage represent two valid outcomes: leaving on your own terms, and staying on your own terms. Both require the same underlying skill — self-awareness about where you add the most value, and honesty about when that answer changes. Brockman’s arc, traced in Chapter 1, is the same pattern at a different scale: he recognised that management was not where he had the most impact, and he returned to engineering. The form of the choice varies. The skill behind it does not.
|
AUTHOR: The author’s own reflection belongs here — not a confession, but an honest acknowledgment that the question applies personally. What keeps you at CorralData? What signals do you watch for? How do you think about the possibility that the role may outgrow you — or you may outgrow it? |
The business acumen gap does not close when the CTO survives a board meeting. It closes when every decision the CTO makes — about architecture, about hiring, about where to invest the team’s time — is informed by both technical judgment and business fluency. The velocity infrastructure from Chapter 6 is a business acumen investment. The metrics language from Chapter 9 is a business acumen investment. The scope discipline from Chapter 6, the non-negotiables from Chapter 7, the stage-awareness from Chapter 1 — all of these were foreshadowing a single skill: the ability to translate between what the engineering team builds and what the business needs to hear.
The CTO who masters that translation has solved the survival problem. The next problem is leverage: you cannot build the team the company needs if you cannot articulate what that team should be — in language the business understands — and defend those decisions against the pressure to hire fast, hire cheap, and fill seats.