Two Captains, One Ship

We are happy each time we disagree, because we know we’re going to learn something new; it’s going to make some sparkle.

—Bertrand Piccard, Swiss explorer

The Late Night Slack Ping

It’s 11:47 PM on a Tuesday night and I’m trying to figure out why our database is locking up in staging when the user hits three APIs in just the right order. We have a Freckle 3rd grade math demo with a principal in two days — our biggest potential deal to date, this school has hundreds of students, many already using our free version — and I’ve been staring at logs for hours. My eyes are dry, my back hurts, and I’m making the kind of slow, methodical progress of a guy drowning in quicksand. The more I poke at the problem, the deeper I sink into confusion. But move I must: this is my first time as a technical co-founder and CTO, there’s nobody else to do the work but me and my stack of dirty coffee mugs. I really need to prove that I can cut it in this gig.

My phone buzzes. Slack notification. From my co-founder, the CEO.

“Hey, how’s it coming along? I was just now re-reading the school’s email about the demo. They’re super excited about Thursday. But, something I forgot to mention earlier: can we also show them the analytics dashboard? Their curriculum person sort of asked about it and I sort of mentioned we had one.”

I read it twice. Are you kidding me? We don’t have an analytics dashboard. He knows that! We have a page that shows three numbers: total students, weekly active sessions, and average time on task. It doesn’t filter by school, it doesn’t drill down by classroom, it doesn’t export. It is, charitably, a statistics stub I built in half a day so we’d have something to screenshot for the pitch deck.

I start typing a response. I delete it. Too defensive. I start again. Delete again. A bit passive-aggressive. The third attempt is a paragraph-long explanation of why unclogging the database matters more than dashboards right now, which is true but also completely unhelpful near midnight when the commitment has already been made.

What I want to say is: You promised something that doesn’t exist and now I have to build it in 36 hours on top of fixing the thing that’s actually broken. What I also want to say is: Why didn’t you ask me first? And underneath both of those, the thing I want to say more than anything, but definitely won’t say: Do you have any idea what I’ve been doing for the last five hours while you were having dinner?

I recognize this spiral. I’ve been here before. Every startup CTO has a version of this moment. You’re deep in the engine room, up to your elbows in grease, and someone walks over from the ship’s bridge, having already made a promise about where the ship is going next without checking whether the engine can take it. It’s not malice. The CEO is doing their job: selling the vision, keeping the district warm, being ambitious about what we can deliver. A good CEO will do that, relentlessly. It just doesn’t feel great when you’re the one who has to figure out how to “manifest it” by Thursday.

I take a deep, steadying breath. I type: “We can show them the numbers page. It’s not really a dashboard yet. How important is drill-down vs just the top-level stats?”

He responds in seconds. “Top-level is probably fine honestly, they just want to see that student usage data exists and that the principal could pull it up. Can we make it look a little more… dashboardy?”

I almost laugh. “Dashboardy” is doing a lot of work in that sentence. I can put the numbers in cards, add a dummy date range selector, maybe drag in a charting library, make it look credible. Three hours of work, maybe four. Not the end of the world once you’ve taken the time to get creative and cut the right corners for a quick ship.

“Yeah, I can clean it up tomorrow. It’ll look solid for the demo. Heads up though, the DB issue is real and I might need most of tomorrow for that. I’ll do the dashboard stuff in the evening.”

“Roger, you rock. Seriously. Let me know if you need anything.”

I put my phone down and sit with the familiar cocktail of emotions that comes with these exchanges. Mild frustration. He should have checked with me before mentioning the dashboard, or at least told me before freaking midnight. Grudging understanding; the school folks were excited, he was in the moment, and in fairness I probably would have said yes if he’d asked anyway. A tiny bit of resentment about the asymmetry: he’s going to bed, while I still have another hour ahead of me and I now have more work to do tomorrow, not less. And underneath all of it, a question that will follow me across multiple companies and multiple CEO relationships: Is this just what it is? Is this the deal?

