How do you split responsibilities between co-founders?
The cleanest co-founder splits give each person a domain where their word is final, not a shared committee vote on everything. Done well, this lets two or three people move at the speed of one. Done poorly, it creates a slow-motion power struggle that kills companies from the inside before any competitor gets the chance.
Why 'We'll figure it out together' is a trap
Most first-time founding teams resist drawing hard lines because it feels collaborative to consult each other on everything. In practice, unanimous-consent governance works fine when the company has three users and two employees — and collapses the moment the pace picks up. When a critical hiring decision, a pricing call, or a pivot needs to happen in 48 hours, 'let's talk it through' stops being a virtue and becomes a bottleneck.
The better mental model is domain sovereignty: each co-founder owns a slice of the company so completely that they can make and execute decisions inside it without a vote. Other founders get input — especially on anything irreversible — but input is not veto power. This sounds uncomfortable until you realize that the alternative is two people each secretly believing they have final say, which produces the worst of both worlds: slow decisions and eventual resentment.
Paul Graham's observation about the co-founder relationship being the literal foundation of the company is worth taking seriously here. Exploitative or ambiguous dynamics between founders don't stay internal — they ripple outward into hiring, culture, and user experience. Getting clarity on who owns what is one of the few things you can control completely before external pressure makes it harder.
The right way to divide the domains
The most durable splits follow the natural fault lines of the business rather than title conventions borrowed from big companies. At the earliest stage, there are really only two functions that matter: building the thing and selling the thing. One founder runs the product and engineering surface; the other runs customers, revenue, and go-to-market. Everything else — legal, finance, HR, PR — is a shared responsibility that neither person owns until the company is large enough to hire a specialist.
Where this gets nuanced is at the seam between building and selling. Product roadmap decisions are almost always at this seam: they require customer insight (sales side) and technical feasibility judgment (product side). The convention that works best in practice is that the product-side founder has final call on what gets built, while the sales-side founder has final call on which customer segments and channels to prioritize. When those two things conflict — which they will — you need a pre-agreed tiebreaker, usually the CEO, who is a real role and not just a courtesy title.
For three-founder teams, the third domain is usually one of: (a) a deep technical specialization the company's product depends on, (b) a specific market or channel one founder uniquely owns, or (c) an operational function like finance that is actually full-time-critical for your business model. Be honest about whether the third founder's domain is genuinely load-bearing or whether it's a political concession. If it's the latter, the equity and decision-making structure will eventually reflect that tension badly.
Making the split operational: what founders actually need to agree on
Writing down domains is the start, not the finish. For the split to work in practice, you need three operating agreements that most founding teams never make explicit.
First, a decision log. Any decision above a certain threshold — say, any commitment of more than $X or any hire — gets logged with who made it and why. This is not about oversight; it's about preventing the revisionism that happens when a decision turns out badly and everyone's memory of who approved it suddenly changes. A simple shared doc works fine. The act of writing it down forces the decision-maker to own it.
Second, an escalation protocol for seam decisions. When a decision touches two domains, who brings it to the table, what information is required before a call gets made, and how long does the deliberation window last? Leaving this undefined means the more aggressive founder will always push through seam decisions fast, and the other will always feel steamrolled. A 48-hour deliberation cap on non-urgent seam decisions, and a two-hour cap on urgent ones, is a reasonable starting point.
Third, a quarterly re-examination of the split itself. The right domain structure at ten employees is wrong at fifty. Founders who never revisit their split end up with one person holding nominal authority over a function that has grown two levels of organization past them, which is both inefficient and demoralizing. Schedule it like a board meeting — short, structured, and recurring — so it doesn't become a crisis conversation.
The equity question is separate from the responsibility question
Many founding teams conflate role splits with equity splits, which creates a subtle but serious problem. If one founder's domain clearly dominates in importance right now — say, the technical co-founder is building everything while the business co-founder is still validating — the temptation is to reflect that in equity. Resist it. Equity is a long-term instrument that prices expected contribution over the full life of the company, not current workload. The right time to adjust equity is before the company is incorporated, with vesting schedules doing the real work of aligning contribution over time.
What the responsibility split does affect is the CEO title, which matters more than founders like to admit. Not because of the title itself, but because customers, investors, and employees use it to know who is the final decision-maker for the company as a whole. Ambiguity here — two founders both calling themselves co-CEO, or alternating the role — creates confusion externally and a vacuum internally. Pick one. It does not have to be the founder with the largest equity stake. It should be the founder who is most effective at representing the company to the outside world and most willing to make unpopular calls internally.
The founder who is not CEO is not second-class. They own a domain fully, they hold significant equity, and in many successful companies they are the reason the product actually works. The title just clarifies who makes the calls that don't fit neatly in either domain — and that clarity is worth more than the symbolic comfort of sharing a title.
“Their exploitation usually begins with their own cofounders, which is disastrous, since the cofounders' relationship is the foundation of the company.”
— Paul Graham, source
The one thing to do
Before you hire your first employee, write down which co-founder has final say in which domain and name a single CEO — ambiguity at the top is the most preventable way a founding team destroys itself.
Frequently asked questions
What if both co-founders want to run the same domain?
This is a signal that the founding team's skills overlap too much and the company will have a blind spot somewhere. Have an honest conversation about which founder is genuinely stronger in the contested area, assign it cleanly, and have the other founder take real ownership of whatever is currently unowned — even if it feels less exciting right now.
Should the technical co-founder always be CTO and the business co-founder always be CEO?
Not automatically. The CEO role should go to the founder who is better at external communication, investor relations, and making hard calls under ambiguity. Sometimes that is the technical founder. Assign titles based on actual fit, not convention.
How do you handle it when a co-founder keeps overstepping into the other's domain?
Name it once, privately, and tie it back to the operating agreement you both made. If it continues, that is a co-founder relationship problem, not a process problem, and it needs a direct conversation about whether both people genuinely accept the structure — not more process tweaks.
When should the responsibility split be documented formally?
Before you have more than two employees, and ideally before you have any. The document does not need to be long — one page covering domains, the escalation protocol, and the CEO designation is enough. The value is not the document itself but the conversation that produces it.
Sources
- gstack: skillify/SKILL.md — Garry Tan
- Beyond Smart — Paul Graham
- Billionaires Build — Paul Graham
- Do Things that Don't Scale — Paul Graham