How to Design Decision Rights for a Scaling Company

How to Design Decision Rights for a Scaling Company

A useful decision-rights system gives each recurring decision one operating owner, the necessary contributors, any required approver, a named executor, an escalation path, a communication rule, and a review trigger.

It does not pretend that every decision is the same. It also does not confuse operating ownership with legal authority.

Start with a decision that is already causing friction

In E052, I used the familiar tension between product and engineering. Product may press for customer value and a date. Engineering may press for reliability, security, maintainability, and credible scope. Both can be right about different parts of the same choice.

The problem becomes expensive when no one knows who can decide, what evidence matters, or when disagreement should escalate.

Elad Gil’s organization chapter describes structure as a pragmatic response to growth, bandwidth, and tie-breaking. Before changing reporting lines, document the decision itself.

flowchart LR
    A["Trigger"] --> B["Operating owner"]
    B --> C["Required contributors"]
    C --> D["Applicable approval"]
    D --> E["Execution"]
    E --> F["Communication"]
    F --> G["Evidence review"]
    C --> H["Escalation"]
    H --> D

Define the decision at the right grain

“Product decides product” is too broad. A real interface may include customer problem selection, roadmap sequence, release scope, architecture, security acceptance, production readiness, launch timing, pricing, claims handling, or regulated filing.

Write one sentence that names the trigger and the choice. For example: when a release has an unresolved reliability concern at the launch checkpoint, who decides whether to defer, reduce scope, accept the risk, or escalate?

That sentence reveals whether the company has one decision or several.

Separate the roles

The operating owner integrates evidence and is accountable for moving the decision toward resolution. Contributors supply expertise, constraints, and alternatives. An approver holds a real legal, contractual, policy, financial, or governance right. The executor performs the work. An escalation owner resolves a defined class of impasse.

One person may hold several roles, but the roles should not be collapsed by accident.

In a regulated insurance setting, a product leader may own the operating recommendation while a carrier, compliance function, licensed producer, underwriting authority, or board retains a particular approval. Naming the product leader “accountable” does not cancel those rights.

Write the evidence rule

Decision rights fail when the owner is named but the evidence is not.

Define what the decision packet must contain. A release decision might require customer impact, technical risk, security status, operational readiness, financial exposure, regulatory implications, alternatives, and the cost of delay. A hiring decision needs a different packet.

The rule should state which facts are mandatory, which estimates can be uncertain, and which missing evidence forces escalation. This reduces power contests disguised as factual disagreements.

Design escalation before the conflict

Escalation should be a normal mechanism, not a punishment.

Name the conditions that activate it. Those might include a deadline, material financial exposure, an unresolved safety or compliance issue, a conflict between reserved authorities, or a decision whose impact exceeds the owner’s stated boundary.

Then name the escalation destination and what it can do. The executive, committee, CEO, or board should receive a concise record of the disputed point, evidence, options, recommendation, and deadline.

An odd number of people or a higher-ranking title does not automatically produce a valid decision. The authority must match the matter.

Communicate the result and the reason

A decision is not complete when the meeting ends.

Record the choice, owner, date, decisive evidence, known uncertainty, affected teams, execution lead, and review condition. Tell people who must act and people whose work is materially affected.

This is particularly important when the decision reverses an earlier direction. Without a short reason, teams may keep executing the old assumption or treat the change as arbitrary.

Review the system, not only the outcome

At the review date, ask whether the result was acceptable and whether the process worked.

Did the right owner receive the issue? Were contributors involved early enough? Did an approver enter only at the end? Was escalation too sensitive or too late? Did the company collect the evidence it said mattered? Did people understand the result?

The answer may call for a new role, better information, a different threshold, or a structural change. Gil’s reorganization chapter can help frame a broader change, but a reorganization should not be the reflexive answer to one unclear interface.

Respect people whose roles change

Scaling can alter the work of founders, early employees, and managers. Describe those changes in observable terms: scope, decisions, expected outcomes, support, skills, reporting, and authority.

Avoid diagnosing a person with a label or assuming that early contribution guarantees a later title. Also avoid erasing the value of the earlier work. A fair transition needs candid expectations, a chance to respond, and employment review appropriate to the jurisdiction and agreement.

The official onboarding chapter emphasizes real ownership for a new hire. That ownership is easier to create when the outgoing and incoming boundaries are explicit.

The smallest useful register

For one recurring decision, record its name, trigger, operating owner, contributors, approver, executor, evidence, deadline, escalation condition, communication audience, result, and review date.

Start with the decision that creates the most repeated friction. If the register improves it, extend the method to the next interface. Do not build a company-wide taxonomy before proving that people can use one record.

About this guide

This guide was developed from Venture Step E052 and current official High Growth Handbook chapters with AI assistance. It is educational, not legal, employment, regulatory, fiduciary, or governance advice. Actual decision authority must be checked against law, charter, contract, policy, license, and company-specific obligations.