The answer, I’ve learned over many years, is yes. This is the deal. In fact, the better the CEO, the more aggressive the pull forward towards a potential customer regardless of how ready the startup feels. It’s practically a must-have. Not the overwork part: that’s a trap for most, and one I’ll talk about later. But the fundamental dynamic where the early stage CEO is on the bridge making promises to everyone who shows the smallest hint of interest while the CTO’s team is in the engine room making them true? That’s the job. Every source of friction I’ve experienced with a co-founder — on product, on timelines, on technical decisions, on culture — grows out of the tug of war between those two roles, and their respective priorities.

It simply is not possible to eliminate that tension. It will always exist. The question is whether you tackle it with trust for each other, or whether you approach it with resentment until one of you can’t take it anymore.

The bones of a great startup CEO

As an early-stage startup’s CTO, you become a bit of an expert in all things startup CEO. It’s likely that by the time you get your first company up and running, you’ll have already tested half a dozen business co-founders. Perhaps you spent months shopping around for the perfect match on Y Combinator’s co-founder matching program, or went to startup speed dating events to find your dream B2B SaaS co-pilot. That’s a good instinct, because this is one of those roles you really want to sit on until you find a great fit. “Good enough” is fine for your twentieth software engineer, not for your business partner.

One important disclaimer here: my bias is of someone who’s been exclusively in the early-to-mid stages of VC-backed B2B SaaS companies, boutique marketing consultancies and consumer-facing indie game studios, all based around two co-founders of different skillsets going zero-to-one together. I’m always their technical counterpart. There are many other permutations of how this game can be played, but here I will talk exclusively about those that I have either personally experienced, or have seen others face in my role as their advisor.

This reads like a LinkedIn hype post, but once you’ve experienced every variation of startup CEO first-hand, you internalize how truly critical these traits are. Great startup CEOs share a few things in common. They feel the urgency in their bones. The burn rate is real to them in a way it isn’t to anyone else in the building. They anticipate their users’ needs, understanding their business workflows and consumption patterns better than the users do themselves. They’re relentlessly optimistic, and the optimism is contagious enough to carry the rest of the company through bad weeks. They pick up whatever task is sitting in the gap between roles and get it done before it becomes a problem. They have infinite patience for the Sisyphean schleps — staffing crises, re-orgs, customers churning at the worst possible moment — and they don’t let those deject them. They are sales and marketing machines, getting customers excited about what their world is going to look like after adopting your product. They rally the team around ambitious timelines that get the office buzzing with enthusiasm rather than dread.

Having a great CEO at the helm is one of the best things that can happen to a startup. And yet, without a great technical “other half” the company is unlikely to fulfill its aspirations of becoming a household name one day.

A tense coupling

The CTO/CEO pair is one of the most foundational relationships in any startup. The couple psychology of two people spending 10-16 hours a day together, weathering hard feedback and inevitable disappointments, deserves more attention than it gets. Countless stressors take their toll: personal quirks, differences in goals, watching the runway dry up, hundreds of VCs rejecting you, star employees getting poached, customers going for a competitor. It’s a miracle that any partnership can survive the ups and downs of startups, and yet this is exactly what you’re expected to do for a decade or longer of your professional career.

What follows is a tour of the dysfunctions I’ve lived through or seen up close in advisor seats, and how to navigate them before they sink the partnership.

Division of responsibility

Unless you and your co-founder have completely non-overlapping skill sets, it’s likely the two of you will step on each other’s toes at some point. The very fact that you’re working at the same company means you’re both driven to succeed and think similarly, at least in some way. When this works, it’s like a perfectly managed restaurant kitchen, both of you moving in seamless harmony to plate a delicious meal.

When things start to fray, however, it can feel like too many cooks, hurting the company’s progress and each other’s morale as you stumble over one another, breaking plates, arguing over recipes and execution details. Friction most often occurs when you each work in the same lane, ending up either accidentally repeating work, or blowing out of proportion small differences because you both have envisioned slightly different paths to the end goal. Anything subjective, such as product visual style, copy, or vibes, is fertile ground for endless evidence-free debates.

I also noticed that the more experienced the CTO, the more they want to expand their influence towards other aspects of the business. They want to impact culture, operations, the business model and product, which puts them more and more on a collision course with their non-technical counterpart, who also feels ownership of those arenas.

