RAPID, RACI, DACI, SPADE: Pick One, Then Actually Run It

The decision that four people thought they owned

The pricing change shipped on a Tuesday. On Wednesday, the VP of Sales asked why she hadn't signed off — she owned pricing, she thought. The CFO assumed he had final say; he'd approved the model. The product lead had actually made the call, believing it was hers to make. And the CEO, reading about it in the all-hands doc, was under the impression that decisions like this came to him. Four people, one decision, four sincere owners — and now a rollback debate that is really an ownership debate wearing a pricing costume.

You have watched a version of this. It is the most common governance failure in growing organizations, and it has a well-stocked shelf of remedies: RAPID, RACI, DACI, SPADE — frameworks whose entire content is write down who plays which part before the decision is made. The letters differ; the insight is identical.

Which points at the real problem. Teams spend the energy choosing between the frameworks — comparison posts, workshop debates about whether Consulted differs from Input — and then assign the letters after the decision, as documentation. Assigning roles afterwards is just narration. This tutorial spends one table on the choosing and the rest on the running: the applied workflow, which is identical whichever letters you pick. (For the frameworks' theory and history, our decision frameworks guide covers them alongside the rest of the toolbox — this tutorial deliberately doesn't restate it.)

The four frameworks in one table

Six jobs exist in any consequential decision. The frameworks name them differently:

Pick by your genuine blockers: real veto-holders → RAPID; execution entanglement → RACI; process-runner culture → DACI; a team that skips writing down the why → SPADE. Then stop. Steps 2 through 10 below do not change with your choice — only the letters in step 3 do. That sentence is the tutorial's most useful one: it ends the framework shopping and starts the running, which is the behaviour that actually improves decisions.

Setting up: scope, then roles, then the case

1. 1Name the decision as a root claim. "We will move to usage-based pricing for the Team tier in Q1." Its author is, in practice, the Recommender/Driver — authorship is visible, so the R is on the record from the first second. Checkpoint: root exists; its author is the person building the case.
2. 2Scope who participates with visibility tiers. Set the discussion's visibility — public, tenant-wide, department, or private — to match the intended Input set. A department-scoped decision is consultable by that department by construction; you are not relying on someone remembering to loop Legal in. Checkpoint: visibility matches the Input set, not habit.
3. 3Record the role assignment — before the first argument. As a pro-child of the root: "Decider: A. Recommender: B. Agree: C, D. Input: Eng, Legal. Informed: all-hands." Dated, attributable, and challengeable like anything else on the tree. This ordering is the whole point of decision-rights frameworks: roles assigned after the debate merely describe what happened. Checkpoint: the assignment argument predates every case argument.
4. 4Build the case. Options as sibling nodes, each with its own pros and cons — the same structure as the decision-records tutorial, including the rejected options a reader will ask about later. Checkpoint: every real alternative has a node.

Consultation you can prove happened

"Were you consulted?" is the question every contested decision eventually turns on — and in most organizations the honest answer is a shrug: there was a meeting, there was a thread, memories differ. The workflow here makes consultation a receipt, not a recollection:

1. 1Each Input-holder opens a Q&A chain on the recommendation: their question, the Recommender's answer, a follow-up, an answer — complete. The completed chain is the proof that consultation happened: who asked, what was answered, when. An Input-holder with nothing to ask declines explicitly. Checkpoint: every Input-holder has ≥1 completed chain or an explicit pass.
2. 2An Agree-holder who objects opens a Review chain: their evaluation, the Recommender's response, follow-up, response. Several Agree-holders means several parallel chains, each resolved on its own terms — no unresolved block hiding in a group thread. Checkpoint: no live objection exists outside a chain.
3. 3Two Agree-holders in conflict → Compromise chain. One proposes the middle position to the other, on the record. Resolved or not, the attempt is documented — which converts "Legal and Finance never agreed" from an accusation into a readable exchange. Checkpoint: conflicts either resolved or visibly live.

Deciding against the room, and writing down why

Before the call, everyone rates the options — one labelled rating each. Read this for what it is: evidence of where the room stood, not a vote. There is no quorum, no threshold, no tie-break; the framework's entire premise is that a named human decides.

Then the Decider decides — as an argument, authored by them, under the chosen option, stating the reasoning. And here is the single most valuable sentence the workflow produces: if the call goes against the ratings, the Decider's node is where that gets explained. "The room leaned toward option B; I'm choosing A because the enterprise-renewal risk outweighs the distribution's preference" — one sentence that separates disagree-and-commit leadership from decision-by-decree, and the exact thing a durable decision is made of. A Decider who won't write it isn't running a framework; they're wearing one.

• ✓Checkpoint: distribution captured before the call; decision recorded as the Decider's own argument, with rationale — mandatory when it contradicts the room.

Informing without a separate email

Last letter, cheapest step: widen the decision's visibility once made. The Informed set opens the discussion and reads not just the outcome but the debate — the options, the consultation chains, the Decider's why. "Why did pricing change?" never needs its own email thread, because the answer is the record itself. Done this way, informing is also the beginning of buy-in: people commit to decisions whose reasoning they can inspect.

• ✓Checkpoint: visibility widened to the Informed set; the announcement links the record instead of paraphrasing it.

Honest limitations

• ✗There is no decision-role field. The letters are a recorded convention — dated and attributable, but the product does not assign or check them. An RBAC role is a permission level, never a decision right.
• ✗Ratings are not weighted votes. One value and label per person, no quorum, no threshold, no tie-break. The Decider is the tie-break.
• ✗Visibility scopes reading, not obligation. Department scope means Legal can see it — the completed Q&A chain, not the visibility setting, is the evidence they engaged.
• ✗A chain is four turns, then complete — and complete ≠ agreed. The dissenting Agree-holder who commits anyway is documented as heard, not converted.
• ✗None of this fixes an unwilling Decider. Structure exposes an unmade decision faster — the empty node where the call should be is very visible — but it cannot make the call.

Practical lessons

• ✓Write the role argument in the kickoff meeting, live, before anyone argues the merits. Thirty seconds now versus the Wednesday-after archaeology.
• ✓Keep the Agree list brutally short. Every Agree-holder is a potential block with a chain to resolve; most "approvers" are actually Input. RAPID's discipline is saying so out loud.
• ✓Declined consultation is a record too. An Input-holder who passes explicitly can't later claim exclusion — protect them and yourself by making the pass visible.
• ✓Reuse the assignment. Recurring decision types (pricing, hiring bands, vendor selection) keep the same letters — paste the role argument as a template and update the names.

Wednesday, revisited

Rerun the pricing change through the workflow. The VP of Sales is an Agree-holder — her objection is a completed Review chain, answered twice, and she committed. The CFO is Input — his consultation is a receipt. The product lead is the Decider by a dated argument written before the debate, and her rationale for going against the room's lean is one paragraph everyone can read. The CEO is Informed — the all-hands doc links the tree. Same decision, possibly the same outcome. But on Wednesday there is nothing to relitigate, because the only question that ever fuels those fights — who had the right to decide this? — was answered before anyone argued.