- Decision scope
- Named owner
- Review + escalation
Cofounder conflict is often described as a relationship problem when the immediate failure is procedural: nobody knows who decides, what input is required, or when the discussion ends. A decision register will not create trust. It will stop ambiguity from spending it.
The founders and teams chapter treats unowned decisions as an operating risk. This guide supplies a lightweight system, not an equity, voting, fiduciary, or legal-governance template.
Separate operating ownership from legal authority
List recurring decision domains—product scope, pricing, hiring, security exceptions, customer terms, spending, fundraising, and communications. Give each domain one operating decider. Then mark decisions that also require board, shareholder, lender, investor, or contractual approval. The operating register cannot override those documents. Counsel should resolve conflicts between the register and governing agreements.
Atlassian’s vendor-authored DACI play assigns a Driver, Approver, Contributors, and Informed participants. It is a useful vocabulary, not proof that the framework fits every team (Atlassian DACI). GitLab describes a Directly Responsible Individual as owning a decision and escalating risks without necessarily doing all the work; that is also a company practice, not a universal rule (GitLab Handbook).
Build the register
Use one row per material decision:
| Field | What belongs there |
|---|---|
| Decision | One sentence that can be answered |
| Decider | One named person |
| Required input | Facts or people that must be consulted |
| Constraints | Budget, law, contract, runway, reversibility |
| Deadline | When the decision closes |
| Dissent | Best objection, recorded fairly |
| Decision and reason | Short enough to reread |
| Review trigger | Date or observable condition |
Consultation is not a hidden veto. If someone has approval authority, say so explicitly.
Worked hypothetical: pricing without permanent consensus
Worked hypothetical. Two founders disagree about moving a product from $500 to $800 per month. The commercial founder is decider for packaging within an approved annual plan. The technical founder must be consulted on support and infrastructure effects. Constraints are no custom features, gross margin above the internal floor, and existing contracts honored. The deadline is Friday.
The dissent records that the price may slow adoption before onboarding is strong. The decision is a three-month $800 test for new customers, with a review after 20 qualified opportunities or three months, whichever arrives first. The rollback trigger is not “we feel uneasy”; it is a material fall in qualified close rate without a compensating improvement in gross profit or customer fit.
Neither founder had to pretend agreement. The company got a bounded decision and preserved the objection for review.
Define disagreement before the next disagreement
Use three levels. Level one: the decider decides after required input. Level two: a decision crossing a stated constraint pauses for both founders and, if applicable, formal approval. Level three: deadlock on an existential issue invokes a pre-agreed mediator, independent director, or counsel-led process. Document who can call each level and the response time.
Add a “disagree and commit” rule only for reversible operating decisions. It is inappropriate where a founder believes the act is unlawful, unsafe, outside authority, or likely to cause serious customer harm.
Monthly maintenance
Review overdue decisions, repeated reversals, domains with no owner, and decisions whose real approver differs from the register. Retire rows once they become policy. Revisit domains after funding, board changes, or a founder role change.
Limitations: a register cannot cure bad faith, concealed information, incapacity, or a broken equity/governance structure. It is operating memory. Corporate approvals and founder rights live elsewhere and deserve qualified legal review.
Sources & scope
Sources checked 19 September 2026. Worked scenarios are illustrative; recommendations are editorial analysis. These checks do not re-verify the entire original notebook.
- DACI: A Decision-Making Framework — Atlassian
Atlassian’s published play assigns distinct roles for driving, approving, contributing to, and being informed about a decision. This is vendor-authored operating guidance, not legal governance authority.
- How We Report Progress — GitLab
GitLab states that a DRI owns the decision and escalation. A DRI need not personally execute all work.
Developed from the original notebook
- A11. Culture, leadership and decision-making — Develops the single-owner principle into a decision register.
- A12. Founder conflict: what the data actually supports — Adds disagreement, escalation, and review without repeating an unsupported failure statistic.