The same is true of technical CEOs: the more they know about code, design, architecture, the more they want to get into the implementation details. There’s good getting-in-the-weeds, where they are contributing, keeping themselves up to date with the codebase, but not imposing their opinions or criticising beyond their skills. That kind of thing is great and helpful feedback from your co-chef can be one ingredient in running an efficient kitchen. But the ones who overstep are a source of frustration.

They question your speed, the complexity cost of a ticket, why something isn’t done yet, but lack the requisite understanding to holistically judge the work. You can thank the Dunning-Kruger effect, a cognitive bias where poor performers overestimate their abilities in a skill because they lack the knowledge to assess when they are wrong or out of depth. It’s the CEOs who don’t backseat drive that tend to be easier to get along with.

My first CTO stint was the best-case scenario because, despite being pretty technical, my co-founder was happy to stay out of the way when it came to delivery. It was obvious where our respective strengths and interests resided, and we had little overlap, with one major exception: product.

The product tug-of-war

In software startups, the CEO frequently acts as the first product manager and domain expert. This doesn’t have to be the case, and I suspect you can be successful with the CTO leading product, but more often than not, the CEO is in the driver’s seat. They often are the ones with the original idea, likely the first true domain expert at the company. Or they’re the only ones with bandwidth for product management while the CTO is heads-down shipping the early bets.

Still, unless the CTO has zero opinions on the product and is purely there for delivery — which is an option, but to me the inferior one — you’ll often end up in a co-pilot arrangement, which opens the door for disagreement on everything from strategy to finances. It would be nice if every product divergence could be resolved amicably after a single objective discussion supported by data. Early on, however, you will not have the necessary facts to be informed, and will instead have to go by gut, of which you have two. Therefore, there has to be a tiebreaker when you both feel strongly about something. And if the CEO is leading product, that should be them.

I’m a fan of the disagree-and-commit approach: fight your battles, push back on what you think is meaningful, try to convince the other person, but ultimately pick a path. Once it’s chosen, stick to it with full enthusiasm. Don’t be salty about it for the rest of the project, making others’ experience miserable as your negativity not only drags them down, but becomes a self-fulfilling prophecy.

Ideally you’re not both digging in at once and you actually hear each other out. But at an impasse, someone has to call it, and if the CEO leads product, that’s them.

I can’t stress enough how important it is to pick your battles. I’ve spent countless hours debating numbers of pixels, colors, naming, copy and other stylistic choices that in retrospect had no bearing on the company’s success. These little things felt crucial in the moment; I felt like I had to win at least some of those battles so that I wouldn’t feel like I was a product pushover. In retrospect, I should have been wiser and conceded about many details that were mostly vibes-based and didn’t matter at all in the big picture.

Product isn’t the only aspect of the firm where the two top startup executives will find friction.

The culture tug-of-war

The other major source of clashing between the CEO and CTO is culture. Depending on your background and experience, you’re going to have an opinion on what a great culture looks like. If you both feel strongly about your respective answers and are unwilling to compromise, you’re going to have a lot of conflict on the culture-setting front.

Remote or not remote. How many hours we are working. What we prioritize. Meeting-heavy versus document-heavy. How we rank people. What titles we give out. What we do during offsites. How often we do them and where. How we give feedback. How we communicate. How we interview. Low documentation culture vs. meticulously writing down everything in our knowledge base.

Some of these are just logistics, but a lot of them are fundamental company DNA questions that don’t have a single correct answer for every startup. These choices exist on a spectrum and each one contributes to the overall ‘vibe’ of a company. Often if you and your partner have agreed to go into business in the first place, making that initial connection, you may have a lot in common when it comes to company culture, but if you and your co-founder have strongly opposing positions, it becomes very difficult to resolve because you both feel like you have the right answer. These clashes are why the Co-Founder Dating 50 Questions playbook is so popular in the startup community: it forces you to be explicit about what you want upfront, instead of delaying an unpleasant conversation with the CEO until months after you’ve gone into business together.

