Sign in
← All posts

Rapid Decision Making in 90 Days: 30/60/90 Playbook for Leaders

Adopt rapid decision making fast with a practice-led 30/60/90 rollout. Includes rehearsal templates, decision artifacts, and leader-ready steps to cut...

Cody Flynn··16 min read

Leaders assigning decision ownership on a board

RAPID is a decision-rights framework, built by Bain & Company, that names who recommends a course of action, who must agree, who provides input, who performs the work, and who ultimately decides. It exists to stop the most common organizational failure mode: a decision with no clear owner, stalled by five people who all think they have veto power. Use it for cross-functional, recurring, or high-stakes calls, not for reversible day-to-day choices that a single manager can make alone.

TL;DR:

  • RAPID is most effective for cross-functional, high-stakes, and recurring decisions that require clear ownership and authority, not for simple or reversible choices.
  • Assign each RAPID role precisely, with one decision maker and limited Agree holders, to prevent delays caused by overlapping vetoes or vague recommendations.
  • Training, practice, and clear role documentation are essential to successful RAPID adoption, as rushed implementation often undermines trust and effectiveness.
  • In urgent or fast-changing situations, alternative techniques like the OODA loop or heuristics may speed decision-making but lack the structured accountability of RAPID.
  • Properly applying RAPID reduces decision stalls and increases accountability, but missteps like Agree inflation or shadow decision makers can weaken its benefits.

Table of Contents

What Rapid Decision Making Actually Solves

Bain consultants Paul Rogers and Marcia Blenko introduced RAPID in the mid-2000s after watching client after client struggle with the same problem: everyone felt accountable for a decision, so no one actually was. Their Harvard Business Review piece "Who Has the D?" became one of the most cited pieces of management writing on decision rights, and the underlying insight still holds. When five people in a meeting all believe they own the outcome, the decision doesn't get made faster. It gets made slower, or not at all.

RAPID stands for Recommend, Agree, Perform, Input, and Decide, and Bain built it specifically to separate the process of deciding from the authority to decide. That distinction sounds obvious until you sit through a project retrospective and hear three different people claim they were "the decision maker" on something that shipped six weeks late.

Naming decision rights matters for a few concrete reasons:

  • It converts vague ownership ("the leadership team decided") into a named individual accountable for the outcome.
  • It separates people who must be consulted from people who can veto, which is where most organizations quietly lose weeks.
  • It gives new hires and cross-functional partners a shared vocabulary instead of relearning each team's informal power structure.

The Five RAPID Roles and How to Assign Them

Each RAPID role does one job. Confusing two of them is the single fastest way to break the framework.

  1. Recommend (R): The person or small group who builds the actual proposal. The R gathers data, weighs options, and puts forward a specific recommendation, not a menu of equally weighted choices.
  2. Agree (A): People whose sign-off is required before the recommendation moves forward, usually because they own a resource, budget line, or legal risk tied to the outcome. An A can veto, but only on the grounds tied to their area.
  3. Perform (P): The people who execute once the decision is made. They often overlap with the R, but not always. Someone can recommend a new vendor contract without being the one who manages the relationship day to day.
  4. Input (I): Anyone consulted for expertise or context before the recommendation is finalized. Input is advisory. It shapes the recommendation but carries no veto.
  5. Decide (D): The single individual with final authority. Not a committee. One name.

Assignment rules that keep RAPID from collapsing into chaos:

  • Assign exactly one D per decision. If two names feel right, the decision hasn't been scoped narrowly enough yet.
  • Cap the number of As. Three or four is workable; eight turns every recommendation into a negotiation.
  • Let the R own the actual analysis and drafting work, not just the process of scheduling meetings about the decision.

A worked example: a mid-size software company deciding whether to sunset a legacy product line might assign the R to the product lead, As to finance and legal, P to the engineering and customer success teams, I to key account managers, and D to the VP of product.

