The RAPID Framework Breaks on the A, Not the D
RAPID gives every decision a recommender, a decider and three supporting roles. The letters are easy to learn. The framework only works when it is applied to decision types, and when the agree role is kept for boundaries.
RAPID assigns five roles in a single decision, and the letters are the easy part.
RAPID is a decision rights framework developed at Bain & Company and set out by Paul Rogers and Marcia Blenko in a 2006 Harvard Business Review article, "Who Has the D?". It gives every decision a small cast and states what each member of that cast is allowed to do. It spread because it is easy to remember, which is also why it is so often installed without changing how anything gets decided.
The five roles
Each letter is a role, and the order of the acronym is not the order of the work:
- Recommend: the person who gathers the facts, consults the right people and puts a proposal forward.
- Agree: a person whose sign-off the recommendation needs, and who can send it back. In practice, a veto.
- Perform: the people who carry out the decision once it is made, and whose capacity it spends.
- Input: the people consulted for facts and judgment. Their view is heard, and it does not bind.
- Decide: the single person who makes the call and commits the organisation to it.
In sequence the decision runs from recommendation, through input and agreement, to the decision and then the work. The value of the framework sits in one constraint: there is exactly one D, and every other role is defined by its distance from it.
Not RACI with different letters
The comparison that comes up most is RACI, and the difference is not cosmetic. RACI assigns roles in a task: who does the work, who answers for it, who is consulted and who is told. RAPID assigns roles in a choice, before anyone knows what the choice will be. A team can run a project with an immaculate RACI and still have no idea who decides when two workstreams want the same engineers. The two fit together, and neither can stand in for the other.
The framework is applied to a decision type, never to a function.
The usual way to install RAPID is a workshop that produces a grid: functions down the side, letters across the top, a letter in every cell. Product is R and D, risk is A, finance is I. The grid looks complete and settles nothing, because a function does not hold one role across every decision it touches. Risk can hold agreement on a change to authentication thresholds and be no more than input on the wording of the checkout page.
One line per decision type
The unit that works is the recurring decision type, stated narrowly enough to check against a real case. Pricing cannot be given a RAPID. Exceptions to list price for a single enterprise customer can. The list of those types is the registry described in the note on inherited decision rights, and RAPID is the notation that fills in each entry. Without the list, the letters are spread across an org chart that was never the thing being decided.
A worked entry, from the kind of checkout work we see, reads like this. The decision type is a change to the step-up authentication rule for returning customers. The checkout product manager recommends. Compliance agrees, because the rule sits against a regulatory requirement for strong customer authentication. Risk, customer operations and engineering give input. The head of payments product decides. Engineering and fraud operations perform. Each role is a person, not a department, and the entry fits on one line.
A single D, named as a person
The test of an entry is whether the D can be read aloud as one name. Two names, a committee or the leadership team means the entry has not been written, only postponed. Where a decision genuinely needs the whole team, the D is the person who chairs the discussion and closes the call, which is the arrangement set out in how to close a decision in a leadership meeting.
The agree role is where most RAPID charts fail, because an A is a veto.
Ask each function which letter it wants and most will ask for the A. Agreement is the only role besides the D that can stop a decision, and it carries none of the accountability for the outcome. It is influence without exposure, and in a workshop it is handed out generously, because withholding it feels like telling a senior colleague that their concerns do not count.
How agree roles multiply
A line with four agree roles on one decision has four vetoes and one decider, and the decider is the weakest person in the process. The recommendation travels from desk to desk collecting conditions. Each A negotiates separately, the proposal reaches the D already shaped by four rounds of concession, and the D ratifies what is left. A decision with several agree roles is not made by the D. It is made by whichever A objected last.
An agree role is a veto, and a veto belongs on a boundary that cannot be priced.
Keeping the A for boundaries
The discipline is to grant agreement only where the objection is a boundary rather than a preference: a regulatory requirement, a contractual obligation, a legal exposure no business case can buy back. That is the line drawn in the note on risk and compliance decision rights, where compliance answers what is permitted and risk answers what something costs. Compliance can hold an A. Risk, in most cases, is a heavy I, pricing the proposal against a tolerance it published in advance. Moving a function from A to I does not silence it. It changes what its objection does, which is to inform the decision instead of ending it.
Input and perform carry the cost of a decision, and a chart that ignores them stays theoretical.
The quieter letters decide whether the framework survives an ordinary week. Input is where most of the organisation's knowledge enters a decision. Perform is where the decision meets the people who have to live with it.
Input with a closing date
Input without a deadline becomes a second veto. A function that has not finished giving its view can hold a decision open as effectively as one that refuses, and it does so without ever being seen to object. Each entry needs a date by which input closes, after which the recommender takes the proposal forward with what has arrived. Consulted means heard by a date, not heard until satisfied.
The P before the D
Perform is the role most charts leave empty or fill with the word delivery. It belongs in the entry because the people who carry out a decision know what it will cost before anyone else does. A sales enablement programme recommended by marketing and decided by the commercial director, with the sales managers who must run it listed only as P, is a familiar way to produce a playbook nobody uses. The answer is not to give the P a vote. It is to take the P's input before the recommendation is final, so the decision is made with the cost of carrying it out on the table.
Where this thinking becomes work.
The first step is not a workshop. It is a list of the ten to fifteen decision types that recur in the leadership team's calendar, each checked against the last three times it was made: who actually recommended, who could actually have stopped it, and who actually decided. That record usually shows more agree roles than anyone intended and at least one decision type with no D at all.
From there the work is writing one RAPID line per decision type, with the A held to boundaries and input given a closing date, and running it for a quarter before revising. Our consulting practice builds that registry with leadership teams inside the decision architecture pillar, and our training programmes cover the habits that keep it honest in the room: naming the D aloud, closing input on time and refusing the extra A. RAPID earns its place when every recurring decision has one name against the D and no more agree roles than its boundaries require.
Continue