Nerdy
RAPID Model
When decisions stall, it's almost never because people lack information. It's because nobody knows who actually gets to make the call. RAPID fixes that by assigning one unambiguous decider.
Overview
RAPID is Bain & Company’s framework for assigning decision roles. Each letter maps to a role: Recommend (proposes the action), Agree (must sign off; has a formal veto), Perform (executes after the decision is made), Input (consulted for facts or judgment, but not binding), and Decide (the single person who commits the organization to a course of action). The power of the model is in forcing exactly one D per decision; when everyone thinks they’re the decider, nothing moves.
We reach for RAPID when teams or leadership groups are stuck in consensus loops or when accountability is diffuse. It pairs well with Stakeholder Mapping because the stakeholder categories (Driving, Enrolled, Impacted, Informed) map naturally onto RAPID roles. It also complements Small, Cross-functional Teams, which concentrate decision rights at the team level; RAPID does the same thing at the organizational or initiative level. The key move is making the D explicit and non-negotiable; everything else is negotiation about who provides input versus who holds a veto.
Examples
Co-building a Strategic Bet
| Role | Actor |
|---|---|
| R — Recommend | Platform group lead + business group PM |
| A — Agree | Architecture lead (interface contracts, coupling risk) |
| P — Perform | Platform team (shared infrastructure); stream-aligned team (business features) |
| I — Input | Other stream-aligned teams consuming the platform; enabling team |
| D — Decide | GM or VP sponsoring the bet |
When two groups co-build, the D must sit above both. Without explicit roles, each group assumes they own the decision for “their” piece and nobody owns the seams.
Sunsetting a Legacy Flow
| Role | Actor |
|---|---|
| R — Recommend | Product trio (PM, Designer, Tech Lead) |
| A — Agree | Head of Customer Support (migration risk) |
| P — Perform | Stream-aligned team owning checkout |
| I — Input | Data/analytics team; downstream teams consuming checkout events |
| D — Decide | Product Director |
The trio recommends but doesn’t decide on high-impact calls that cross team boundaries.
Splitting a Team
| Role | Actor |
|---|---|
| R — Recommend | Engineering manager for payments |
| A — Agree | People Ops lead (headcount and hiring implications) |
| P — Perform | EM + affected team members |
| I — Input | Current team members; adjacent team leads; product manager |
| D — Decide | VP of Engineering |
Team members provide input but don’t hold veto power over structural decisions. Team Topologies treats cognitive load as the trigger for splits; RAPID clarifies who makes the call.
Allocating Capacity for Technical Investment
| Role | Actor |
|---|---|
| R — Recommend | Engineering leads, citing DORA metrics |
| A — Agree | Product Director (capacity trade-off impacts roadmap) |
| P — Perform | Stream-aligned + platform teams |
| I — Input | SRE team; delivery managers with flow metrics |
| D — Decide | CTO |
A can represent a business constraint, not just a technical one. The Product Director’s veto forces engineering to make the case in terms of outcomes, not just metrics.
Resources
- Paul Rogers and Marcia Blenko, “Who Has the D?” (Harvard Business Review, January 2006) — the original article that popularized the framework
- Marcia Blenko, Michael Mankins, and Paul Rogers, Decide and Deliver: Five Steps to Breakthrough Performance in Your Organization (Harvard Business Review Press, 2010)
- Stakeholder Mapping — complements RAPID by mapping who is affected and what they gain or sacrifice
- Small, Cross-functional Teams — decision rights at the team level
- By What Method — once the D is clear, the next question is how