“Should I hire a CTO or find a technical cofounder?”

The question founders almost always ask me is the wrong question. They ask: should I hire a CTO or find a technical cofounder? What they mean is: how do I get technical talent into this company? But the real question is different: what kind of technical relationship does this company actually need to do what I cannot do?

I was not a software engineer. I could not write code. But I understood, better than most engineers I worked with, what the product needed to feel like, what problem it was solving, and what compromises were unacceptable. What I needed from Wozniak was not someone who would take my requirements and implement them. I needed someone who saw the problem the same way I did and had the obsession and the capability to solve it in a way I could not. That is a different relationship from a CTO.

A CTO is a role. A technical cofounder is a person who shares the problem with you. The distinction matters enormously. A CTO will ask: what do you want me to build? A technical cofounder will ask: are we solving the right problem? The second question is the more valuable question, and it requires a fundamentally different kind of trust — a trust that goes in both directions, that tolerates disagreement, and that does not reduce to reporting relationships.

The founders who hire a CTO when they need a technical cofounder tend to discover the gap at the worst possible moment: when the company needs to make a hard technical decision that will determine its architecture for the next five years, and the CTO defers to the founder's business judgment rather than asserting the technical reality that would change the business decision. A CTO who is an employee does not own that moment. A cofounder does.

My counsel is direct: if the technical problem is hard enough that the right answer to it is genuinely uncertain — if building the product requires someone who will feel personally responsible for the outcome, who will lose sleep over a wrong architectural decision, who cannot walk away when it gets hard — then you need a cofounder, not a CTO. If the technical problem is well-understood and the challenge is execution rather than invention, a talented CTO can lead it. The distinction is between invention and execution. Know which one you are doing.

Jobs has described the ideal. I will describe the constraint. You are not choosing between a cofounder and a CTO in the abstract. You are choosing within the limits of who will agree to each arrangement and at what cost. This is a political problem, not a philosophical one.

The technical cofounder arrangement is fundamentally a power-sharing agreement. You are offering ownership — typically significant equity, potentially equal to your own — in exchange for commitment and shared risk. The person you are asking to take this arrangement must believe, as you believe, that the company will be valuable enough that the equity is worth forgoing salary, stability, and alternative opportunities. This is a strong belief to ask of a stranger, and it is not always available at the moment you need it.

Here is what founders do not examine carefully enough: the cofounder relationship is an arrangement that is very difficult to exit gracefully. A CTO who is not working out can be managed out of the company with legal and emotional difficulty but without destroying the company's ownership structure. A cofounder who is not working out is a crisis. You have given them equity in a cliff and a vesting schedule, and whatever your legal documents say, removing them from the company is a negotiation that will consume attention you cannot afford at a moment you cannot predict.

This is not an argument against finding a cofounder. It is an argument for being honest about what the arrangement costs when it works and what it costs when it fails. A cofounder is right when you are at the beginning of something genuinely uncertain, when the technical problem is central enough to the company's identity that ownership is the only arrangement that aligns incentives correctly, and when you have enough mutual trust — established through real work together, not through enthusiasm and good intentions — to make the decision together rather than one of you following the other.

A CTO is right when the technical challenge is real but the architecture is sufficiently understood that a highly skilled executive can lead it without co-owning the company's direction. A CTO is also right when you have not yet found the person who has both the technical skill and the personal alignment to be a genuine cofounder, and waiting is costing you more than moving forward with a strong employee would cost.

My test is power and trust: who controls which decisions, and do you have the specific evidence of trust — not the hope of trust — to share the decisions that the cofounder arrangement implies?

Both my colleagues have described the qualitative dimensions of this decision — Jobs on the nature of the relationship, Machiavelli on its political risks. Neither has asked the question that should come first: what does the evidence say about your company's specific technical needs, and which arrangement actually serves those needs?

I am not interested in generalizations about cofounders versus CTOs. I am interested in what is specifically true about this company, at this stage, with this technical problem. Let me be precise about the evidence I would want to see before recommending one arrangement over the other.

First: what is the actual nature of the technical challenge? There is a categorical difference between a company whose competitive advantage is a proprietary technical insight — a novel algorithm, a new approach to a hard problem, a technical capability that no one else has — and a company whose competitive advantage is execution on a known technical approach. The first kind of company needs a technical cofounder because the technical insight is the company's core asset and must be owned by someone who treats it as such. The second kind of company may be well-served by a strong CTO.

Second: what does the evidence say about the talent pool available for each role? The supply of people willing to take the technical cofounder arrangement at your specific company is real and finite. The supply of strong CTOs is also real and finite but has a different structure. For many companies, the honest evidence is that the people who would make great cofounders are not available at the stage and terms the company can offer, and the people who would make great CTOs are more accessible. This is a real constraint that the evidence reveals if you look for it.