With my very first company, I was more laissez-faire about this, less confrontational, because I felt like I didn’t know enough to have a strong opinion. Twelve years later and my stance on controlling culture had done a dramatic 180. At Double Dusk, I had strong opinions about what works and what doesn’t because by then I had accumulated countless scars over nine years of running Freckle. It was difficult not to voice those opinions, not to fight for them to become baked and codified into our culture. It’s surprisingly tough to change your cultural direction even when it’s just a dozen people at the company, so you better get it right sooner. People hate change, and every change requires re-negotiation.

If I’d made all of those mistakes and didn’t take advantage of that knowledge, all those hard knocks, then what was even the point of having gone through it? I wasn’t going to pretend I didn’t see a mistake when I saw one! The whole point of being an experienced second-time founder and fifth-time CTO was to bring all of those playbooks with me, especially since we were on the ground floor and I wasn’t asking an existing organization to change anything.

But of course, when you have two opinionated people in the room with strong feelings and no real way to prove either one right or wrong, whoever is the most stubborn wins. Which is not a great way to run a partnership and adjudicate merit.

How do you resolve this then? No one is going to get 100% of what they want when it comes to culture. It’s too big, non-specific, and fluid for that to happen. So the best way to navigate this is for both parties to simply realize this fact and be willing to concede points to each other with grace. It ends up being a give and take. Successfully negotiating over these issues can be another way you build trust with one another. You may not always agree, but you can always treat one another with respect and accept that compromises will be necessary to make the partnership work. When you’re beginning to take concrete steps to work together as co-founders, some of the first questions you and your CEO ask each other should be: what kind of culture do we envision, not just for the two of us, but for the future of this company? What work styles do we prefer? How do we envision people working here? A lot of this is covered in the aforementioned 50 Questions.

Those answers may be highly personal to you and so you may feel strongly about them, especially when they’re backed by real hard-earned experience. But at the same time it’s good to remember that startup-building, like many other domains, is a wicked domain: you can accumulate a lot of scars, but those scars can teach you the wrong lessons. It’s easy to extract the wrong conclusion from a messy experience in a space that doesn’t clearly label what’s working and what isn’t. You might be hyper-opinionated about something you’re wrong about. Experience is still king, but it’s a reminder of the need for humility even as an expert, as there may be corner cases that you haven’t thought through where your opinion isn’t better than anybody else’s.

More importantly, go into company building with the assumption that everything should be open to revision from day one, given evidence of it not working. No cultural trait is guaranteed permanent stay if it’s not bearing fruit for the company, no matter how long it’s been allowed to hang around.

Some of it is about developing enough trust that your counterpart has put in at least as much care and thought into these decisions as you.

A pairing built on trust

As Marc Andreessen puts it: “Trust equals consistency over time”. At its core, trust is doing what you said you were going to do, and doing that over long enough stretches of time that you build a track record for following through on your word. When you occasionally can’t live up to that ideal — and sometimes you won’t — you need to be transparent about what went wrong, why you did something differently, what you learned, and so on. By doing this, well-handled failures and disappointments can, perhaps counter-intuitively, build even more trust.

A key part of the CEO trusting you is being empowered to make your own mistakes. If they’re breathing down your neck, if they feel the need to inspect and oversee and be in the weeds of your job — especially as an experienced CTO with several companies and many projects under your belt — then it’s best for you not to be in that role. If you’re not being given freedom to fail, but you’re taking ownership and accountability for someone else’s decisions, that’s the worst of both worlds.

I’ve prided myself on making engineering something the CEO doesn’t have to think about. Delegation is the only way their role scales long term. The only reason to grow your team is so that problems go away without you being actively involved in their details. If I’m a CTO working alongside you, engineering problems should magically disappear without you needing to open the black box and understand why the site is down, why people are quitting, why positions rarely get filled, why the team is always behind schedule, why customers are drowning in product defects.

This doesn’t mean hiding problems. You want to be transparent about what you’re seeing on the team. You don’t want the CEO to feel like you’re concealing essential details, forcing them to pry the box’s lid open to get to the truth. At the same time, you want them to be able to trust your delegation, to not need to debug engineering processes, buggy software, things that didn’t ship on time, or deliverables that don’t match what you said they’d be. When that happens, it breaks trust and breaks the CEO’s critical ability to delegate.

