Chapter 3: The Relationship That Defines Everything

Adelina Chalmers, a consultant who coaches CTOs and advises boards under the name "The Geek Whisperer," has spent more than a decade studying why founding CTOs get fired. Her conclusion, drawn from working with dozens of CTOs and interviewing their investors, is consistent and specific: "CTOs got fired: 30% because they were NOT strategic. 70% because they could NOT communicate with the board and other non-technical stakeholders. 100% did NOT get fired because of their technical skills."^[2]

The failure modes she identifies are not personality flaws. They are communication patterns that emerge when a technically oriented person is placed in a business relationship without preparation for the translation work it requires. The CTOs who were fired were seen as "`arrogant — showing disdain towards board and ELT members who were non-technical; alienating the board with geek speak; not talking about the business outcomes of tech; and saying to the board things like ‘You have to trust me’ without ever making a business case.`"^[3] Chapter 10 will address the communication skills in depth. Here, the concern is the relationship dimension — how these patterns develop between the CTO and the CEO specifically, and why they are structural rather than personal.

The CEO-CTO relationship contains at least three built-in tensions that do not require anyone to behave badly to produce conflict.

The first is the expectations mismatch. Fred Wilson, co-founder of Union Square Ventures, describes the standard startup trajectory: "The ideal web/mobile startup will have a CEO/founder who will also wear the VP Product hat. It will have a technical co-founder who will wear both the CTO and VP Eng hats."^[4] In the early days, this works. The technical co-founder builds the product, manages the small team, and makes the architectural decisions. But as the company grows, the role splits — and the split reveals a mismatch that was invisible when one person was doing everything. Wilson’s observation is direct: "It is very rare to find a person who can do both the VP Eng and CTO jobs at the same time. They require very different skills and very different time allocations."^[4]

Mark Suster, a venture capitalist who was twice a startup founder, identifies the CEO’s contribution to this mismatch: "The problem that many inexperienced startup CEO’s make is confusing these people for the people who lead the technology team. Most often they are not. Your deepest thinkers on technology architecture are seldom good team leaders."^[5] The CEO who expects the CTO to be both the visionary architect and the day-to-day engineering manager is setting up a conflict that will surface when one of those functions starts failing — which it inevitably will, because they require fundamentally different skills and fundamentally different uses of time. Suster’s formulation is blunt: "CTO’s max out at about 3 direct reports. Remember, management is often a hassle for CTO’s, not a sign that you respect them by giving them people who report to them."^[5]

The second tension is power asymmetry. Chalmers captures this with a diagnostic that should make every CTO uncomfortable: "`If your CTO gets 5 minutes to give the ‘tech update’ at SLT that everyone glazes over, yet you spend 1+ hours on other things from other departments, you don’t have a CTO.`"^[2] The technical co-founder who holds the CTO title but is treated as a senior developer — consulted on implementation but excluded from strategy — is experiencing a power imbalance that will produce resentment, withdrawal, or both. Camille Fournier, former CTO of Rent the Runway, names the structural version of this problem: "The CTO who does not also have the authority of management must be able to get things done purely by influencing the organization. If the managers won’t actually give people and time to work on the areas that the CTO believes are important, the CTO is rendered effectively powerless."^[6]

The third tension is the implementation-arm dynamic — the CEO who goes directly to engineers with pet projects, bypassing the CTO entirely. Chalmers documents this as the single most common way founders sabotage their own engineering organisations: "A CEO or COO or some co-founder goes directly to an engineer or a specific group of engineers with a pet project and asks them to drop everything and work on this now. They cut across everyone and everything — the CTO or VP Engineering is not informed and the founder basically ignores all processes, rules or hierarchies involved."^[7] The CEO who does this is not being malicious. They are reverting to the behaviour that worked when the company was five people and the fastest way to get something done was to ask an engineer directly. The behaviour that scales at five people becomes organisational sabotage at fifty.

Esther Perel, the therapist and relationship expert who has worked extensively with co-founding pairs, identifies three hidden categories beneath most co-founder fights: power and control, care and closeness, and respect and recognition. The surface argument — about a feature priority, a hiring decision, a strategic direction — is rarely about the thing itself. It is about one of these underlying dynamics.^[8]