Pro Tip: Write the D's name on the recommendation document itself, not just in a project charter buried three folders deep. If people have to ask "wait, who's deciding this?" the framework has already failed.

When RAPID Earns Its Overhead

RAPID takes time to set up. It's worth that time on decisions with certain traits, and a poor fit on others.

Apply RAPID when a decision is:

  • Cross-functional, touching more than one team's budget, headcount, or roadmap.
  • High-stakes, meaning a wrong call is expensive or slow to reverse.
  • Recurring, so the time invested in defining roles pays off across multiple future decisions, not just one.

Skip it when a decision is:

  • Easily reversible, so a wrong call costs little more than a quick correction.
  • Contained within a single team with an obvious existing owner.
  • Low-impact enough that formal role assignment costs more time than the decision itself is worth.

The three-question reversibility test cuts through most of the ambiguity: Is this decision reversible? Does delaying it cost something real? Would waiting produce meaningfully better information? If the answers point toward "reversible, cheap to delay, and information won't improve," skip RAPID and just make the call.

How to Roll Out RAPID Without Wrecking Team Trust

RAPID fails most often not because the framework is flawed, but because it gets introduced badly. Here's a sequence that avoids the usual landmines.

  1. Break the decision into components. A "go to market" decision usually hides five smaller decisions inside it: pricing, channel, timing, positioning, and budget. Map roles separately for each piece rather than assigning one blanket RAPID grid to the whole thing.
  2. Pilot with two or three decision templates. Pick low-risk, recurring decisions first, like vendor renewals or feature prioritization, and build a repeatable template before touching anything strategic.
  3. Run practice sessions before the real thing. Walk a fictional or past decision through the framework so people feel the mechanics before stakes are attached.
  4. Train cross-functional cohorts together, leaders included. Bain's own guidance is explicit here: rushed rollouts backfire, and training only a handful of managers while skipping the teams who actually do the work leaves the old informal power structure fully intact.
  5. Set explicit deadlines and escalation rules. Every RAPID grid needs a due date and a named escalation path for what happens if an Agree holder refuses to sign off.
  6. Document outcomes and measure. Track how long decisions actually took against the deadline, then revisit the role assignments that caused delays.

Pro Tip: Bain's own research points to heavy practice time, not just orientation slides, as the difference between adoption and abandonment. Budget more time for rehearsal than for the kickoff meeting itself.

Benefits and Trade-Offs of Committing to RAPID

The upside is real: fewer stalled decisions, faster execution once a call is made, and a paper trail that shows exactly who owns what. Teams that have struggled with "decision by exhaustion," where the loudest or most senior voice wins by attrition, tend to feel the difference within the first few pilot decisions.

The trade-offs are just as real:

  • Training time, especially the practice sessions Bain recommends, isn't free.
  • Cultural resistance shows up fast when someone who used to have informal veto power gets reassigned to Input.
  • Misapplied RAPID grids can accidentally exclude people who should have had a voice, which breeds resentment even when the process is followed correctly.

Track three metrics as you scale adoption: decision lead time (how long from framing to final call), escalation rate (how often a D or A dispute needs to go up a level), and execution slippage (whether decisions made actually ship on the timeline the P team committed to).

Common Pitfalls That Quietly Sabotage RAPID

Most RAPID failures trace back to four repeatable mistakes.

  • Agree inflation. When everyone wants a seat at the Agree table, veto power becomes meaningless. Require every A to state a specific, defensible reason tied to their domain, not a general sense of unease.
  • Shadow D. The named decider on paper isn't the person who actually makes the call. Name the real D transparently, even if that means admitting a senior executive is quietly overriding the formal owner.
  • Weak R and Input theater. If the R shows up with vague options instead of a firm recommendation, or if Input holders are consulted after the recommendation is already locked, the framework becomes decoration. Consult Input early, and require the R to submit an actual recommendation with a fallback option.
  • Undated decisions. A RAPID grid with no deadline just relocates the stall instead of resolving it.