Ultimately, what every CEO is looking for is security. They want to feel like engineering is in good hands and operating as well as it could be, aligned with the rest of the company, and not have to spend all of their attention on it.

Building that takes time together. In the early days I like meeting at least a couple of times a week. As things stabilize and the CEO’s attention gets crowded by sales, marketing, PR, and legal, weekly is fine. Time outside of work helps too, building a human connection alongside the professional one.

The cliché about CTO/CEO pairings being like a marriage, marriage counseling and all, is an undying meme for a reason. And like many relationships, there will be times when one side feels they’re not getting a fair deal.

The ebb and flow of effort

There’s a silent reality that, depending on the stage of the business, either the CEO or the CTO is carrying more of the weight at any given time. This can become a major source of resentment if you’re not aware that it’s part of the natural ebb and flow of the partnership. It’s something I’ve seen erode trust in CEO/CTO relationships time and again.

Early on, in the prototype and product build-out phase, engineering is the bottleneck. There isn’t much to sell or market yet, you don’t know your target segment, you don’t know what painful customer problem will end up driving adoption. The only thing that moves the needle is running validation experiments to reach PMF, and that’s gated by engineering. The CEO is doing plenty, of course, but it can feel like the CTO is the one cranking on code Saturday night while the CEO gets their beauty sleep.

That dynamic flips once the company finds its footing. The engineering team grows; the CTO operates through lieutenants and moves off the hot path of delivery. Meanwhile, especially in B2B SaaS, the CEO has to step into every role the company hasn’t hired for yet: building a sales flywheel, standing up sales teams, building marketing routines, fundraising, wrangling executives who want to do things their own way, doing HR until real HR gets hired. There are just as many days that drive the CEO crazy as the CTO; they just happen at different points in the lifecycle.

You can anticipate this source of friction upfront by mutually acknowledging from the very beginning that the load isn’t always evenly distributed, that the imbalance will reverse and re-reverse over time. Sometimes the CEO will feel like the bottleneck; sometimes the CTO won’t be delivering as fast as the company needs.

Why is it not shipping faster?

The CEO/CTO relationship often gets bogged down in another source of conflict I’ve personally experienced: the CEO’s desire for things to happen faster, for a higher sense of urgency beyond what’s already felt by the team. They’re under tremendous pressure from investors, customers and their own internal drive to always want to go faster. If the team is already at code red, the CEO wants to bump it up to code extra red. This seems to happen with well-meaning somewhat-but-not-completely technical CEOs who aren’t in the weeds of implementation day-to-day and don’t grok why something takes longer than their intuition suggests it should.

Sometimes, perhaps LARPing hardcore startup culture they learned about through one too many VC podcasts, a first-time CEO will say: “You’re not working hard enough. You should be doing longer hours. You’re not CTO material unless you push harder. Cracked founders work nights. Why do you need the weekend? We have to ship, there’s no time like now to push. This is a winner-take-all market and we’re all rushing to the prize. We have to fundraise in 8 months and we don’t have the requisite metrics yet, so it’s all-hands-on-deck now.”

This is a common expectation for early stage teams in the modern YC-fueled, 996, Silicon Valley AI gold rush world of Stanford grad 20-somethings attempting to “escape the permanent underclass”. Sprinting during mission-critical times to nail a time window makes sense, but it’s easy to fly too close to the sun and end up in a perennial deathmarch, where sprinting is the only speed known to the team. The CTO becomes the main recipient of this pressure from their peer, not only on themselves but also on their team.

Too much comfort and the market leaves you behind. Constant stakhanovism at the office — especially one without matching wins — will fry you and make people bail. This can also create disparities in how much effort the CTO and CEO feel the other side is putting into the company. If the CTO is seen as a slacker layabout by the CEO while the CTO sees the CEO as a relentless slave driver not putting in the hours, resentment and conflict are near.

