Once you start working together as founders — for real, not just on a side project — you need a way to agree on things. Not on every opinion. On who gets to call the fork.
You will hit moments where one of you thinks: I'm really not convinced this is the best route. Pricing. Hiring. Which customer segment to chase. Whether to take the money. Whether to ship the thing this week or rewrite it again.
That's normal. What's 'expensive'- time consuming for you, time consumers in how fast you go, energy consuming on the relation - is what happens next: you keep talking about it without taking the fork. Another meeting. Another Slack thread. Another "let's sleep on it, I am not convinced." Sometimes that's wisdom. Often it's stall — and stall is worse than a wrong turn you can reverse.
It also wears on the relationship in small ways. Irritation builds. You start to wonder whether your co-founder will ever actually let something go that you feel is on your plate, or whether you're being overruled without a real decision. Trust doesn't blow up in one fight — it erodes in repeated loops where nothing closes. So the cost isn't just time. Left unhandled, it compounds into friction you'll later blame on "personality" when it was really process ambiguity.
In the founding teams I see, getting past that moment takes work. And as with many things in ops: maintenance beats repair. Agree the rules while you still like each other. Not when you're three weeks into the same argument.
What you don't need (yet)
At 2–10 people you don't need a RACI matrix. You don't need SPADE memos. You don't need the GitLab DRI handbook. So that's not what we'll talk about here.
You need:
- Founders aligned with each other — who owns which domain, what your personal runway allows, a weekly slot to talk about it.
- One visible list for what still needs all-founder OK — hiring, big spend, pivot.
- A rule for disagreement — so "I'm not convinced" doesn't mean "we don't move."
That order matters. Team-facing rules before founder alignment is backwards.
The fork: right to decide, duty to consult, then close
What I use myself — and I suspect I picked it up from Grove, Apple DRIs, and the Laloux crowd without tracking which — is simpler than the slogan everyone quotes:
- Someone has the right to take the decision (named upfront, usually the domain owner).
- That same person has the responsibility to get the right input — actively, not passively. Talk to people affected. Talk to people with expertise. Don't decide in a vacuum and call it leadership.
Only after that comes the bit people shorten to disagree and commit. And honestly, "disagree and commit" is a harsh label for something that shouldn't feel harsh if step 2 was done properly. It's not "shut up and execute." It's: we talked, I was heard, you own the call, I won't block the fork.
Where this shows up in the literature
Advice process (Reinventing Organizations wiki, Laloux summary) is almost exactly the model: anyone can decide, but first they must seek advice from everyone meaningfully affected and everyone with relevant expertise. Advice is taken seriously — not a veto. Voice, not vote. The decision-maker still chooses. Laloux calls it a third way between hierarchy and consensus.
Apple's DRI (Directly Responsible Individual — Coinbase's writeup states it clearly): having a DRI "does not mean that one person decides in a vacuum." One person is responsible for collecting input from all relevant sources and making the final call. They're accountable for doing that job, not just for the outcome.
Andy Grove (High Output Management, summarised here) splits the process in the right order: free discussion → clear decision → full support. Before you even get there, answer six questions — including who will need to be consulted prior to making the decision? and who will ratify or veto? Grove is often quoted for "disagree and commit," but the book is really about consult first, decide clearly, then support. Skipping consultation and jumping to commit is what makes it feel authoritarian.
Bain RAPID (HBR / Bain, Bridgespan PDF) separates Input (expertise, no veto) from Decide (single point of accountability). The "I" must be consulted; the "D" makes the call. Same shape.
SPADE (Rajaram / First Round) is heavier than you need at founder scale, but the sequence is right: consult → decide → commitment meeting (pledge support out loud). Rajaram's line I keep coming back to: "What is important isn't that everyone agrees, it's that everyone is listened to. And then the right person makes a decision."
What I say at the end (after input, not instead of it)
At founder scale the close is often just:
"Your call. I've said my piece. I'm not convinced, but I don't need to be. We go with your view until [date]. I won't relitigate in Slack."
That's the commit step — and it only works if the owner did the consult step. If they didn't, you're not disagreeing and committing. You're being overruled.
Frances Frei adds a useful middle beat: disagree → understand → commit. The bar isn't agreement. It's "reasonable people could disagree, and we've both been heard."
Bezos's 2016 letter version — "will you gamble with me on it?" — assumes the debate already happened. It's a closing ask, not a substitute for one.
One counter-school: Wistia's founders don't want to commit to things they don't believe in; they keep talking until there's real buy-in. Fair for some two-person creative partnerships. In most early startups I see, the failure mode is the opposite — endless re-debate because nobody was ever named as decider and nobody chased input properly.
ABC buckets — the bit that actually sticks
The most useful thing I found digging through founder-agreement stuff isn't a legal contract. It's a one-page decision map with three buckets. Ascent Incubator names them cleanly; Ramp's founders-agreement writeup and Mercury's cofounder prenup questions say the same thing with different words.
| Bucket | Rule | Examples |
|---|---|---|
| A — Domain owner decides | One founder has final call in their area; partner commits | Feature order this cycle; vendor under €Y; how you ship |
| B — Discuss, then break ties | Both care; deadlock is unacceptable. At 50/50 you need a named tie-break (usually CEO) | Pricing test; spend between €Y and €X; cross-domain prioritisation |
| C — Unanimous | No override | Equity, fundraising, add/remove founder, sell company, hire approval, spend above €X, pivot |
When you're in an argument, you don't renegotiate the process. You look up the bucket.
Bucket A is the advice-process zone: owner decides, owner consults, partner commits once heard. Not "decide alone," not "consensus forever."
Bucket C is where disagree-and-commit does not apply. If you truly deadlock on fundraising or a pivot, you need a different conversation — mediator, advisor, or "maybe we shouldn't be doing this together." YC's co-founder questionnaire puts that in question 10: decide what happens when you're stuck, before you're stuck.
Bucket B is the messy middle. Ascent puts "pricing tests, feature prioritisation, small spend limits" here. With two founders, "majority vote" is a joke. Pick a tie-break. Elad Gil is blunt: "equal but we each own our area" breaks the moment product and GTM overlap. Someone has to be able to decide across domains.
What the sources agree on (and where they differ)
I went through a pile of this while building the Who Decides What wiki entry. Short version:
They agree:
- One person owns the decision; that person must actively gather input — not decide alone. (Advice process, Coinbase on DRIs, Grove's six questions.)
- Consensus for everything is slow and vague. Someone has to own the outcome. (Rajaram: "consensus means no ownership.")
- Decide process before the fight. CEO tie-break, domain owner, or advisor — pick one. (Matt Munson's co-founder questions, Ramp.)
- Domain owners for day-to-day; unanimity for existential. (Ascent, Ramp, Mercury, Equity Matrix template.)
- Personal runway affects which forks you can afford. Shortest runway sets company constraint — not weakness, just math. (YC Q7, Wasserman.)
- Revisit the map quarterly. Companies change. (Ascent / HBS founders-agreements framing.)
They differ:
| Camp | Says |
|---|---|
| Consult → decide → commit (Advice process, DRI, Grove, RAPID, SPADE) | Input duty first; commit is the close, not the whole model |
| Disagree and commit (Bezos soundbite) | Closing step after debate — harsh label if consultation was skipped |
| Passion partnership (Wistia) | Don't commit to what you don't believe. Find alignment. |
| Unequal clarity (Elad Gil) | CEO must be able to override; "we decide everything together" is a time bomb. |
| Lightweight buckets (Ascent, Ramp) | Write A/B/C once; don't over-lawyer at MVP stage. |
My default for the teams I advise: buckets + consult/decide/commit in A and B, real unanimity in C, quarterly refresh. Not because it's theoretically perfect — because repair is miserable.
Before the buckets: three founder conversations
Buckets sit on top of three things founders often skip:
- Skill + passion map — Ada Lin's Areas of Responsibility exercise: rate skill and passion per domain; cluster ownership. Passion breaks ties.
- Personal runway — months without salary, partner income, minimum you need to stay full-time. Shortest runway wins as a constraint on strategy.
- Founder sync — Amy Buechler's template: weekly 60–90 min, founders only. Roles and money on the agenda, not in the hallway.
If you skip these, your ABC map is guesswork.
Template — copy and fill in
One page. Google Doc is fine. Review every quarter.
Domain owners (feeds Bucket A)
| Domain | Owner |
|---|---|
| Product / roadmap | |
| Engineering | |
| Sales / GTM | |
| Ops / finance |
Bucket B — discuss, then tie-break
*Tie-break @ 2 founders (usually CEO): ___
| Topic | Notes |
|---|---|
| Spend from €_ to €_ | Between pocket money and Bucket C |
| Pricing / packaging tests | |
| Cross-domain prioritisation |
Bucket C — unanimous (show this bit to the team)
- [ ] Hiring approved (offer band agreed; contract from template)
- [ ] Spend above €____
- [ ] Fundraising / external capital
- [ ] Equity changes / new founder
- [ ] Pivot or sell / material strategy change
When we disagree in Bucket A
Owner: named decider + duty to consult affected founder(s) and relevant expertise before calling it.
Non-owner: after being heard, says out loud: I've said my piece. Your call. I back it until [date / milestone].
Grove checklist (before the fork): What decision? By when? Who decides? Who must be consulted? Who can veto? Who needs to know?
Rituals
- Founder sync: weekly, ___ min
- ABC map review: quarterly, 30 min
- Decisions that matter → written down within 48h (see communication norms)
Maintenance, not repair
The pattern I see in teams that stall:
- Roles assumed from titles, never discussed.
- "We'll figure out the process when it happens."
- The same fork argued for three weeks while a hire, a customer, or a runway clock waits.
- The awkward 'I don't think we need consensus on this' is not said, but it is felt.
The pattern in teams that move:
- One awkward evening filling in the template.
- A weekly founder slot where disagreement is allowed.
- A sentence at the end: who owns this, and when do we revisit.
You don't need conviction on every route. You need a rule for the fork — and the discipline to take it.
Full decision map by stage (schools, sources, edge cases) lives in the proposal doc behind the wiki. Published wiki: First Hires · Early Revenue · Growth. If you fill in the template and want to sanity-check it against your stage, the diagnostic's Who Decides What section is the place to start.