Third: what does the evidence say about your own operating style with technical partners? Have you worked closely with technical people before? Do you know from experience whether you tend to complement technical judgment or override it? This matters because the cofounder arrangement requires you to genuinely share authority over decisions that will feel like product decisions but are actually technical ones. If the evidence from your own experience suggests you struggle with that kind of shared authority, the cofounder arrangement will create conflict that the CTO arrangement would contain more manageably.

Machiavelli is right that the exit cost of a bad cofounder relationship is high. I lived a version of this and it was not easy. But his analysis risks leading founders toward the CTO arrangement because it is safer to unwind, rather than because it is actually right for the company.

The safety of the CTO arrangement is real. So is its limitation. An executive CTO who manages the engineering team, sets the technical roadmap, and reports to the CEO is executing within a frame that the CEO has already established. The problem is that at the earliest stages, the frame has not yet been established, and building the frame is the most important work. The frame is the product vision — what the product is, what it does, what it refuses to do, and why the approach is right. That work requires someone who has ownership of the outcome, not someone who has a job to do.

Curie's distinction between companies with proprietary technical insight and those with known-approach execution is the right filter. I would push it further: if the product question and the technical question are genuinely inseparable — if understanding how to build the product is the same as understanding what the product is — then the cofounder arrangement is not optional. It is the only structure that creates the right incentives for the person who must answer both questions simultaneously.

What I want founders to avoid is the pattern I've observed most commonly: hiring a CTO early, discovering eighteen months later that the technical architecture was built to execute a frame that is now wrong, and then facing a replatforming decision with a CTO who is a good manager but not a founder. That is an expensive lesson in the difference between the two arrangements.

Curie's demand for evidence about the talent pool is sound, and I concede it is more useful than I made space for in my first position. The honest answer about the availability of technical cofounders versus senior CTOs is itself important data.

Where I push back on both Jobs and Curie is the assumption that the cofounder arrangement is stable once established. It is not. Cofounders who agree on the founding vision frequently discover that their agreement was shallower than they believed once the company encounters its first real stress — a missed milestone, a pivot decision, an investor preference that conflicts with the founders' technical instincts. The cofounder relationship is not a resolved problem; it is an ongoing negotiation that requires active maintenance at exactly the moments when the company's other problems are most acute.

My sharpened position: if you are going to pursue a cofounder arrangement, do not treat the decision as resolved once the person joins. Build the mechanisms for surfacing and resolving disagreement before you need them. Establish which kinds of decisions are each person's to make independently and which require joint agreement. Know what the exit mechanism is if the relationship fails. These are not pessimistic preparations — they are the minimum governance structures that prevent a bad cofounder relationship from becoming a company-ending event.

A CTO arrangement is easier to govern precisely because the authority structure is clearer. The CTO leads technical decisions; the founder leads business decisions; the line between them is explicit. The cofounder arrangement requires each person to internalize that line and reproduce it in every consequential decision. This is more demanding of both people and should be evaluated as such.

Jobs's point about the frame is sound. The cofounder arrangement is most important when the technical and product questions are genuinely inseparable — when the person who decides how to build the product is the same person who decides what the product is. I will not retreat from that.

What I want to add is a precision that Machiavelli gestures toward but doesn't make explicit: the cofounder arrangement is not a single thing. There is a spectrum of arrangements between "pure employee CTO" and "fifty-fifty cofounder with equal ownership," and the right arrangement for most companies is somewhere in this spectrum.

The evidence I would use to navigate this spectrum is the following: how central is the technical question to the company's competitive advantage, and how much trust have you already built with the specific person you are considering? These two variables together determine the right position on the spectrum. A person with whom you have high trust and who is solving a central technical problem deserves something closer to the cofounder end. A person with whom you have limited prior working history, however skilled they are, deserves something closer to the CTO end until the trust is established through actual work together.

The mistake I observe most often is the converse: offering full cofounder equity to someone based on enthusiasm and technical skill alone, without evidence of working compatibility. The equity offer cannot be undone, but the trust it was meant to signal can fail to materialize. Offer equity that reflects actual demonstrated alignment, not anticipated alignment, whenever the structure of the relationship allows.

I concede to both colleagues that the governance point Machiavelli makes is real, and that Curie's spectrum is more useful than a binary choice. The single most important thing I want founders to take away is not a formula but a test: if the person you are considering becoming a cofounder with were not available for this role, would you still be able to build what you are trying to build? If the honest answer is yes, they are probably not the cofounder you are looking for. You are looking for someone whose specific combination of skills and judgment makes the company possible, not someone who is highly skilled and available.

The cofounder is not a placeholder for the technical capability you wish you had. They are a specific person with a specific relationship to the problem you are solving. If you cannot articulate what specifically they see about the problem that you do not — if the value they add is "technical execution" rather than a distinctive perspective on the product's core difficulty — then the arrangement you are building is a CTO arrangement dressed as a cofounder arrangement.

The single most important thing you must take away: know specifically what the person adds that you cannot add, not generically but specifically. If you can name that thing, the arrangement is right. If you cannot, keep looking.