There’s a productive conversation to be had on speed. It’s totally fair to question why something takes a certain amount of time. The CTO should be able to explain. Maybe there’s a lot of tech debt. Maybe the system is complex. Maybe the requirements are trickier than they appear at first glance. The conversation should boil down to: are we okay with this taking as long as we think it’s going to take? There’s nothing we can do to conjure more hours out of a day no matter how many Steve Jobs motivational posters we put up. It’s back to the iron triangle: in early-stage startups, scope and polish are the dials we actually control. We can do less about cost and time, although in the world of token-driven development, that may be about to change. So you ask the CEO: Do we need all of this? Can we be clever about cutting corners? If we cut this and that, the implementation goes from a month to four days. Are we okay with that tradeoff? Is there a better person on the team to work on this? We can change the order of priorities.

The key is to dial in a sustainable, urgent pace that will get you where you want to go, assuming you pick the right product bets, and constantly explore clever product and engineering tradeoffs to get the most validation for the fixed amount of time you have. One of the key dials to get right when it comes to shipping enough volume of high-quality changes is the budget for the CTO’s team.

Budgeting as a CTO

When it comes to managing the budget, I’ve been both hands-off, letting the CEO act as the finance lead, and heavily involved in the budgeting process myself.

The hands-off version worked surprisingly well at Freckle. When you’re one part of a big team, it can be a bad thing if the CTO is too involved in the budget and successfully funnels funds away from the larger machine towards their team. As the control tower for the business, the CEO should figure out — of course informed by input from all of the different parts of the business — how to place the right bets at the right time and make sure none of the core functions are starving for staffing. Sometimes that means more engineers, at times more sales people, and at other times the company’s outlooks may not look great and need to shed some weight.

Either way, we left it up to the CEO to determine how much was “fair” for every team at the company based on the information we fed him, and ultimately his picks worked out great. We were not — unfortunately, perhaps — blitz-growing and could be methodical in the evolution of the company’s staffing.

At the Double Dusk game studio I was part of budgeting from day one. I felt good about how we allocated our runway across the whole company because I understood the constraints firsthand, played with different scenarios, and agreed to a particular plan. We explored many staffing scenarios and picked the most sensible one based on our projections for the product roadmap. Do we have enough artists for the pace at which we need to make content to ship before running out of money? Can we afford a dedicated 3D person, or should we go all-in on art generalists? Who should be a contractor, and who full time? Can we afford a specialist network engineer, or are we too early? Countless questions with no right-or-wrong answers.

That does not mean that co-owning a budget magically exempts you from costly mistakes in the CEO/CTO relationship. The way I had done it led to the CTO hero trap.

Being the hero CTO

I wanted to save as much budget as possible for the rest of the organization by not asking for help on the engineering side. “We’re pretty hardcore. We just need a couple of people. I’m sure that will be enough, I’ll work extra hard to make up for it. I know what my team and I are capable of and we can handle a few lean months.” Great intentions, in theory. And that worked. For a while at least.

I knew the CEO was already fighting a dozen fires; the last thing he needed was to fight my insistence for more people. I wanted my partner to feel like I had this and that the answer to my problems wasn’t the predictable “if only we had more people”. I was convinced we could lifehack our way around the iron triangle.

So I pushed myself to work unsustainable hours for months on end. I didn’t want to be a hero, but it felt like the right thing to do at the time, making sure the rest of the organization had as many resources as it needed. I would tighten the belt and take one for the team. Months of non-stop grind, little feedback from the universe to boost the morale, and your own sunny disposition slowly eroding and making you a pain to be around as you’re deep in the death march. In retrospect, it was a mistake, and I should have been more aware of the punishment I’d inflicted on myself and how it ultimately affected my relationship with the rest of the team and with the CEO.

This happens to startup CTOs who haven’t yet encountered the consequences of sustained heroism, who make up for the lack of systems with their own sanity. Startup people romanticize the heroic hours. The VCs praise the habit. A shrinking runway and upcoming demo days set a brutal pace, whether you like it or not. But long-term this plan implodes and prevents the team from building systems that stand the test of time, that don’t require individual sacrifice, but instead consistently deliver results.

You can however avoid this trap.

