Decision-Making Frameworks for Small Teams (and Where to Record the Result)

A decision-making framework is an agreement, made before the argument starts, about who decides, who gets a say and how a disagreement ends. For a small team the useful ones are few: RAPID and DACI name one decider and everyone else’s role; consent lets a group move once nobody has a reasoned objection; the consultative method has one person decide after asking; and “disagree and commit” ends a debate that has run long enough. Which one fits depends less on the framework than on the decision, and the first question is whether it can be undone. Whatever you use, the result is only worth something if it is written down: what was decided, why, who decided and when.

First, sort the decision: one-way or two-way door

Jeff Bezos put the distinction plainly in Amazon’s 2015 letter to shareholders↗ (opens in a new tab). Some decisions are “consequential and irreversible or nearly irreversible – one-way doors,” and should be made “methodically, carefully, slowly, with great deliberation and consultation.” Most are “changeable, reversible – they’re two-way doors,” and “can and should be made quickly by high judgment individuals or small groups.” The trap he names is using the heavy process on everything.

• Two-way doors on a small team: which bug to fix first, a page layout, the wording of a release note, trying a new standup time for two weeks. One person decides, today, and says so.
• One-way doors: signing a multi-year contract, deleting customer data, changing what a paid plan includes, choosing the database a product will live on for years. Slow down, ask more people and write the reasons down in full.
• In between: anything expensive to reverse but not impossible, such as a public price or an API that customers already call. Treat it as a one-way door unless you can name the way back.

Sorting takes ten seconds and saves most of the process. A team that asks “can we undo this?” first usually finds that four decisions in five need no framework at all, just a named person and a line in the record.

Five frameworks, one paragraph each

RAPID

Bain & Company’s RAPID tool↗ (opens in a new tab) names five roles: Recommend, Agree, Perform, Input and Decide. One recommender gathers input and brings a proposal, input comes from the people with expertise or who will be affected, one decider makes the call, and the performers carry it out. Agree roles are for mandatory requirements such as legal sign-off, and Bain says to assign them sparingly. It also says not every decision needs explicit RAPID roles and suggests starting with high-value or frequent ones. On a small team, the Agree role is the one to watch: every person who can block is a person who can stall.

DACI

The DACI play in Atlassian’s Team Playbook↗ (opens in a new tab) has four roles. The Driver gathers people and information and gets a decision made by an agreed date. The Approver is “the one person (yes: one!) who makes the decision.” Contributors have “a voice, but not a vote,” and the Informed are told afterward. DACI suits a small team because it separates the person doing the legwork from the person deciding, which is often the missing piece when a founder is too busy to research every choice.

Consent

Consent asks a different question from consensus. Nobody has to love a proposal. The consent decision-making pattern in Sociocracy 3.0↗ (opens in a new tab) accepts a proposal when it is “good enough for now and safe enough to try until the next review,” and only an objection stops it: an argument that reveals a risk worth avoiding or a worthwhile way to improve, not just a feeling. The steps run from agreeing on the purpose, through presenting and clarifying the proposal and a round of brief responses, to checking for objections, testing whether each one qualifies and resolving it. It works well for policies a whole team lives with, such as on-call rules, and badly for urgent calls.

Consultative

One person owns the decision, asks the people who know most or will be most affected, then decides and explains why. It is the default on most small teams whether or not anyone calls it that. It fails in two ways: when the decider asks for input they have no intention of using, and when nobody is sure who the decider is. Name the decider out loud before the consulting starts, and say when the decision will be made.

Disagree and commit

This one is a closing move rather than a full framework. In the 2016 letter to shareholders↗ (opens in a new tab), Bezos suggests saying “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” and adds that it applies to the boss too. The same letter suggests most decisions “should probably be made with somewhere around 70% of the information you wish you had.” The commitment is the point: once the call is made, the people who argued against it help it succeed rather than waiting to be proved right.

If the question is who does the work and who answers for it, rather than who makes a single call, that is a RACI matrix, which covers tasks as well as decisions.

Choosing a framework by team size

• Two to five people: consultative for almost everything, with “disagree and commit” to end debates. Anything heavier costs more time than the decisions are worth.
• Six to fifteen people: DACI for decisions that cross roles, such as a pricing change that touches product, support and sales. Keep consultative for the rest.
• Decisions that set policy everyone lives with: consent. It is slower, but people follow rules they could have objected to.
• Several teams, or a client with a veto: RAPID, because it makes the Agree role explicit. When the client must sign off, write that down before the work starts, not after.
• Any size, one-way door: whichever framework you use, add more consultation and a written why. Any size, two-way door: one person, today.

Pick one default and one escalation, and write both down. A team that argues about which framework to use for each decision has added a meeting, not removed one.

Writing the result down: who, why and when

Every framework above ends in the same place: a decision someone will later need to find. Three months on, the question is never “what did we discuss?” but “did we decide this, who decided it, and why?” A record that answers those three things stops the same debate from being reopened by whoever missed the meeting. Keep it short enough that people actually write it.

Decision: [one line, e.g. "Move the launch to October 14"]
Status: [open / decided / superseded]
Question: [what had to be decided, and by when]
Context: [what made it come up]
Options considered: [each option, and why it was not chosen]
Decided: [what was decided, in one or two sentences]
Why: [the reason that would convince someone who was not there]
Decided by: [the named person or people who decided]
Decided on: [Month day, year]
Framework: [consultative / DACI / consent / RAPID]
Door: [one-way / two-way]
Review by: [Month day, year, or "only if X changes"]

Two habits keep the record honest. Never edit a decision to reverse it; write a new one that replaces it, so the history shows what changed and why. And record open questions too, with who will decide them: a list of what is waiting on someone is as useful as a list of what is settled. For decisions made in meetings, the meeting minutes template has a decisions section in the same shape.

Standing rules on the fenbs Decisions and rules page

In fenbs, decisions live on the Decisions and rules page rather than inside task notes. Each gets its own ref, such as DEC-004, never reused, with the question, context, what was decided, why, the options considered, who decided, the day they decided, and an optional review-by date. A task links the decisions it depends on, and a card shows that a decision is waiting while one it depends on is still open. To change a decision, you record a new one that supersedes it; the old one is kept and marked Superseded.

A decision that holds from now on is marked as a rule, such as “never ship pricing changes without legal approval.” Rules matter most when AI assistants work on the board: every connected assistant is given the rules in full, first, before its context notes and before it touches a task. The decider is always a person, a board member or someone outside the board named with their role. An assistant can write a decision down for the person it works for, or add an open question and ask, but it never decides. When a decision needs formal agreement, you can ask named board members to sign it off.

Be clear about what fenbs does not do. It has no voting, and the record has no Driver, Approver or Contributor fields, so if you use DACI or RAPID, name the roles in the context or the why. It records the outcome of your framework; it does not run the framework for you. How a small team decides what AI assistants may do on their own is its own topic, covered in AI agent governance for small teams.