Pro Tip: A useful governance habit: require every RAPID template to name the D, list the As with a one-line statement of their veto authority, and require the R to submit options plus a recommended fallback, all before the first meeting happens.

Rapid vs. RACI vs. DACI: Which Framework Fits

These three frameworks solve related but different problems, and mixing them up is a common source of confusion.

  • RAPID answers "who has the authority to decide?" It's built for judgment calls with real ambiguity and competing stakeholders.
  • RACI answers "who does the work?" It maps Responsible, Accountable, Consulted, and Informed roles across a project's execution, not its decision points.
  • DACI (Driver, Approver, Contributors, Informed) is a lighter-weight decision map, often used for smaller product or engineering calls where a full RAPID rollout would be overkill.

Prefer RAPID for strategic or cross-functional decisions where authority is genuinely contested. Prefer RACI for project execution once the decision itself has already been made and the work is about delivery. Teams that need both often run RAPID to decide what to build, then hand the resulting plan to a RACI chart to track who builds it. DACI works well as a lightweight substitute for either framework when the stakes are lower and speed matters more than rigor.

What Actually Speeds Up Adoption in Practice

Training and rehearsal aren't a nice-to-have layer on top of RAPID. They're the difference between a framework that sticks and one that quietly reverts to the old informal power structure within a quarter. Bain's own guidance on adoption is blunt about this: slowing down to practice beats rushing to roll out.

  • Shared, versioned decision artifacts cut down on Input theater because context gets captured once, not re-explained in five separate meetings.
  • Real-time collaboration between the R and Input holders shortens the handoff to Perform, since the recommendation reflects actual pushback rather than a guess at what stakeholders might object to.
  • Tools that let a team draft, argue, and version a recommendation together, the way SwarmStack structures collaborative planning sessions with human experts and AI specialists, can shorten the distance between "we have input" and "we have a decision."
  • Pilot any new tool on one or two decision templates before linking outcomes to execution trackers like GitHub or Jira.

Fast Decision Techniques Beyond the RAPID Framework

RAPID assumes you have time to define roles before the decision hits. Plenty of real decisions don't. A handful of other techniques handle speed differently.

The OODA loop (Observe, Orient, Decide, Act), developed by military strategist John Boyd, is built for situations changing faster than a role chart can be drawn. Instead of assigning fixed roles, it assumes one person or small team cycles continuously through observation and action, adjusting as new information arrives. It fits crisis response and fast-moving competitive situations better than it fits recurring organizational decisions.

The Eisenhower matrix sorts decisions by urgency and importance into four quadrants, helping people decide what deserves immediate attention versus what should be delegated or dropped entirely. It's a triage tool more than a decision-rights tool, useful for individuals drowning in competing demands rather than teams negotiating authority.

Fast-and-frugal heuristics, a concept from psychologist Gerd Gigerenzer's research, argue that simple rules often outperform complex analysis under time pressure, because they ignore noisy variables that don't actually predict outcomes. A doctor triaging chest pain with a three-question checklist, rather than running every possible test, is using a fast-and-frugal heuristic.

The 5-second decision rule applies the same logic to low-stakes daily choices: cap deliberation time on trivial decisions to reclaim mental bandwidth for the ones that actually matter. None of these replace RAPID for cross-functional accountability, but they're the right tool when speed matters more than governance.

Comparison of four fast decision techniques

How Stress and Bias Distort Decisions Under Pressure

Speed and clarity don't always coexist. Under time pressure, decision-makers lean more heavily on mental shortcuts, and those shortcuts carry known failure modes.

Cognitive load is the first factor. When someone is juggling multiple decisions at once, working memory fills up, and judgment quality drops even if the person feels confident. This is part of why RAPID's separation of roles helps: it reduces how much any single person has to hold in their head at once, since the R focuses solely on the recommendation while the D focuses solely on the final call.

