How a team makes decisions is often more important than which decisions it makes. Teams that lack a clear decision-making process either default to the loudest voice (creating resentment) or seek consensus on everything (creating paralysis). Effective teams match their decision-making approach to the decision’s importance, reversibility, and time constraints.

Team Decision-Making Frameworks: From Consensus to Command

The Decision Spectrum

Decisions exist on a spectrum from unilateral to consensus:

Approach	Speed	Buy-In	Best For
Command	Fastest	Lowest	Emergencies, operational decisions
Consult	Fast	Medium	Technical decisions with clear expertise
Vote	Medium	Medium	Preference-based choices with no clear best option
Consent	Medium-slow	High	Process and working agreement changes
Consensus	Slowest	Highest	Strategic decisions affecting the whole team

Command (Decide and Inform)

One person makes the decision and informs the team. Appropriate for time-sensitive decisions, operational choices, and situations where one person has significantly more expertise. The team lead decides to roll back a production deployment. The Product Owner decides sprint priority order.

Consult (Gather Input, Then Decide)

The decision-maker gathers input from affected parties but retains the final decision. Appropriate for technical decisions where expertise matters: the lead architect consults the team on the database technology choice but makes the final call based on their experience and the team’s input.

Vote (Majority Decides)

Each team member has an equal vote. Appropriate for preference-based decisions with no objectively correct answer: which retrospective format to use, what time to hold standup, or which team name to adopt.

The proposal is adopted unless someone raises a specific, substantiated objection. This is faster than consensus because it does not require active agreement from everyone — only the absence of objections. Used in Sociocracy and Holacracy for governance decisions.

Consensus (Everyone Agrees)

All team members must actively agree. Appropriate for decisions that significantly affect everyone and require full commitment: team working agreements, methodology changes, or major process overhauls.

The DACI Framework

DACI (Driver, Approver, Contributors, Informed) is the most popular decision-making framework in tech companies, used at Atlassian, Spotify, and others.

Driver: The person responsible for moving the decision through the process. They gather information, facilitate discussion, and ensure a decision is made by the deadline.
Approver: The person (or small group) who makes the final decision. Usually one person; sometimes two to three for major decisions.
Contributors: People whose input is needed. They provide data, analysis, and perspectives but do not make the final call.
Informed: People who need to know the outcome but are not involved in making the decision.

DACI is essentially a RACI matrix applied specifically to decisions. It works because it clarifies who is responsible for what before the decision-making process begins.

Decision Documentation

Every significant decision should be documented:

What was decided — the specific choice made
Why — the rationale and trade-offs considered
Who decided — the approver and key contributors
When — the date of the decision
Alternatives considered — what other options were evaluated
Review date — when to revisit the decision if needed

Architecture Decision Records (ADRs) formalize this for technical decisions. For non-technical decisions, a simple entry in the team’s documentation wiki suffices.

Documented decisions prevent re-litigation. When someone asks “why did we choose PostgreSQL?” six months later, the decision record provides the answer without requiring a new discussion.

Amazon’s Disagree and Commit

Jeff Bezos introduced the concept of “disagree and commit” — once a decision is made, everyone commits to executing it wholeheartedly, even those who disagreed. This prevents decisions from being undermined by people who “commit” but then work against the decision through passive resistance.

The prerequisite is that disagreement must be genuinely heard during the decision-making process. If people feel their objections were ignored, asking them to commit is unreasonable.

Decision-Making Anti-Patterns

Analysis paralysis. Gathering more data when the decision is fundamentally about values or preferences. At some point, additional data provides diminishing returns, and the team needs to decide.

Consensus on everything. Seeking consensus for decisions that do not require it wastes time and energy. Use the decision spectrum to match the approach to the decision.

Undecided decisions. Discussions that end without a clear decision. The facilitator must call the question: “What is our decision? Who is accountable for executing it?”

Reversing decisions without process. If a decision was made through a deliberate process, reversing it should require a similarly deliberate process. Casual reversal undermines the team’s confidence in decisions.

Excluding affected parties. Decisions made without input from the people who will implement or be affected by them generate resistance and often miss important constraints.

Matching Framework to Context

For sprint-level decisions (what to work on, how to implement), use Consult or Command. For process decisions (ceremony format, working agreements), use Consent or Consensus. For strategic decisions (methodology selection, tool migration), use DACI with appropriate stakeholder involvement.

The most important thing is not which framework you choose but that the team knows which framework applies to which type of decision before the decision needs to be made.