Be realistic about what’s sustainable and constantly warn the team when anybody is getting overstretched, including yourself, and adjust course. Actually, let the system fail — in a benign and non-catastrophic way, such as making it clear that you won’t be able to ship as much as the company would like, short of a personnel or scope change — to demonstrate that you need the help, need the resources, or need a new roadmap. The alternative is to stretch and stretch and keep stretching yourself until eventually, inevitably something snaps on the people’s side. Employees quit. Relationships fray. Resentment sets in.

Heroics are easier when things are going well. The wins, the favorable tailwinds, the unsustainable schedule can feel joyful while the spirits are high, the higher confidence that you’ll deliver the goods even under all the pressure. You’re crushing it, and now you get to do more of it. But heroism when nothing is working? That drains you fast, and can lead to gnarly burnouts that can require many months to recover from, the brain refusing to do more of what got you there in the first place.

I would tell younger me to push when things are good, and be more considerate towards myself when the universe is doing me no favors. But at least in this role I get to own my lane, my failures and successes. Or do I?

Bypassing ownership

One of my least favorite experiences in a CTO seat was discovering that the CEO had, unbeknownst to me, made technical decisions I would have to live with in perpetuity, some of them highly expensive in terms of time and complexity. These decisions came from a good place, out of a genuine intention to do the right thing for the product, but had I been consulted, I would have strongly opposed the move.

We adopted functionality overnight that turned out to be incomplete, poorly maintained, where the authors behind it had either disbanded or were impossible to get ahold of. The codebase was never meant for real external consumption. We were the first shop to use the module in commercial production. Retroactively the CEO justified it as mission-critical for the product, without ever consulting the person who would ultimately be saddled with maintaining it, supporting it, debugging it and evolving it for years to come.

Imagine the reverse: it’s as if one day the CTO walked into the room and announced: “This is how we’re going to monetize the product. NFTs on FartChain2000 Layer 15, I already deleted our Stripe account, moved our customers to the blockchain and sent out an email blast informing them. That’s the only way from now on, it’s super important to us and will be why we win.” The CEO had no say in it and now has to somehow retrofit everything to work for this unilateral decision. That would be absurd. And yet the reverse can happen to CTOs from somewhat technical partners with the best of intentions.

This isn’t limited to technical choices. It happens when the CEO saddles engineering with a commitment to a product evolution or a feature that may be unreasonably costly or damaging to the product experience. Or the CEO with a personal relationship to a vendor has the tech team use that provider instead of what they may already be familiar with, or one that feels like a better fit. Regardless of the variant, it always feels disempowering; it removes any ability from the people doing the work to have a say in it. If the bet fails, they will feel like they told the CEO all along. If the bet pays off, they had no hand in the win, it will feel like an empty victory at best.

There are corner cases where the CEO has to override everyone in the interest of saving the company or making an executive decision on its behalf that they will later apologize to the team for. It’s important for that to be a true exception, not the team’s modus operandi. Whether it’s technical one-way doors, product promises, or any other serious commitments that someone else will ultimately be responsible for delivering, don’t saddle your partner with a burden they had no hand in shaping.

Some of this stems from the inevitable difference in power between the two roles.

The power asymmetry

There’s a structural reality worth naming: unless you started the company and carved out larger equity (or more board seats) for yourself, the CTO seat is structurally wobblier than the CEO’s. The CEO is the vision holder, the one who interfaces with capital, customers, and staff. If things go south between you two and the CEO wants to stay, you’re the one who has to go.

A CEO, when push comes to shove, can find a new CTO. A CTO often has to look for a new job. This weakens your hand in any disagreement, which is part of why long-standing relationships matter so much in this pairing. Many co-founding pairs of total strangers fail because they have no buffer of trust to absorb that asymmetry.

Knowing this doesn’t mean accepting a subordinate role. It means being clear-eyed about the dynamic so you can navigate it with intention. In a venture-backed startup, everyone — majority-owner CEOs excluded — is at the service of the business; the CTO’s seat is just a little less secure.

There are exceptions. Sometimes the board pushes the CEO out, or they leave voluntarily. I’ve seen CTOs successfully step into the CEO role and do a tremendous job. Companies can thrive after losing their top exec.

When to walk away