Bias shows up in predictable patterns. Confirmation bias pushes decision-makers toward information that supports a conclusion they've already half reached. Anchoring bias means the first number or option presented, even a bad one, disproportionately shapes the final decision. Under genuine time pressure, both biases get stronger, not weaker, because there's less time to double check the reasoning.

Stress adds a physiological layer. Acute stress narrows attention onto the most obvious threat or option, which can be useful in a genuine emergency but actively harmful in a business decision that requires weighing several nuanced trade-offs at once.

The recognition-primed decision process developed by psychologist Gary Klein offers a partial answer: experienced decision-makers under pressure often skip formal analysis entirely, instead pattern-matching the current situation against past experience to identify a workable option fast. This works well, but only after enough scenario exposure to build a reliable pattern library, which is exactly why rehearsal and simulation matter so much for high-stakes roles.

Rapid Decisions Across Different Industries

Speed requirements look different depending on the stakes and the clock a team is working against.

In emergency medicine, clinicians routinely make life-or-death calls in minutes using structured triage protocols rather than open-ended deliberation. The protocol itself does the work that a RAPID grid would do in a slower-moving business context: it pre-assigns who decides on what, so no one has to negotiate authority mid-crisis.

In software product teams, a common failure pattern is committees re-litigating the same feature decision every sprint because no one was formally named the D. Teams that adopt a lightweight RAPID or DACI structure for prioritization calls tend to see fewer repeated debates, because the decision, once made, has a named owner accountable for defending or revisiting it.

In financial services, decisions around credit risk or trading limits often combine fast individual judgment calls, governed by pre-set thresholds, with slower committee-level RAPID processes for anything that crosses those thresholds. The split matters: routine, in-bounds decisions get resolved instantly by policy, while anything unusual escalates to a defined decision-rights process instead of ad hoc debate.

Nonprofit organizations, per Bridgespan's analysis of RAPID adoption, often adapt the framework for smaller teams and board-level governance, scaling down the number of formal roles while keeping the core discipline of naming a single decider.

Building the Skill, Not Just the Framework

RAPID gives a team structure, but the underlying skill, making sound judgment calls quickly, has to be trained separately.

Scenario-based rehearsal is the most consistently cited method. Walking through past decisions, real or simulated, in a low-stakes setting builds the pattern recognition that Klein's recognition-primed decision research points to as the core skill behind fast expert judgment. Fire commanders and ICU nurses train this way for a reason: real-time high-stakes practice isn't available on demand, so simulated repetition has to substitute for it.

Scenario rehearsal loop for decision training

Time-boxing decisions in low-stakes settings builds the muscle for faster judgment elsewhere. Giving a team fifteen minutes instead of an hour to reach a recommendation, on decisions where the cost of a slightly worse call is low, trains people to trust a faster process before applying it to something that actually matters.

Debriefing after the fact matters as much as the decision itself. Teams that review what information they had, what they ignored, and what they'd do differently build a feedback loop that sharpens judgment over time. Skipping this step is the most common reason teams keep repeating the same decision-making mistakes.

Cross-functional training, not just role-specific training, rounds this out. Bain's adoption research found that training isolated groups while leaving others out preserves the old informal decision culture. Everyone touching the decision, not just the people formally named in the RAPID grid, benefits from understanding how the roles work.

What Leaders Get Wrong About Rolling This Out

Most leaders treat RAPID as a chart to fill out once and forget. It's not. The framework only works if leadership visibly defers to the named D, even when the D isn't the most senior person in the room, and openly acknowledges Agree holders who overstep their veto authority. A practical starter plan: spend the first 30 days mapping and piloting two recurring decisions, the next 60 training the full cross-functional cohort involved with real practice sessions, and the final 90 measuring decision lead time and fixing whichever role broke down first. The framework rewards patience far more than it rewards a polished rollout deck.

— Cody

Sources