Decision Rights Matrix for Founder-Led Startups

Most startup decision problems are not caused by a lack of intelligence. They are caused by an invisible contract.

One person believes they own the decision. Another believes they can recommend but not approve. The founder believes the team should move independently, then reverses a decision because an unstated threshold was crossed.

A decision-rights matrix makes that contract inspectable. It does not assign every possible choice. It defines the recurring decisions that currently create waiting, duplication or surprise.

Download the startup decision-rights matrix. It includes the conditions and escalation boundary that simpler RACI tables often omit.

Start With Decisions That Already Hurt

Do not begin by listing every responsibility on the organisation chart. Pull decisions from evidence:

• approval requests that wait in private messages;
• choices reversed after work has begun;
• recurring exceptions sent to the founder;
• two functions acting on the same issue;
• no owner acting because each expects the other to move;
• customer commitments accepted without delivery review;
• incidents where response authority was unclear.

Name each decision as a choice, not a topic. “Pricing” is a topic. “Approve a non-standard annual discount” is a decision.

The Seven Fields

Decision

Describe a repeatable decision class narrowly enough that its boundary can be tested.

Default owner

Name one role with the authority to decide inside the boundary. A committee cannot be accountable for response time.

GitLab publishes a concrete version of this principle in its directly responsible individual guidance: one DRI owns the outcome while other people may contribute. A startup matrix adds the conditions, escalation and evidence needed to make that ownership safe.

May decide when

List the conditions under which the owner can act without further permission. Include required evidence.

Must consult

Consultation means a named person supplies evidence before the decision. It does not mean the person gains an informal veto.

Escalate when

Define consequence-based thresholds: policy conflict, margin floor, data risk, legal exposure, irreversible customer impact or uncertainty above an agreed level.

Response time

Set the service expectation for a usable decision. This makes waiting visible and allows an alternate owner when the default is unavailable.

Evidence record

State where the decision, context and reasoning live. The record is what turns one decision into organisational learning.

A Hypothetical Example

Consider customer credits at a SaaS company.

The current rule is “ask finance and the founder”. Requests wait because neither party knows who decides.

The matrix row becomes:

Decision: approve a customer credit for a service failure
Default owner: customer success lead
May decide when: incident is verified and amount falls within policy band
Must consult: finance for ledger treatment
Escalate when: amount exceeds band, fraud is suspected or legal terms conflict
Response time: four business hours
Evidence: CRM decision record linked to incident

This does not remove judgment. It places routine judgment near the evidence while preserving a clear path for consequential exceptions.

Decision Rights Are Not Task Ownership

A person can own preparation without owning the choice. A salesperson may prepare commercial evidence while a sales lead decides. A product manager may prepare customer evidence while an engineering owner decides whether a reliability threshold permits release.

Separate four roles:

1. Preparer: assembles the evidence.
2. Decider: accepts the consequence.
3. Executor: implements the choice.
4. Verifier: checks the expected outcome.

One person can hold several roles for low-risk decisions. Explicit separation matters when consequence or reversibility changes.

Use Risk to Set the Boundary

Assess:

• Reversibility: can the choice be undone?
• Blast radius: how many customers, records or rupees can it affect?
• Sensitivity: does it involve identity, security, finance, employment or legal obligations?
• Observability: will a poor outcome be detected quickly?
• Precedent: does the choice create a rule others will reuse?

Keep high-consequence, weakly observable choices concentrated. Move reversible, observable choices closer to the work. This is more useful than a generic instruction to delegate more.

Install the Matrix in Three Passes

Pass 1: document reality

Write who decides today, including founder intervention that occurs outside the official process. A false current-state map produces a ceremonial future state.

Pass 2: design the boundary

Review recent examples. Ask what evidence the founder used and which cases truly required founder judgment. Turn repeated reasoning into conditions and escalation thresholds.

Pass 3: test and review

Run the new boundary for a fixed period. Record decisions, reversals and exceptions. Review whether the boundary was too narrow, too broad or missing information.

Do not treat an exception as proof that delegation failed. Exceptions are the evidence needed to refine the rule.

Make the Language Operational

Avoid words that cannot be consistently tested: significant, large, urgent, strategic, sensitive and reasonable.

Replace them with an observable condition or named policy. If a number would create false precision, define a decision test:

Escalate when the concession changes implementation scope, contradicts the standard contract or creates an obligation the receiving owner has not accepted.

The IETF’s RFC 2119 created explicit meanings for requirement words such as MUST, SHOULD and MAY in technical specifications. A startup policy does not need to imitate RFC formatting, but it benefits from the same principle: people should understand whether a step is required, recommended or permitted.

Prevent Founder Override From Breaking the Contract

Founders retain the right to intervene. The operating rule should require the intervention to leave evidence.

When an in-boundary decision is reversed, record:

• which assumption or threshold changed;
• whether new evidence appeared;
• whether the decision rule must change;
• who needs to know before using the old rule again.

Silent overrides train the team to wait. Explained overrides improve the system.

Review the Right Signals

For each decision class, track:

• median response time;
• decisions made by the default owner;
• escalations and their triggers;
• reversals and reasons;
• exceptions that changed policy;
• outcome measure the decision exists to protect.

Do not reward fewer escalations without context. That can encourage owners to hide uncertainty. Reward appropriate use of the boundary and high-quality evidence.

The founder-dependency audit helps identify which rows to create first. The SOP guide helps turn stable execution steps into usable documentation. Decision rights should come first when the procedure currently stops at “ask the founder”.

Run the matrix on five decisions for four weeks. If the same work still waits despite clear boundaries, the missing layer may be information or operating cadence. The full seven-layer startup operating-system map helps trace that connection.

If several functions need to renegotiate consequential boundaries, bring the current decisions and recent exceptions to a working session.