The power dimension manifests as: "Technical and non-technical co-founders argue over who is more essential to the company. Whether it’s the engineer building the product or the sales and marketing whiz running the business, these discussions about who’s working harder or adding more value often boil down to a question of who needs who more."^[8] The CTO who feels that the CEO could not function without the technology — and who resents that this dependency is not acknowledged — is operating in the power dimension.

The care dimension manifests as exclusion. Perel’s diagnostic question cuts to the heart of it: "I often ask co-founders this telling question: What hurts you more? The fact that they did it in the first place — or that they did it without you? The former is an issue of power, the latter is an issue of care and closeness."^[8] The CTO who discovers that the CEO made a strategic decision in a board meeting without consulting them is not angry about the decision. They are hurt about the exclusion.

The respect dimension manifests as invisibility. The CTO whose contributions are not recognised in board meetings, whose technical achievements are attributed to "the team" while the CEO’s sales achievements are attributed to the CEO personally, is experiencing a respect deficit that will eventually surface as cynicism or withdrawal — two of the three dimensions of burnout that Chapter 15 will address.

Tan’s experience at Posterous illustrates how these dynamics compound: "Success will cover up many sins. When things are going up and to the right, things might be going wrong underneath and you won’t be aware of it. It’s the black ice of startups."^[1] The co-founders who never fought during the growth phase are not conflict-free. They are conflict-deferred. The debt accumulates invisibly and comes due when the company hits its first serious challenge.

Rachel Lockett, a coach who has worked with co-founders at Pinterest and Stripe, provides a case study that captures the compounding dynamic: "The CTO confided in me that he planned to go to the board and kick out the CEO because he was no longer a fit for his role. These two people were good friends from college." When Lockett investigated, she discovered that the CEO hated his own role — he missed being technical and was depleted by board management and team leadership. "When you’re not honest about how you’re growing," Lockett observes, "it’s on your co-founder to be the person to tell you."^[9] The CTO who was preparing a boardroom coup was actually dealing with a co-founder who needed a role change — but neither had the language or the structure to surface that conversation before it became a crisis.

Tom Blomfield co-founded Monzo, the UK digital bank, as CEO. His co-founder and CTO, Jonas Templestein, built the technical infrastructure. By all accounts, their relationship was strong — Blomfield credits Templestein as "even more passionate" about culture than he was.^[10] The co-founder dynamic was not the problem. The role was.

Blomfield’s account of his departure is the most detailed founder-burnout narrative in the UK startup ecosystem: "I stopped enjoying my role probably about two years ago, as we grew from a scrappy startup that was iterating and building stuff people really love, into a really important UK bank. The things I enjoy in life is working with small groups of passionate people to start and grow stuff from scratch."^[11] The CEO role at a scaled company — regulatory burden, board management, process design, crisis communication — had nothing to do with the builder identity that brought Blomfield to the role. "When you get to that size, it’s about people management. You spend almost no time on product or customers really. It’s about process, a lot of process, extraordinary amount of regulation."^[12]

When COVID hit in March 2020, a funding round collapsed, revenue dropped 50% in one week, and the pressure became unsustainable. "I wasn’t sleeping, which impacted my decision-making, I was anxiety-wracked and never switched off from work."^[10] Blomfield stepped down as CEO, took a transitional role, and eventually walked away from roughly four million unvested shares. His assessment in retrospect: "As CEO, I never switched off. I found it impossible to stop thinking about the latest problem."^[13]

The Monzo story matters for this chapter not because the co-founders fought — they did not — but because it illustrates what happens when one partner in the relationship is destroyed by the role itself. The CTO who watches their CEO co-founder burn out is losing their most important professional relationship, their strategic partner, and their buffer against the board — simultaneously. The CTO who does not notice the CEO’s burnout, or who notices it but does not have the relationship infrastructure to address it, will discover the problem only when the CEO announces their departure.