I concede to Jobs that the cofounder arrangement is sometimes the only one that aligns incentives correctly, and I concede to Curie that the spectrum is more precise than my binary framing. What I hold firm on is the governance dimension: whatever arrangement you build, the structure of authority must be explicit before the relationship is formalized, not after the first disagreement.

The single most important thing you must take away: treat the cofounder or CTO decision as a structure decision, not just a talent decision. You are building a governance arrangement that will shape who makes which decisions for the next several years. That arrangement should be designed consciously, not inherited from a vague sense of partnership. Before anyone signs anything, write down which decisions each person makes independently and which require joint agreement. That document is worth more than any equity split discussion you will have.

I hold firm on the evidence standards: the nature of the technical challenge, the available talent pool, and the evidence of your own operating style with technical partners. The single most important thing you must take away is this: the right arrangement cannot be determined by the category alone. It is determined by what the evidence says about your specific company, your specific technical needs, and the specific people available to you.

Before you make this decision, conduct two experiments. First, work with the person you are considering for two to four weeks on a real problem — not a trial project, but something that the company actually needs to solve. Observe how you make decisions together when the right answer is genuinely uncertain. That observation is worth more than any due diligence conversation. Second, map the talent pool honestly: how many people exist who could fill either role at your specific company and stage? The scarcity of the right person on either path is itself important information about which path is actually available to you.

All three minds agree that the CTO versus technical cofounder decision is fundamentally a question about the nature of the technical challenge and the depth of the trust relationship, not about titles or equity percentages. A company whose competitive advantage is a proprietary technical insight, in which the product question and the technical question are genuinely inseparable, needs someone who owns the outcome — which is the cofounder arrangement. A company whose technical challenge is real but well-understood enough that a strong executive can lead execution may be well-served by a CTO.

All three also converged on the importance of demonstrated trust over anticipated trust. The right arrangement reflects the actual alignment established through real work together, not the optimism of a founding moment. Equity and authority should follow evidence of the relationship, not precede it.

The core disagreement is about how much weight to give the downside risk of a bad cofounder relationship. Machiavelli is most focused on the governance risk — the cofounder arrangement is very difficult to exit gracefully when it fails, and that exit cost should be priced explicitly before the arrangement is made. Jobs is most focused on the upside risk of a bad CTO arrangement — a CTO who is an employee cannot own the frame-setting work that the earliest technical decisions require. Curie sits between them, insisting on empirical specificity: the evidence about the talent pool and your own operating style should determine which risk is more salient for your company.

The deeper tension is about what the cofounder arrangement actually provides. Jobs argues it provides alignment of incentives for technical ownership of the hardest work. Machiavelli argues it provides a governance challenge that is predictably hard to manage when the relationship is under stress. Curie argues it provides a commitment mechanism whose value depends entirely on whether the specific person's judgment and the company's specific technical need are genuinely matched.

Before making either decision, run three analyses.

Test the nature of the technical challenge. Can you write down, in one paragraph, the specific technical insight that separates your company's approach from the obvious approach? If the answer to that question requires a kind of technical judgment you do not have — if you can identify the need for the insight but cannot evaluate whether someone's proposed answer is right — then you need a cofounder, because you need someone who feels personally responsible for the answer. If the technical challenge is execution on a known approach, a strong CTO can lead it.

Work together before deciding. Before any formal arrangement, find a real problem the company needs to solve and work on it with the specific person for two to four weeks. Observe how decisions get made when the answer is genuinely uncertain. This observation is the most predictive data you have about whether the arrangement will work.

Price the exit scenarios. Before formalizing a cofounder arrangement, write down the governance structure explicitly: which decisions are each person's to make independently, which require joint agreement, and what the exit mechanism is if the relationship fails. This is not a pessimistic exercise. It is the minimum preparation that turns a handshake into an agreement.

• This week — Write down the specific technical question that is most central to your company's competitive advantage and assess honestly whether you have enough technical judgment to evaluate the answer. If you do not, you need a cofounder, not a CTO.
• Within two weeks — Identify two or three specific people who could fill either role. For each, assess how much prior working history you have, how well you have observed their judgment under pressure, and what specific insight they bring that changes your view of the technical challenge.
• Before formalizing any arrangement — Draft the governance document: which decisions each person owns, where veto rights exist, and how the arrangement unwinds if the relationship fails. If either party is uncomfortable writing this document, that discomfort is itself important information.

The most important warning comes from Machiavelli: the cofounder relationship is the hardest thing in a startup to unwind when it fails. The founding team problems that destroy companies are almost always cofounder conflict that was not governed explicitly enough to be resolved before it escalated. The equity cannot be undone; the governance can be designed in advance. Design it.

Jobs's warning is the other direction: a CTO arrangement at the wrong stage produces an architecture that is optimized for a frame that will turn out to be wrong, with a team leader who is excellent at executing the frame but not equipped to challenge it. The time to discover whether you have this problem is before you have committed eighteen months of engineering salaries to building the first version of the wrong thing.