The Startup Decision-Rights Register: Who Decides What as the Team Grows

A startup decision-rights register should answer one practical question: who can make this recurring decision, within which boundaries, using what input, by when, and when must it be escalated or reviewed? It is not an org chart and it is not a list of every responsibility. It is a compact operating record for decisions that otherwise bounce between founders and functional leaders.

As a team grows, “the founder decides” stops being a useful operating model before it stops being technically true. People may own work without knowing which tradeoffs they may settle. Leaders ask for autonomy but reverse decisions after the fact. Teams invite more people to meetings because authority is unclear, then confuse attendance with approval.

The fix is not to distribute every decision. It is to make the distribution explicit.

At Stackmatix, the growth agency I co-founded, our work sits across acquisition, sales, measurement, and operating handoffs. That commercial perspective informs this template. The framework and hypothetical example are editorial recommendations, not reported client results or universal benchmarks. External sources were checked on October 25, 2026.

A responsibility chart is not a decision-rights system

Owning a function, doing the work, and making a decision are different jobs.

A head of marketing may own pipeline creation but not have authority to change the ideal customer profile. A product manager may drive a release but need security approval before changing data retention. A salesperson may negotiate a deal but lack authority to grant a pricing exception. Writing “marketing owns growth” does not resolve any of those boundaries.

Current public operating guidance makes this distinction visible in different ways:

• GitLab's handbook says a Directly Responsible Individual owns a project, initiative, or activity and may hold final decision power, while still consulting relevant stakeholders. It also notes that execution ownership and the final decision maker can differ. GitLab: Directly Responsible Individuals.
• Atlassian's DACI play separates the driver who moves the process from the single approver who makes the decision, contributors who provide expertise, and people who need to be informed. Atlassian: DACI decision-making framework.
• AWS guidance recommends distinguishing one-way decisions from reversible two-way decisions so teams know when to escalate and when they can act. AWS Well-Architected: empower team members to take action.

Those are useful references, not a reason to import a heavyweight governance program. A startup usually needs a small register for the decisions that recur, cross functions, or carry material downside.

Use the RIGHTS record

For each recurring decision, document six parts: Result, Individual, Guardrails, Hearing, Trigger, and Send.

The acronym is less important than the fields. If the record does not specify a single decider, real boundaries, and an escalation trigger, it is only a polished description of ambiguity.

Result: make the decision small enough to own

“Own pricing” is too broad. It contains list price, packaging, contract terms, sales discounts, renewal changes, billing units, and promotional tests.

Write a question a person could actually answer:

• May sales approve a discount for this opportunity?
• Should marketing move the next $15,000 between channels?
• Does this product request enter the next planning cycle?
• Can the company publicly make this performance claim?

If one row contains several decisions with different risk or expertise, split it.

Individual: name the decider, not a department

Use one person's role, not “leadership,” “product,” or “the GTM team.” The named person can consult widely without turning every contributor into a veto holder.

Also name a driver when someone else gathers evidence and manages the deadline. For a major pricing change, a product marketer might drive the analysis while the CEO decides. For a reversible campaign test, the marketing lead may be both driver and decider.

Avoid two common traps:

1. The decider is secretly the founder. A functional leader appears in the record, but everyone knows the founder can reverse the call without using the stated escalation path.
2. The decider is also every approver. The row names one owner but lists four functions that must all agree. That is consensus with an owner-shaped label.

Guardrails: define delegated authority as a range

Delegation should not mean “use good judgment.” State the permitted range.

A marketing leader might move up to 15% of a monthly paid budget among approved channels, provided the move does not change the customer segment, claim set, or measurement contract. A sales leader might approve a discount within a defined band if standard payment, term, security, and legal conditions remain unchanged.

Guardrails can include:

• maximum spend, discount, contract length, or service credit;
• approved customer segments and excluded use cases;
• claims that require evidence or legal review;
• data access, privacy, and security constraints;
• margin, capacity, or implementation requirements;
• decisions explicitly reserved for the board or founders.

The goal is not to anticipate every exception. It is to make the normal case fast and the exceptional case visible.

Hearing: require input without creating hidden vetoes

Record the evidence that must be considered and the people who contribute it. Then state whether their input is advisory, a policy approval, or a blocking control.

For example, finance may contribute margin analysis to a pricing decision. Legal may have blocking authority over a nonstandard indemnity clause. Customer success may advise on implementation risk. These are not the same relationship.

Use the smallest evidence set that can support the decision. A reversible landing-page test may need a message hypothesis, baseline, traffic threshold, and stop rule. A change to annual pricing may need customer research, unit economics, operational impact, competitive evidence, and a migration plan.

The customer advisory loop is useful when buyer or user input should inform the decision without becoming a vote.

Trigger: specify when authority changes

Every row needs a clock and an exception path.

Record:

• the deadline for the normal decision;
• the default if no decision is made;
• conditions that require escalation before the deadline;
• the event that reopens a completed decision;
• the person who resolves a conflict between two rights records.

Reversibility should change the process. A low-cost two-way decision can usually have a short deadline, narrow evidence, and a clear rollback. A one-way decision that materially affects customer trust, financing, regulatory exposure, or an irreversible commitment deserves wider consultation and a more senior decider.

Do not call a decision reversible merely because software can be rolled back. A public promise, customer migration, employee action, or contract can create consequences that persist after the technical change is undone.

Send: close the gap between decision and execution

A decision is not complete when the decider says yes. Record:

• the exact option chosen;
• the date and evidence version;
• the owner of the first execution step;
• who must be informed before work begins;
• the system where the durable record lives;
• the metric or event that will trigger review.

This connects the register to the startup decision-meeting discipline: the meeting can resolve an exception, but the operating system should preserve the authority and outcome afterward.

Build the first register from recurring friction

Do not start by mapping the entire company. Review the last four to six weeks and find decisions that produced one of these signals:

• the same question returned to a founder more than once;
• work paused because two leaders believed the other person owned the call;
• a delegated decision was reversed without a stated boundary being crossed;
• a customer exception created unplanned delivery, margin, legal, or security work;
• a meeting ended with more analysis but no decider or deadline;
• a team acted quickly, but affected people learned about the choice too late;
• a leader owned an outcome without authority over the process or data required to change it.

Select five to ten recurring decisions. That is enough to reveal whether the model works. The RevOps ownership analysis applies the same principle to revenue systems: responsibility only becomes useful when the owner has real change authority.

A hypothetical 18-person SaaS register

The following example is hypothetical. It illustrates routing, not recommended spending limits, discounts, staffing ratios, or performance benchmarks.

Now work one row through the full RIGHTS record.

Hypothetical decision: May sales approve a 7% discount for a $48,000 annual contract?

• Result: Decide whether to approve the discount without changing scope, payment terms, implementation, or support.
• Individual: Sales lead decides; account executive drives the record.
• Guardrails: Up to 10%; annual prepayment; standard agreement; standard onboarding; no roadmap promise; modeled gross margin remains above the company's internal floor.
• Hearing: Account executive supplies the buyer's stated constraint and alternative path. Finance confirms the arithmetic. Customer lead confirms delivery scope. Their input is required; finance blocks only if the stated margin rule fails.
• Trigger: Decision due within one business day. Escalate to the CEO if any guardrail fails or if the buyer requests a precedent-setting term. Default is standard price if the record is incomplete.
• Send: Record the approved terms and reason code in the CRM, notify finance and the customer lead, and reopen the policy after ten completed exception records or one observed delivery failure.

The point is not that 7% is safe. The point is that the team can see why this decision stays with the sales lead while a superficially similar deal must escalate.

Copy this decision-rights template

Use one record per decision class:

```text Decision question: Business outcome affected: Decision class: reversible / conditional / one-way / emergency

Driver: Single decider: Execution owner:

Authority granted: Non-negotiable guardrails: Explicitly out of scope:

Required evidence: Contributors and role of each input: Blocking controls, if any:

Decision deadline: Default if incomplete: Escalation conditions: Escalation owner:

People to inform: System of record: Review trigger or date: Current version and effective date: ```

Keep the register next to the work, not in a founder-only document. Link specific policies, evidence definitions, and approval workflows rather than duplicating them inside the row.

Diagnose a broken register

Run this review after the first month:

Do not measure success by the number of rows completed. Inspect operating evidence:

• median time from complete input to decision;
• share of decisions made by the named decider;
• exception and escalation reasons;
• decisions reversed because a guardrail was missed;
• decisions reopened by the planned review trigger;
• founder overrides outside the documented path;
• people informed too late to execute safely.

These measures are diagnostics, not targets to game. A low escalation rate can mean good delegation or hidden risk. Read the record behind the number.

Roll it out in 30 days

Week 1: collect friction. Review delayed, reversed, repeated, and surprising decisions. Select five to ten recurring classes.

Week 2: draft boundaries. Have the current functional owner draft each RIGHTS record with the person who presently holds final authority. Use the hiring scorecard logic here: define observable acceptance criteria, not personality-based trust.

Week 3: test real decisions. Route live work through the register. Capture missing evidence, unclear overlaps, late notifications, and escalation cases. Do not quietly work around a broken row.

Week 4: ratify and publish. Resolve conflicts, version the records, name a register owner, and set the next review. Retire rows for decisions that no longer recur.

The founder should not disappear from consequential decisions. The founder should stop being the invisible approval layer for routine decisions. A good decision-rights register makes authority legible enough for people to act, bounded enough for the company to manage risk, and reviewable enough to improve as the team grows.

Matt Pru

Co-founder and CEO of Stackmatix, startup advisor, and former Head of Sales at MightyHive. Connect with Matt on LinkedIn ↗ · More about Matt →