Design Decision Rights Framework

---
name: design-decision-rights-framework
description: Use when an organization repeatedly experiences slow or contested strategic and operational decisions because it's unclear who has actual authority to decide — explicitly mapping decision types to the specific role or body with final decision authority, distinct from who merely provides input, rather than leaving decision authority ambiguous and re-litigated each time a similar decision arises.
source: Bain & Company, RAPID decision-making framework (Rogers & Blenko, "Who Has the D?", Harvard Business Review, 2006)
tags: [business, operations, decision-rights, decision-making, governance, organizational-clarity]
related: [design-raci-matrix, design-organizational-structure, design-committee-charter-framework]
---

# Design Decision Rights Framework

Explicitly map decision types to the specific role or body with final decision authority, distinct from who merely provides input — rather than leaving decision authority ambiguous and re-litigated each time a similar decision arises.

## Why This Is Best Practice

**Adopted by:** Bain & Company's RAPID framework (Recommend, Agree, Perform, Input, Decide), introduced in Rogers & Blenko's "Who Has the D?" (Harvard Business Review, 2006), is one of the most widely adopted decision-rights frameworks in corporate strategy and organizational design practice, used to clarify decision authority across large, complex organizations where ambiguous authority repeatedly slows decision-making.
**Impact:** Bain's own research documents that decision effectiveness (the speed and quality of organizational decision-making) correlates more strongly with clarity of decision rights than with almost any other organizational design factor studied — organizations with clear decision rights make faster, more consistently executed decisions than organizations with equivalent talent but ambiguous decision authority.
**Why best:** Ambiguous decision authority means every decision of a given type gets re-litigated from scratch — who actually has the final call is negotiated anew each time rather than settled once, producing slower decisions and, worse, decisions that get revisited after the fact because the people who felt entitled to a say weren't clearly excluded from final authority in advance.

Sources: Rogers & Blenko, "Who Has the D? How Clear Decision Roles Enhance Organizational Performance," Harvard Business Review (2006); Bain & Company, RAPID decision-making framework

## Steps

### Step 1: Identify the recurring decision types causing friction

Identify the specific categories of decisions that recur and currently experience friction, delay, or repeated re-litigation — pricing decisions, hiring above a certain level, product feature prioritization — rather than attempting to map decision rights for every conceivable one-off decision the organization might face.

### Step 2: Assign a single Decide role for each decision type

For each decision type, assign a single role or individual with final decision authority (the "D" in RAPID) — exactly one decider, since diffuse or shared final authority reproduces the ambiguity the framework is designed to eliminate.

### Step 3: Distinguish Input providers from the Decide role explicitly

Explicitly distinguish who provides Input to inform the decision from who holds final Decide authority — input providers contribute their perspective, but the decision doesn't require their agreement, a distinction that prevents input from being mistaken for veto power.

### Step 4: Identify who must Agree, distinct from who merely provides Input

For decision types requiring formal sign-off from a specific party (e.g., legal or finance approval for contractual commitments), identify this Agree role explicitly and distinctly from Input providers — an Agree role has an actual veto within its specific domain, unlike an Input role.

### Step 5: Communicate the framework and apply it consistently

Communicate the resulting decision-rights map broadly enough that people understand, before a decision arises, who holds final authority for it — and apply it consistently, since a decision-rights framework that's overridden inconsistently reintroduces the same ambiguity and re-litigation the framework exists to prevent.

## Rules

- Assign exactly one Decide role per decision type — shared or diffuse final authority reproduces the ambiguity the framework exists to eliminate.
- Explicitly distinguish Input (perspective sought, no veto) from Agree (formal sign-off, actual veto within a specific domain) — conflating these misrepresents what each role's involvement actually means.
- Focus the framework on genuinely recurring decision types experiencing real friction, not an exhaustive map of every conceivable decision.
- Apply the framework consistently once established — inconsistent application reintroduces the ambiguity and re-litigation the framework is meant to prevent.

## Examples

**Clear Decide authority ending repeated re-litigation:** A company's product pricing decisions previously involved sales, finance, and product leadership each believing they held final say, causing repeated delays and post-decision disputes. A decision-rights map assigns the VP of Product as the sole Decide role for pricing, with finance holding an Agree role specifically for margin-threshold compliance and sales holding an Input role — resolving the ambiguity and eliminating the repeated re-litigation.

**Input correctly distinguished from veto power:** A cross-functional decision-rights map specifies that regional sales leaders provide Input on a global product roadmap decision but do not hold Agree authority. When a regional leader disagrees with the final roadmap decision, the framework's clear distinction between Input and Agree means their disagreement is heard but doesn't block the decision — exactly the outcome the framework's explicit role distinction was designed to produce.

## Common Mistakes

- **Assigning shared or joint Decide authority for a single decision type** — this reproduces exactly the diffuse-authority ambiguity the framework exists to eliminate.
- **Conflating Input with Agree** — treating every input-providing stakeholder as having effective veto power defeats the purpose of distinguishing advisory input from binding sign-off.
- **Attempting to map decision rights for every conceivable decision rather than focusing on recurring, high-friction decision types** — this produces an unwieldy, low-value exercise; focus on decisions that actually recur and currently cause friction.
- **Establishing the framework but not applying it consistently** — inconsistent application (allowing decisions to be re-litigated outside the framework when convenient) undermines the clarity the framework is meant to provide.

## When NOT to Use

- For a very small organization where decision authority is already genuinely clear through direct, informal communication — formal decision-rights documentation adds overhead without addressing an actual ambiguity problem in this case.
- For a genuinely novel, one-off decision with no recurring pattern — the framework's value is in resolving ambiguity for decisions that recur, not in mapping authority for a unique situation that won't come up again.
- As a substitute for task-level responsibility assignment within a known process — decision rights address who has final strategic or operational authority; task-level execution ownership within an already-decided process is better addressed by a RACI matrix (see `design-raci-matrix`).