When the Founder-CTO Relationship Breaks

That’s the uncomfortable asymmetry for a non-technical founder: you’re making business commitments against estimates you can’t independently assess. You need an explanation you can use with a customer, even if you can’t review the implementation yourself.

The Asymmetry That Makes It Worse

Consider what might separate those estimates. The engineer may be estimating the feature in isolation. Your CTO may be including testing, rollout, and the work it would displace. Or the engineer may have found a simpler approach that the CTO missed. Until you compare the assumptions, you don’t know whether you’ve found a better plan or left something out.

Suppose the request is a customer report. The engineer proposes generating a file from existing data; the CTO has estimated a self-service reporting feature. Sending the file could meet the immediate need with less development, provided someone owns producing and checking it whenever the customer asks. Put that continuing work into the comparison, and you may have a legitimate reason to choose the shorter estimate.

Act on the shorter answer alone, and the engineer has to reconcile your promise with their existing work. If they drop that work, the CTO’s plan is now wrong. If they keep doing it, your customer commitment is at risk. They can ask you both to resolve the conflict, but until you do, they’re carrying a decision that belongs to the founders.

From there, the loop can feed itself. If displaced work slips and you read the slip as proof that the CTO needs closer supervision, you have a reason to bypass them again. If the CTO responds by withholding uncertain estimates for fear they’ll become promises, you have less information to work with. Each founder’s attempt to protect their own responsibilities makes the other’s harder to fulfill.

None of those steps requires an open fight. Standups can still run; the roadmap can still get updated. The fracture can live underneath those routines, in the private calculations about what can be trusted, what gets routed around, and what isn’t worth raising because it’ll turn into another argument. Open conflict can be a late symptom of decisions the team has already had to absorb.

Direct contact with engineers can coexist with clear management responsibility. In her account of moving into managing managers, Lara Hogan described keeping meetings with engineers after handing off their team’s management, while stepping away from its day-to-day work. Her example shows a distinction worth keeping: access to information and authority to redirect work can be separate. Protecting your CTO’s role doesn’t require making them your only source of information.

Put One Disputed Commitment on the Table

Start with a commitment that went wrong. Separately, write down what each of you believed had been agreed, what counted as finished, which information you had, and who you thought could change the plan. Then compare those accounts with the customer messages and the work assigned to engineers. A different recollection tells you where to look; dated messages, tickets, and changed priorities let you check it.

In Gloria Lin’s account of choosing her co-founder, she and Joel Poloney answered a questionnaire independently, then compared their responses before committing to build Siteline together. Lin explicitly wanted to surface differences rather than fall into groupthink. Applied to an existing dispute, the practice has a narrower purpose: establish whether you remember the same agreement before asking each other to honor it.

Now bring the missing context into the decision. Show your CTO the customer’s actual requirement and what the deal is worth. Share the financial constraints as well as the deadline. Ask the CTO to explain what the estimate includes and what would have to move to meet the request. The engineer’s simpler approach, if there is one, belongs in that discussion too.

You can insist on understanding the tradeoff without pretending to judge every line of code. Your CTO can challenge a customer promise while still taking responsibility for explaining the technical options. In the reporting example, check with the customer whether a delivered file meets their need, then ask the engineer and CTO what would demonstrate that they can produce it reliably. That separates a question you can answer with the customer from a technical assumption the team still has to test.

Your agreed roles may give you the final call on business priorities even when the CTO disagrees. That lets you choose which risk to accept; it doesn’t make an uncertain estimate certain. If authority itself is disputed, take it to whoever your company’s agreements empower to resolve it rather than asking another engineer for a more favorable answer.

Write down the resulting commitment, what has to be true for it to hold, and the work you’ve deferred. Tell the team what changed and who made the call. If you changed the priority, own that change instead of leaving the CTO to defend the old plan’s missed work. Put unresolved commitments on a recurring founder agenda so the next disagreement has somewhere to go before either of you takes it to the engineers.

The observable change is modest: the next customer request reaches the agreed decision-maker before anyone promises a date, and the team gets one plan. That gives you something to assess beyond whether the last conversation felt better. Compare the delivered work with the commitment and its recorded assumptions before concluding that the delivery problem is fixed.

When the Facts Don’t Settle It

Your CTO may genuinely be wrong about the work, even after you’ve compared assumptions. Where you have the relevant expertise internally, use it to review the disputed approach with both founders. If you lack that expertise or can’t agree on an internal reviewer, an outside technical review is an option.

Agree on the question before choosing the reviewer, and give them the requirement, constraints, and work to inspect. Ask them to explain where the estimates differ and what remains untested, with room for both founders to challenge the reasoning. A favorable answer without that explanation repeats the original problem. A reviewer who could win work from the verdict also has a stake in it; their recommendation deserves the same scrutiny as your CTO’s.

If either founder keeps breaking agreements or refuses to share material information, the technical answer leaves that behavior unresolved. A coach or trusted advisor acceptable to both of you is an option for structuring the conversation, provided you’re both willing to act on what you agree. Changing responsibilities or ending the partnership may still be necessary.

Keep that decision with the people responsible for it. The engineer who answered your question shouldn’t have to decide which founder to disappoint.