The Framework Wasn't the Problem
A leadership team you know has the same conversation every quarter. A decision needs to be made. They debate it. Someone proposes RAPID. Someone else says they tried DACI last year. A third person suggests they "just need to be more decisive." A week later, the decision is still open.
It is tempting to read this as a framework problem. It isn't. The same team, given any of the popular decision-making frameworks for teams, will produce the same outcome. RAPID, DACI, RACI, consensus, consent — they all look reasonable on a slide. They all assume capabilities most teams have not yet built. When the capability is missing, the framework collapses on first contact with a real, contested decision.
This post is about what those capabilities are, why every framework rises and falls on them, and what to do about it when your team is the team in the room.
What the Popular Frameworks Actually Do
Five frameworks show up in most workplace conversations about team decisions. Each one is a useful tool when the team can run it.
RAPID (Bain) — Recommend, Agree, Perform, Input, Decide. RAPID is built to make ownership visible. One person recommends. One person decides. Others give input or have to agree. It is at its best when a decision has clear functional owners and a small set of stakeholders.
DACI — Driver, Approver, Contributors, Informed. DACI is similar in spirit to RAPID, with the Driver moving the decision forward and the Approver having final say. It is common in product and operations teams.
RACI — Responsible, Accountable, Consulted, Informed. RACI is project-management heritage and works best for ongoing operational decisions where the same roles recur.
Consensus — every member must affirm the decision before it moves. Used well, consensus produces deep commitment. Used poorly, it produces watered-down decisions and slow timelines.
Consent (sociocracy-derived) — the decision proceeds if there is no objection on the grounds that it is "good enough for now, safe enough to try." Consent is faster than consensus because the bar is no objection, not full agreement.
Each of these frameworks has helped real teams. None of them solves the underlying issue if the team's decision-making behavior is the actual problem.
The Four Behaviors Every Framework Assumes
Look closely at any framework and you will find the same four behaviors underneath. Without them, the framework is decoration.
Behavior one: name the decision rule before the discussion starts. Most slow decisions are slow because the room is arguing the decision and the decision rule at the same time. "Who decides this?" gets relitigated halfway through, the conversation collapses, and the team has to restart. A team that names — at minute one — "Sarah recommends, the three of us give input, Sarah decides by end of day Friday" gets through the same decision in 30 minutes that used to take three meetings.
Behavior two: disagree clearly without it becoming personal. Storming, in Tuckman model terms, is where most decision-making frameworks die. The team has the framework. It also has two people who quietly resent each other. Dissent gets read as politics. Politics gets avoided. The decision drifts. Frameworks assume disagreement can happen on the substance without infecting the relationship. That assumption is built, not given.
Behavior three: capture dissent without it stopping the decision. Once the decision rule is named and the disagreement is on the table, the team has to be able to record the dissent in writing — and then move. Teams that cannot capture dissent end up re-deciding the same call three times because the disagreement keeps surfacing in side conversations. Teams that capture dissent cleanly say: "we heard X, we considered X, we went with Y for these reasons" — and the decision sticks. Stop killing ideas in your next meeting walks through the upstream skill that makes this possible.
Behavior four: commit once the decision is made. A framework only moves a decision through if, after the decision is made, the people who pushed back commit to making it work. The pattern that breaks teams is the one where disagreement continues outside the room — the same dissent gets relitigated in hallway conversations, in side emails, in the next meeting. The decision was nominally made. Operationally, it never was.
Three behaviors out of four can be present and the team will still stall. All four have to be installed for any decision-making framework to do its work.
Why Most Teams Don't Have All Four
Two patterns suppress the four behaviors in most workplace teams.
Surface harmony. The team has learned that disagreement is uncomfortable, so the room produces nods and agreement while the actual disagreement lives in private. The framework runs cleanly on the surface. The decision dies in the field, because the people executing it never bought in.
Performance dominance. The most senior person, or the most confident voice, sets the direction early. Others give input that doesn't reshape the call. The framework "worked" — Recommend was given, the Decider decided — but the input phase was theater. Decisions made this way carry a quiet cost: the team stops bringing real input over time, because they have learned input doesn't change the outcome.
Both patterns are invisible during calm conversations. Both become visible the moment the team is under pressure with a real decision and a clock. That visibility is what installs the behaviors — not a worksheet, not a slide.
For the version of this in operational meetings, see The Meeting Where Nothing Gets Decided — same dynamic, different surface.
A Working Decision Rule You Can Use This Week
Whatever framework your team is currently using — RAPID, DACI, RACI, or none — install this small ritual at the start of every consequential decision.
Step one — name the rule. Before the discussion, take 60 seconds to say, out loud: "Here's how we're going to decide this. [Name] recommends. The four of us give input. [Name] decides by [date]. We'll revisit in 90 days." If the room cannot agree on that one paragraph, the team is not ready to decide. The first 60 seconds save the next 60 minutes.
Step two — separate input from decision. Give every person in the room — including the Decider — a five-minute silent input round before discussion. Each person writes their position, their reasoning, and the single thing they're most uncertain about. Read them aloud. Then discuss. Silent input prevents performance dominance from collapsing the input phase.
Step three — record the dissent. Before the meeting closes, write down: "We heard [X]. We considered [X]. We went with [Y] because [reason]." Send it to everyone within 24 hours. The dissent on the record is the dissent that doesn't keep coming back.
Step four — pre-commit to the commit. Each person in the room states, before leaving, what they will say about this decision to the people they manage. The team that names the commit out loud, in front of each other, lives by it. The team that doesn't, relitigates it on Monday.
You don't need a new framework to run this. You need 90 seconds at the front of the meeting and 5 minutes at the back. That's it.
What Changes When Teams Run a Decision Under Real Pressure
You can describe the four behaviors on a slide. You can hand them out as a job aid. The team will not internalize them until they experience what their own default looks like under load.
That is the design behind Save the Titanic. A team becomes the Senior Officers of the RMS Titanic in the minutes after the iceberg strikes. Limited time. Limited resources. Real consequences inside the fiction. Within ten minutes, every decision-making default is visible — who dominates, who defers, who freezes, who shifts into trying to please the senior person in the room. The framework the team brought into the room doesn't help. The behaviors do.
The teams that perform best are not the ones with the most decision-making theory. They are the ones who, under pressure, can do the four behaviors. The teams that struggle hardest are the ones whose decision rule was always implicit — and now, with a clock running, has to become explicit and the team has never practiced making it explicit before.
The debrief is where the work installs. Each team gets to see, on tape and in the room, exactly which behavior they defaulted to and what it cost them. That seeing — not a worksheet — is what changes how the team makes its next real decision back at the office.
How to Pick the Right Framework
If you are going to use a framework, pick the one that matches the kind of decision and the size of the room.
For high-stakes, single-decision moments with clear functional ownership, RAPID is the cleanest. For product or operations decisions with a known Driver, DACI works. For ongoing operational decisions where the same people show up week after week, RACI holds up. For decisions where commitment matters more than speed, consensus is worth the time. For decisions where speed matters more than perfection, consent ("good enough for now, safe enough to try") wins.
The framework is the second-order choice. The first-order choice is whether your team can do the four behaviors under load. If it can, almost any framework will work. If it can't, no framework will.
For the upstream conversation about how a team makes any decision in the first place, the meeting format that produces decisions in 30 minutes walks through the structural side of the same problem.
Where to Start
Pull your last three meaningful team decisions onto a single page. For each one, answer four questions.
Was the decision rule named in the first 60 seconds, or did the meeting relitigate it? Did every person in the room give substantive input, or did the senior voice set direction early? Was the dissent captured in writing, or did it leak into hallway conversations afterward? Was the commit named out loud, or did the team leave the room with quiet reservations?
The pattern across the three decisions is your team's default. Frameworks won't change the default. Naming it, then practicing the four behaviors under conditions that surface them, will.
For leadership teams that want to install the four behaviors directly — to see, in real time and under pressure, what their decision-making default actually looks like and what to do about it — watch how the Save the Titanic experience works. The decision-making framework that comes out of it is the one your team will actually run.
Read next: Team Debrief Template