Blomfield had an earlier experience that is more directly instructive. Before Monzo, he was CTO at Starling Bank under CEO Anne Boden. He lasted six months: "I just thought, I can’t work with this person — it’s really damaging to me and my mental health — and so I resigned."^[14] The Starling departure was a classic CEO-CTO conflict — a relationship that could not sustain disagreement. The Monzo departure was something different: a relationship that worked until the role consumed one of the partners. The CTO needs to understand both failure modes.

Sam Altman, speaking from his experience as president of Y Combinator, states it plainly: "In YC’s case, the number one cause of early death for startups is cofounder blowups."^[15] Paul Graham, co-founder of YC, lists "fights between founders" among his eighteen mistakes that kill startups and offers the analogy: "Cofounders are for a startup what location is for real estate. You can change anything about a house except where it is."^[16]

Noam Wasserman’s research, based on roughly 10,000 founders across 6,000 US tech and life sciences startups, provides the quantitative foundation. Eighty-four percent of startups have co-founders. Seventy-three percent of founding teams split equity within one month of formation, most setting it in stone with no mechanism for adjustment. And a finding that should concern every co-founding pair: each additional social relationship in the founding team — a friendship, a family connection, a prior working relationship — increases the likelihood of a co-founder’s departure by 30% after the initial honeymoon period.^[17] The teams with the deepest personal bonds are, after six months, the least stable. The closeness that made them co-found together becomes the emotional intensity that makes disagreement feel like betrayal.

Wasserman’s most cited finding — that 65% of startup failures are caused by people problems — deserves a caveat. The statistic originates from a 1989 survey of 49 venture capitalists by HBS professor William Sahlman, measuring VC perceptions of failure causes rather than a direct empirical measurement.^[18] The figure is useful as a signal of how investors think about startups — and investors who believe that people problems are the primary failure mode will intervene accordingly, which shapes the reality even if the original data is perception-based.

The CB Insights analysis of 101 startup post-mortems provides a complementary view: "not the right team" ranks as the third most common reason for failure at 23%, behind "no market need" (42%) and "ran out of cash" (29%).^[19] Mark Suster provides the practitioner’s version: "I promise you, for as great as you feel about your current partnership agreement — I meet far more people who had problems with theirs than founders who didn’t have problems. People just don’t talk about it publicly."^[20]

The CTO who cannot say no to the CEO will burn out. The CTO who says no without translating it into business terms will be fired. The space between these two failures is where the CTO must learn to operate.

Jeff Bezos’s "disagree and commit" principle, formalised in his 2016 letter to Amazon shareholders, provides the foundational framework. The principle works in both directions: the CTO should commit to the CEO’s decision after expressing disagreement, and the CEO should commit to the CTO’s recommendation in their area of expertise. Bezos’s own example: he greenlit an Amazon Studios project he personally doubted, writing back to the team: "I disagree and commit and hope it becomes the most watched thing we’ve ever made."^[21] The principle only works if both parties practice it. The CEO who expects the CTO to disagree and commit but never reciprocates is running an autocracy, not a partnership.

Cedric Chin, writing about the practical difficulty of executing this principle, identifies the failure mode that most CTOs fall into: publicly undermining the decision they disagreed with. He cites Andrew Bosworth of Meta: "Many leaders sell out their management and rally the team. They say management sucks, but don’t worry, we will make progress in spite of them. This approach is staggeringly effective. Until it isn’t."^[22] The CTO who disagrees with the CEO’s direction and then signals that disagreement to the engineering team — through tone, through body language, through the conspicuous absence of enthusiasm — is poisoning the execution of a decision they committed to support. Chin’s resolution: express disagreement clearly, ask for the CEO’s reasoning, then commit genuinely and execute. And know that there is a point at which the only honest response is departure: "Staying when you can no longer commit is a disservice to yourself, to your company, and to the subordinates who might not share your views."^[22]

Evan Cooke, technical co-founder of Twilio, provides the practical reframe that makes "no" productive rather than adversarial. Instead of blocking a request, the CTO translates it: "Well, here’s what that would take — what do you think?"^[23] The sentence turns a gate into a negotiation. The CEO who hears "no" hears obstruction. The CEO who hears "that would take six weeks and require postponing the billing feature" hears a trade-off — and trade-offs are the language of business.