But like with all human relationships, there may be times where the best course of action for the firm is for the relationship to end. You did all the couples counseling. You had heart-to-hearts. Maybe your services are no longer needed by the company and you don’t want to burn through their cash reserves for no reason. You both tried to adjust your styles and expectations, but ultimately it’s not working. It might be time for the CTO to go.

A telltale that it’s time to walk away is when you’re not bringing your best self to work anymore and you don’t see how that situation could ever change. You’re performing a pantomime of the role, but inside you’re checked out. You don’t care as much. You’re cynical. You’re disconnected from the work. In such a situation, it’s to everyone’s benefit that you move on before you’re forced to.

The company deserves someone in your seat who is pumped, full of optimism and vision and desire to grind it out with the team even when things are hard. And things are going to be hard most of the time. You need to be stoked about powering through those challenges together because you believe in the opportunity, the partnership you have with the CEO, and the team. You want to prove to the world that you can overcome these hurdles and emerge from the swamp of pivot hell, or whatever other challenges you might be facing. Maybe it’s a competitor eating your lunch, a sudden market change, a failed fundraise on which you bet the farm.

Once you’ve permanently lost the stoke — I joke that if you’re not considering quitting at least once a week, you’re doing startups wrong — and you’ve realized that you have to move on, there are generally going to be ways to offboard yourself gracefully. While they may miss your steady hand, the folks on your team are going to be grateful that they didn’t have to wait for things to truly implode before you let them know you hadn’t been feeling it for some time. You’re giving yourself a chance to leave with honor, not let people down at a critical moment. You can time the exit in a way that makes sense, and hopefully find your zone of genius somewhere else.

Like with many other things in life, there are ebbs and flows to every role, every company, every position, every relationship. Maybe you’ve reached the limit of how far you’re able to take this one. And it’s okay to move on if that’s what it comes to.

As the company grows

But if you stick around, have a great relationship with the CEO, and as the company grows and keeps finding success, some things get easier. The company identifies its niche, its segment, its maximum point of leverage in the marketplace where cash flows and customers start coming back for more. It’s more stable, more predictable. But as the bones of the business strengthen, the CEO will inevitably spend more and more time on administration, sales, marketing, finance, meeting customers, going to conferences, fundraising, PR, legal; all things they hardly had to think about in the earliest stages.

Usually they have to stop being the main product manager and find a replacement: first maybe a senior PM, eventually a head of product. In some sense, that makes your life easier. You’re no longer dealing with a very opinionated, strong-willed CEO who is also getting progressively more removed from constant interaction with users and ground-level product thinking.

Instead, you’re working with folks who do this all day, every day: product management experts who are more interested in a smooth process than they are in getting their way on every little thing like a strong-willed and disagreeable CEO can be. Not only that, but there’s no longer a major power imbalance between the person you’re talking to the most day-to-day. A CTO and head of product are much closer to co-equals than a CEO-CTO. They might even report to the CTO. Things smooth out. The surface area for friction shrinks.

Eventually, as the company grows even bigger, you and the CEO are both managing progressively larger teams of teams with less crossover between them than in the early days, where everyone was expected to pitch in with every job. A lot of your interaction ends up being about spreadsheets and administrating your respective fiefdoms rather than what you were doing before—on-site visits, designing the next app workflow, fielding customer feedback, trying to convince your target market to use your product. The nature of your job changes, the nature of the CEO’s job changes.

If you’re successful, what you’re doing together will continuously evolve. The constant growing and changing is part of the reward for a job well done.

Conclusion

In the ideal version of this partnership, both of you know exactly what lanes to swim in and let each other do your best work without unnecessary friction. You trust each other, keep each other honest, have radically candid conversations when they’re needed, and don’t throw each other under the bus when things get hard.

Some pairings work beautifully off the cuff. Others need massaging until they fit just right. And some aren’t meant to be, in which case it’s okay to walk away, as I have done before, in the interest of the collective. I believe that ultimately, you can always find a great CEO partner that allows you to thrive in your role and be in your zone of genius, if you’re willing to look for it. The search may take years and many tries, but when you find it, you’ll appreciate how rare and precious that relationship is.