There’s a meeting that happens in almost every organization, in some form or another. Someone brings up a decision that was supposedly made three weeks ago. A few people look confused. Someone else says they thought it was still being discussed. The original decision-maker — if there even was one — goes quiet.
Sound familiar?
This isn’t a communication problem. It isn’t a culture problem. It’s a structural problem, and it has a very specific cause: nobody was ever clearly named as the decision-maker.
The story most small businesses know well
Take a small marketing agency — twelve people, a founder who runs the business, a creative director, an operations manager and a handful of account managers and designers. They’ve been using the same project management software for three years. Everyone hates it. One of the account managers, Lisa, does the research, demos three alternatives and presents her recommendation to the team.
What happens next is what kills momentum.
The founder says it sounds good, but wants to loop in the operations manager. The operations manager has concerns about the migration timeline. The creative director prefers one of the other options. An account manager heard that the recommended tool has issues with client-facing reporting. Two weeks later, the team is still using the software everyone hates, and Lisa has quietly stopped bringing proposals to the group.
The problem wasn’t that people had opinions. Opinions are useful. The problem was that nobody knew whose opinion ended the conversation. Was the founder deciding? Was this a consensus call? Did the operations manager have a veto, or just a voice?
What RAPID does — and why the order matters
RAPID® is a decision-making framework developed by Bain & Co. that gives every person in a decision a specific, named role: someone provides Input, someone Recommends, someone Agrees, someone Decides and someone Performs. Each role is distinct. Only one person Decides — always.
But the acronym is a memory aid, not a sequence. The actual order in which a decision should flow is I → R → A → D → P.
Input comes first. Before Lisa builds her recommendation, she should be talking to the operations manager about migration constraints, the creative director about workflow needs and the account managers about client-facing requirements. Not to get permission — to get information. That’s what Input means: consulted before the proposal is built, not consulted as a way of stalling it.
Then Recommend. Lisa synthesizes everything she’s heard and brings one clear proposal with a preferred option and the reasoning behind it. Not a menu. A recommendation.
Then Agree. If there are people who genuinely have veto authority — say, the operations manager has to sign off because they own the tech stack — they review the proposal and either agree or raise a formal objection with stated grounds. “I’m not comfortable with this” is not an objection. “This will break our client reporting integration, and here’s why,” is.
Then Decide. The founder — or whoever has been named the Decider for this decision — makes the call. Informed by all the above. But their’s alone.
Then Perform. Lisa, or whoever is assigned, executes. Migration planning starts. The decision is made.
In the agency scenario, running this properly would have looked like this: the founder names Lisa as Recommender and themselves as Decider at the start. The operations manager and creative director are Input, not Agree. The proposal comes back in a week. The founder decides. Everyone knows what happened and why.
The corporate version of the same problem
Scale the same dysfunction up to a 200-person company and the stakes get higher, but the pattern is identical.
A regional sales director wants to change the commission structure for a new product line. She builds a business case. She presents it to her VP. The VP likes it but says legal needs to weigh in. Legal weighs in. Finance wants to run numbers. The product team has concerns about how it maps to their road map. HR flags some implications for existing contracts.
Six weeks later, the commission structure hasn’t changed. The product launched without clear sales incentives. Two high performers are already quietly frustrated.
What went wrong? Nobody was clear on whether legal had Input or Agree authority. Finance ran the numbers, but nobody decided whose numbers mattered. The VP never said, “I am deciding this”—they said, “Sounds good, keep moving it forward,” which meant nothing.
The fix isn’t more meetings. It’s one conversation at the start: who needs to give Input before the recommendation is built? Who has genuine Agree authority — and what specifically triggers that authority? Who is the Decider? When does this get decided?
In a corporate context, the Decider often isn’t the most senior person in the room — it’s the person who owns the outcome. The regional sales director might Decide on a commission structure within an approved range, even if her VP sits above her. The VP’s role is to set the range and Agree that the proposal fits within it. That’s not a demotion for the VP — it’s clarity for everyone.
The one rule that unlocks everything
Every team that runs RAPID well eventually arrives at the same insight: the Recommender and the Decider must be two different people, and keeping them separate is the single most important discipline in the whole framework.
When the Recommender and the Decider are the same person, Input becomes performative. Nobody believes their perspective will change anything, so they stop giving it honestly. The person with the most authority gets advice shaped to what people think they want to hear.
When they’re separated, something shifts. The Recommender has real work to do—they have to synthesize diverse perspectives into a defensible proposal. The Input providers have a real incentive to be honest — they know their input will be used. The Decider has real information to work with.
And when the decision is made, everyone knows who made it and why. Which means when it goes well, someone gets the credit. When it needs revisiting — and sometimes it does — there’s a named person to bring it back to. Not a committee. Not a vague sense that “we all agreed.” One person.
That’s what makes the growing pains worth it. Trusting a named Decider feels uncomfortable at first, especially in teams used to consensus. But it’s the only thing that stops decisions from stalling, being reopened or quietly dying in someone’s inbox.
Where to start
You don’t need to RAPID-map every decision your organization makes. Start with the three or four decisions that have stalled most recently — the ones your team keeps circling back to, the ones everyone privately knows should have been resolved months ago.
For each one, ask: who is currently acting as if they’re the Decider? Does everyone else agree? If the answer to the second question is no, you’ve found your problem. Name the Decider. Map the roles. Move the decision forward.
The framework is simple. The discipline is in using it — and in resisting the pull toward consensus when clarity is what’s needed.
Opinions expressed by SmartBrief contributors are their own.
____________________________________
Take advantage of SmartBrief’s FREE email newsletters on leadership and business transformation, among the company’s more than 250 industry-focused newsletters.