Bezos adds one more principle that applies directly to the CEO-CTO dynamic: teams should "recognize true misalignment issues early and escalate them immediately." His warning: "The default dispute resolution mechanism for this scenario is exhaustion. Whoever has more stamina carries the decision."^[21] The CTO who loses arguments not because the CEO was right but because the CTO ran out of energy to fight is experiencing the exhaustion mechanism. The antidote is escalation — to a board member, to an advisor, to the structured conversation that the next section describes.

Tan’s central lesson from Posterous applies to every co-founder pair: "Most people think of good co-founding pairs in purely functional terms — a business person paired with a technical person. This is deeper than that."^[1] The functional complement — one builds, one sells — is necessary but insufficient. The relationship requires maintenance, and most co-founding pairs do none.

Amy Buechler, a founder coach referenced by Y Combinator in its official co-founder guidance, developed the "Founder Sync" — a recurring, protected meeting dedicated entirely to the co-founder relationship. "One of the things that’s surprised me in my coaching work is how often cofounder conflict is not because of a failing relationship, but because of a lack of process — a lack of routine, built-in collaboration. Founders mistake their bad relationship habits for a bad relationship."^[24]

The Founder Sync covers six areas: alignment on strategy, existential threats, accountability, bidirectional feedback, management support, and trust. Buechler recommends 60 to 90 minutes weekly. "Psychologically, Founder Syncs are soothing. Their consistency relieves anxiety."^[24] The CTO who has a structured weekly conversation with the CEO about the state of the relationship — not the state of the product, not the sprint review, not the fundraise update, but the relationship itself — is building the infrastructure that prevents Tan’s crisis from developing.

Lockett reinforces the principle: "People think if they don’t argue, they have a healthy relationship. That just means there’s a lot going unsaid and resentment is building. You need healthy conflict to make good decisions."^[9] The structured conversation creates a container for that healthy conflict. Without it, the conflict either goes underground (producing withdrawal and resentment) or erupts unpredictably (producing the crisis that Tan described).

Matt Munson, a two-time founder who coaches co-founding teams, recommends a three-step process for periodic deeper check-ins: journal independently on a set of alignment questions, swap answers before meeting, then schedule two to three sessions of 60 to 90 minutes to discuss where answers diverge or surprise. The output: a one-page alignment document that captures shared values, role boundaries, decision-making rules, and what each person is willing to sacrifice.^[25] His assessment of the cost of skipping this work: "Every hour you spend exploring values on the front end will save you 10+ hours down the line."^[25]

Y Combinator publishes its own set of ten questions for co-founders, including: "How will we split up equity? What will our roles and titles be? What will we do if we’re having trouble agreeing? What happens if we decide we don’t want to work together anymore?"^[26] The fact that Y Combinator — which has seen more co-founder relationships than any other institution — considers these questions essential enough to publish as a checklist suggests that most co-founding pairs have not asked them. The CTO who has not had an explicit conversation about equity split, role boundaries, and conflict resolution mechanisms is operating without the equivalent of a vesting schedule for the relationship: no structure, no milestones, and no exit clause.

The CEO-CTO relationship is the startup’s first architecture. Like any architecture, it can be designed deliberately or it can emerge by default. The default version works when the company is small, the problems are technical, and the co-founders are in the same room solving them together. It breaks when the company grows, the problems become political, and the co-founders discover that the functional complement — one builds, one sells — is not enough to sustain a partnership under pressure.

The CTO who understands the structural tensions (expectations mismatch, power asymmetry, the implementation-arm dynamic), who can diagnose what co-founder fights are actually about (power, care, or respect), who has learned to say no in business language rather than technical language, and who maintains the relationship through structured conversation rather than crisis management — that CTO has built the foundation for everything this book describes. The operational chapters (Part II), the business acumen chapters (Part III), and the personal survival chapters (Part IV) all rest on this foundation. Without it, every framework in this book is an abstraction. With it, the CTO has a partner — and a partnership is the only structure strong enough to survive what comes next.