decision-making: make a decision and put it on record

---
name: decision-making
description: Helps a team make a decision well, on evidence, and put it on record. Use when someone asks "should we do X or Y", "help us decide", "who decides this", "we keep arguing about this", "write up the decision", "is this reversible", or faces a choice that is costly to undo (a price, a hire, a platform, a vendor, a market, a pivot). Checks what is already decided, sizes the decision (can it be undone, what being wrong costs, who it affects) and scales the process, from a short record for a two-way door to criteria set first, at least three options, evidence, independent views and a pre-mortem for a one-way door. Names one decider, writes the decision record (what, why, options rejected, who decided, when, how sure, what would make us revisit) and gets it agreed. Keeps facts apart from opinions, starts from how similar cases went, asks what would change the team's mind, and judges past decisions by what was known then.
license: MIT
metadata:
  source: https://alcoven.co/skills/decision-making
  version: "2"
---

Decision making: size it, decide it, put it on record

A decision is good when it was made well with what could be known at the time. A good outcome can follow a bad decision, and a bad outcome a good one; judging decisions by how they turned out is what Annie Duke calls "resulting". Most decisions can be undone and should be quick; a few are hard to undo and deserve care (Jeff Bezos's two-way and one-way doors). The person asking is usually stuck between options, short of time, or tired of a choice the team keeps arguing about, and fears both a wrong call they can't take back and a slow one that costs the moment. So size the decision first, spend effort in proportion, name one decider, and write it down so nobody argues it again without new evidence.

What you need

• The question, in the person's words, and the date it must be decided by.
• What is already on record: decisions, agreed documents, the brief and strategy, earlier attempts at the same thing.
• The people: who decides, who knows the most, who must agree, who it affects.
• The evidence: numbers, research, customers' words, costs, each with its date.

If you can only see the conversation, ask for the question, the deadline and who decides, and list what you could not check.

1. Check the record first

• Look for a decision on record on this subject and for what people agreed to. Read why it was decided and on what evidence.
• If it is decided, say so and cite it: who, when, why. Reopening it is the decider's call, and only on new evidence or a changed situation, named in a sentence.

2. Frame the question

• One sentence, as a choice: "Which payment provider do we launch with, by 15 November?"
• The deadline, and what waiting costs.
• The roles (Andy Grove's pre-decision questions; DACI or RAPID if the team uses one): one decider; who gives input; who must agree (only those who must, such as whoever holds the budget or owns what it changes); who needs to know.
• If nobody is named as the decider, ask the person who it is. Never assume it is the most senior person or the loudest.

3. Size it

Most decisions are two-way doors. Bezos warns that organisations slow down when they treat them like one-way doors, and suggests deciding most of them with about 70% of the information you wish you had. In between, use steps 4.1, 4.2 and 4.6. Before the full method, ask whether a one-way door can be turned into a two-way door: a pilot, a shorter contract, a first step that can be undone.

4. The full method, for a one-way door

1. Set the criteria before looking at options. What matters, in order; the must-haves; for each, the evidence that would show it is met.
2. Widen the options to at least three. Include waiting and doing nothing. Ask: if none of these were possible, what would we do? Look for "both, in order" and for a small test first (Chip and Dan Heath, Decisive).
3. Gather the evidence. Facts with a source and a date; opinions marked as someone's view; assumptions listed. Start from how comparable cases went, the outside view, then adjust for what is different here.
4. Collect views independently first. Each contributor writes their choice, the reason and how sure they are, before any discussion. The decider and the most senior person speak last. Discussion goes to where people disagree (Kahneman, Sibony and Sunstein, Noise).
5. Run a pre-mortem. Imagine it is a year later and the decision failed. Each person writes the reasons alone; share them in turn; change the plan, or set a tripwire that will tell you early (Gary Klein).
6. Decide. The decider decides by the deadline. People who disagree say so, and their view goes in the record if they want it there; then everyone commits to the decision (Bezos: disagree and commit). A real disagreement about direction goes to whoever sits above both sides, early.

5. Write the record

Every record has: the decision in one sentence ("We will..."); why, and why now; the options rejected and why; who decided, who gave input, who agreed, and the date; how sure the decider is; what would make us revisit (a condition and a date) and who checks. A one-way door adds the criteria, the evidence with sources, the pre-mortem's main risks, any dissent, and the consequences: what changes and what we give up. A two-way door fits in one paragraph. Templates in references/record.md. When a decision changes, keep the old record, mark it superseded and link the new one (Michael Nygard's architecture decision records).

6. Put it on record and get it agreed

Show the person the text before writing it. Then ask the people who must agree to agree to that version, and give it to those who need to know. Until both happen, it is a proposal.

7. Look at it again

At the revisit date or when the condition is met: what was known then, whether the process was sound, what happened, and how much was luck. Judge the decision apart from the outcome. If the condition fired, change course and write a new record that supersedes the old one.

Deciding with evidence

• Set criteria and pass lines before seeing options and data.
• Every fact carries a source and a date; every opinion a name.
• Start from the base rate of similar cases, then adjust (Lovallo and Kahneman's outside view).
• Say how sure you are as a number, and ask others to: "likely" means different things to different people (Duke).
• Ask "what would change our mind?" and write the answer as the revisit condition.
• With thin data, decide a two-way door anyway. For a one-way door, buy information cheaply first (a test, a pilot, a call) or make it reversible. For choosing measures and reading numbers, use the metrics skill; for a test, lean-experiments, if the project has them.
• A missing number is said to be missing, never estimated from memory.

Common mistakes

Name one when you see it, once, with the evidence and the fix. Why each hurts and its source are in references/methods.md.

1. No clear decider. Everyone waits for someone. Instead: one named person.
2. Waiting for everyone to agree. The decision waits for the last holdout. Instead: input from all, a decider, disagree and commit.
3. The loudest voice or the highest-paid person's opinion decides. Others stop offering what they know. Instead: independent views first, the senior voice last.
4. Reopening a settled decision without new evidence. The team re-argues it each month. Instead: point to the record; reopen on named new evidence.
5. Nobody wrote it down. Newcomers accept it blindly or reverse it blindly. Instead: a short record, where the team looks.
6. Judging the decision by its outcome. Teams learn from luck. Instead: review what was known and how it was decided.
7. A two-way door treated as a one-way door. Slow, cautious, no experiments. Instead: decide fast and set a date to look again.
8. A one-way door treated as a two-way door. A hasty call that can't be undone. Instead: the full method, or make it reversible first.
9. Only two options. "Whether or not" hides better choices. Instead: at least three, including waiting.
10. Choosing first, then finding reasons. The criteria are bent to fit the favourite. Instead: criteria before options.
11. Anchoring the room. The boss, or an AI, gives a view first and everyone moves toward it. Instead: collect views before showing any recommendation, yours included.
12. Waiting for complete data. The moment passes. Instead: about 70% for a two-way door; cheap tests for a one-way door.

Speaking up

• Once, with the evidence and the cheapest step. "This was decided on 3 March (decisions/2026-03-03-pricing.md) on churn data from February. Is there new evidence? If not, want me to list what would justify reopening it?"
• Credit what is already good before the gap.
• Match their pace. On a deadline, one line. Never repeat a point they have heard and decided on.
• Then help with the decision they choose, and note the risk once in the record.

What you never do

• Make the decision. Recommend when asked; the decider decides.
• Present your recommendation as the team's view, or put words in anyone's mouth.
• Reopen or edit a decision on record on your own.
• Invent probabilities, base rates, costs or evidence.
• Name someone's dissent in a record without their agreement.
• Ask people to agree to anything without the person's yes.

In Alcoven

Pass the project's slug and cite by § address.

1. related with the question in a sentence or two, and agreed with about: the subject: what is already decided or agreed. A choice settled on a call may live only in a document, so search too.
2. why on the passage that settled it: who decided, when, and what they read. If the new step goes against an agreed line, stop that step, tell the person, and add_note on that section to whoever put it there.
3. For a one-way door, add_note with to each contributor on the options section, asking for their choice, reason and how sure they are. Everyone who sees the document sees its notes, so ask each person to write theirs before reading the others', and show no recommendation until they have.
4. Show the person the record, check the folder with list (the project's decisions folder, else decisions/YYYY-MM-DD-<slug>.md), then add_document with asked in their words and read.
5. hand_out with ask: "agree" to those who must agree, and the person's own line; ask: "read" for those who need to know. Then task for the decider, due on the revisit date, standing on the record.

Elsewhere

Look for a decisions folder (decisions/, docs/adr/, wiki/decisions/) and follow its numbering and shape. Find earlier decisions with grep and git log -S "<term>". Get agreement in writing: a reviewed pull request, or replies to the record.

Files

• references/methods.md: the methods in more depth, the mistakes in depth, and the sources.
• references/record.md: record templates, a pre-mortem script, an options table, and a worked example.

Decision methods, in more depth

The ideas behind each step, in our own words, with where each comes from. Sources at the end.

One-way and two-way doors

In his 2015 letter to shareholders, Jeff Bezos split decisions into two types. Type 1 decisions are consequential and impossible or nearly impossible to reverse (one-way doors); they should be made "methodically, carefully, slowly, with great deliberation and consultation". Type 2 decisions can be changed (two-way doors) and should be made quickly by individuals or small groups with good judgement. His warning: as organisations grow, they tend to use the heavy Type 1 process for most decisions, which brings slowness, risk aversion and too few experiments.

His 2016 letter adds three points:

• About 70% of the information you wish you had is usually enough for most decisions; waiting for 90% is usually too slow. Being good at correcting course makes being wrong cheaper.
• Disagree and commit. When there is conviction but no consensus, people can say they disagree and still commit fully. It works upward too: his example is approving a show he doubted, because the team believed in it.
• Escalate real disagreement early. Otherwise it is settled by whoever has more stamina.

The reverse error matters for small teams: treating a signed contract, a price for existing customers or a public promise as an experiment.

Decision quality and outcome quality

Annie Duke (Thinking in Bets, 2018) calls judging a decision by its outcome resulting. Outcomes mix the quality of the decision with luck and with what nobody could know. To review a decision, ask what was known, what could have been learned at a reasonable cost, and how the choice was made, before looking at how it turned out.

Her later tools (How to Decide, 2020; Quit, 2022):

• Map the outcomes. For each option, list the outcomes that could follow, how much you would like each, and roughly how likely each is. A rough tree beats none.
• Say probabilities as numbers. Words like "likely" mean very different things to different people; a number exposes disagreement that words hide.
• Quarantine opinions. Ask others for their view before sharing yours, so yours does not colour theirs.
• Freerolls and close calls. When the downside is small, decide fast. When two options are close in value, the choice feels hard and matters little: pick one.
• Kill criteria. Set in advance a state and a date that will make you stop or change course ("if fewer than 20 bakeries have signed up by 31 March, we pause the delivery feature"). This is the revisit condition in the record.

Criteria and options

Chip and Dan Heath's Decisive (2013) names four traps and a remedy for each, WRAP:

They cite Paul Nutt's studies of organisational decisions, which found that only 29% considered more than one option. Ways to widen: the vanishing options test (if none of the current options were possible, what would you do?); running two options at once; a small test first ("ooching"). For distance, Suzy Welch's 10/10/10: how will we feel about this in ten minutes, ten months, ten years? To prepare to be wrong, set tripwires: a date or a signal that forces a fresh look.

Decision hygiene

Daniel Kahneman, Olivier Sibony and Cass Sunstein (Noise, 2021) define noise as unwanted variability in judgements that should be identical. Their decision hygiene works without knowing which way the error runs:

• Independent judgements first, then combine them. Each person forms and writes a view before hearing others.
• Sequence information. Give people the facts they need when they need them, so an early impression does not colour the rest.
• Break the decision into a few separate assessments (for a vendor: cost, reliability, fit, exit), judge each on its own facts, and only then make the overall call. With Dan Lovallo, they call this the mediating assessments protocol.
• Use the outside view as a shared starting point.

They note that hygiene has costs: scale it to the stakes.

Group dynamics and roles

Andy Grove (High Output Management) gives a model: answer six questions first (what is the decision, by when, who decides, who must be consulted, who approves or vetoes, who must be told), then free discussion, a clear decision, and full support afterwards. He warns of the peer-group syndrome: peers hold back until they sense where the group is heading. His fix is a more senior person in the room who steps in when that happens, and reassurance that being overruled costs nothing.

Google's Project Aristotle found that consensus-driven decision making was not significantly connected with team effectiveness. Two common role schemes:

Both insist on a single decider.

The pre-mortem

Gary Klein (Harvard Business Review, September 2007): before committing, the team imagines the plan has already failed and writes down why. It makes doubts safe to say, because everyone is asked for reasons it failed. It rests on "prospective hindsight": research by Deborah Mitchell, Jay Russo and Nancy Pennington (1989) found that imagining an event has already happened helps people explain it more fully. The script is in record.md.

The outside view

Dan Lovallo and Daniel Kahneman ("Delusions of Success", Harvard Business Review, 2003) describe how planners focus on the case at hand, the inside view, and come out too hopeful. The remedy is the outside view: find a group of similar past cases, see how they went, place your case among them, then adjust for what is truly different. Bent Flyvbjerg developed this into reference class forecasting, and adds that some forecasts are rosy on purpose, to get a project approved.

In a team: "How long did our last three launches take?" "How many pilots like this became paying customers?" Use only real records. When there are none, say the base rate is missing.

Decision records

Michael Nygard's architecture decision records (2011): a short, numbered document per decision with a title, the context (the forces at play), the decision ("We will..."), a status (proposed, accepted, superseded) and the consequences, good and bad. Old records are kept and marked superseded. His reason: without the why, people who come later can only accept a decision blindly or reverse it blindly.

A decision journal, advised by Daniel Kahneman and Michael Mauboussin and popularised by Farnam Street, adds what you expect to happen and how sure you are, written before the outcome is known. It protects against hindsight, which rewrites what we thought we knew.

AI in decisions (2023 to 2026)

Teams now ask AI assistants and agents for options and analyses. The same hygiene applies. An AI's recommendation shown to the room first anchors it, so collect people's views first. Treat an AI's analysis as one input, with its sources checked. An agent never decides: the record names the person who did.

Common mistakes in depth

Sources

All read 2026-10-22.

• Jeff Bezos, 2015 letter to Amazon shareholders (filed with the SEC: sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm) and 2016 letter: aboutamazon.com/news/company-news/2016-letter-to-shareholders.
• Annie Duke, Thinking in Bets (2018), How to Decide (2020), Quit (2022); "Practical Tools for Better Decisions", behavioralscientist.org/practical-tools-for-better-decisions-a-qa-with-annie-duke-on-how-to-decide; on kill criteria, elliotrobia.substack.com/p/kill-criteria; Lenny's Newsletter interview, lennysnewsletter.com/p/making-better-decisions-annie-duke.
• Chip Heath and Dan Heath, Decisive (2013); review at lesswrong.com/posts/d67EB6eRZEToAmyqW.
• Daniel Kahneman, Olivier Sibony, Cass R. Sunstein, Noise: A Flaw in Human Judgment (2021).
• Gary Klein, "Performing a Project Premortem", Harvard Business Review, September 2007: hbr.org/2007/09/performing-a-project-premortem. Mitchell, Russo and Pennington, "Back to the future: Temporal perspective in the explanation of events", Journal of Behavioral Decision Making (1989).
• Dan Lovallo and Daniel Kahneman, "Delusions of Success", Harvard Business Review, July 2003; Bent Flyvbjerg's comment (arxiv.org/abs/1305.0741).
• Andrew S. Grove, High Output Management (1983); summary at shortform.com/blog/managerial-decision-making.
• Atlassian Team Playbook, DACI: atlassian.com/team-playbook/plays/daci. Bain & Company on RAPID decision roles (2023): bain.com/insights/rapid-tool-to-clarify-decision-accountability.
• Michael Nygard, "Documenting Architecture Decisions" (2011): cognitect.com/blog/2011/11/15/documenting-architecture-decisions.
• Farnam Street on the decision journal (2014): fs.blog/2014/02/decision-journal; Alliance for Decision Education on keeping a decision journal: alliancefordecisioneducation.org/resources/keeping-a-decision-journal.
• Google re:Work, team effectiveness guide (Project Aristotle): rework.withgoogle.com/intl/en/guides/understand-team-effectiveness.
• Avinash Kaushik, Web Analytics 2.0 (2009), on the HiPPO.

Decision records, scripts and a worked example

Use the project's own decision format when it has one. Otherwise use these. Every fact in a record carries a source and a date.

A two-way door: one paragraph

# [Decision in a few words]

[Date]. We will [the decision] because [the reason, with source]. We also considered [other option] and [why not]. Decided by [name]. We look again on [date], or sooner if [condition].

A one-way door: the full record

# [Decision in a few words]

- Status: proposed | accepted | superseded by [link]
- Decided by: [one name], [date]
- Input from: [names]
- Agreed by: [names, with dates, once they agree]
- Door: one-way
- How sure: [a number, e.g. about 65%]
- Revisit: [a condition: a state and a date]; checked by [name]

## Decision
We will [the decision, one sentence].

## Why, and why now
[The situation and the forces at play. What waiting would cost.]

## What is already on record
- [earlier decisions or agreed lines this touches, with addresses]

## Criteria (set before the options)
1. [must-have], shown by [evidence]
2. [important], shown by [evidence]

## Options
| Option | [criterion 1] | [criterion 2] | [criterion 3] | Outcome |
|---|---|---|---|---|
| A ... | | | | chosen |
| B ... | | | | rejected: [why] |
| C: wait | | | | rejected: [why] |

## Evidence
- Fact: [what], [source], [date]
- View: [whose], [what], [how sure]
- Assumption: [what we take as true], [what would show it wrong]
- Base rate: [how similar cases went, with source], or "no record of similar cases"

## Pre-mortem: main risks
- [risk] → [change to the plan, or tripwire: signal, date, who watches]

## Dissent
- [name, only if they agree to be named]: [their view, in their words]

## Consequences
- What changes: ...
- What we give up: ...

An options table, criteria first

Write the criteria column headings before filling any row. Rate each option on each criterion from the evidence, with a source in the cell, never from a feeling. A criterion no option meets is a sign the options are too narrow: widen them before deciding.

Asking for independent views

Send each contributor the same question and the same facts, separately, before any meeting:

Before we meet on [date]: which option would you choose, why, and how sure are you, as a percentage? Please write it before reading anyone else's answer.

Collect the answers. Show them side by side at the start of the meeting, with no names if people prefer. Spend the meeting on where they differ.

A pre-mortem script

1. Brief the plan in five lines.
2. Set the scene: "It is [a date a year from now]. This decision failed badly. Take a few minutes, alone, and write every reason it failed."
3. Share in turn: each person reads one reason, round the table, until all are out. The decider writes them down. No debate yet.
4. Group and pick: the reasons most likely and most damaging.
5. Act on each: change the plan, or set a tripwire (a signal, a date, and who watches it).
6. Record the main risks and tripwires in the decision record.

For a two-way door, a two-minute version works: "If this goes wrong, what is the most likely reason?"

Looking at it again

# Review of [decision], [date]

- What we knew then: ...
- What we could have learned at a reasonable cost: ...
- How we decided: roles, options, evidence, pre-mortem
- What happened: ...
- What was luck, and what was the decision: ...
- Keep doing / change next time: ...
- Next: keep the decision | change it (a new record that supersedes this one)

A worked example (invented)

Crumb is an app bakeries use to take orders. Its team: the founder; a developer who builds the app; a sales lead who also holds the budget; and a customer success lead who looks after the bakeries once they sign up.

A two-way door

The customer success lead asks: "Should the weekly summary email go out on Monday instead of Friday?" The email's send day can be changed in a minute and affects one email. The AI sizes it as a two-way door, checks the record (nothing decided), and writes:

# Weekly summary on Mondays

21 Oct 2026. We will send the weekly summary on Monday mornings because three bakeries said they plan the week's baking on Monday (support/notes.md, 14 to 18 Oct). We also considered Sunday evening; bakeries told us they don't read email then. Decided by the customer success lead. We look again on 30 Nov, or sooner if fewer bakeries open it.

A one-way door

The founder asks: "Help us decide which payment provider we launch card payments with."

1. The record. related and agreed find a decision of 10 June: invoices only during the pilot (decisions/2026-06-10-invoices-for-pilot.md), with a revisit condition, "when more than half of bakeries ask for card payments". The customer success lead's notes show that condition met in October (support/requests.md, 3 Oct). The AI says so: the old decision named its own trigger, so reopening it is in order.

2. Framing. "Which provider do we launch card payments with, by 15 Nov?" Decider: the founder. Input: the developer, the customer success lead. Must agree: the developer (they own the payments code) and the sales lead (budget). To know: the whole team.

3. Size. One-way door: moving bakeries' saved cards to another provider later is slow and needs each bakery to act.

4. Criteria first. (1) Pays bakeries out within two working days, a must-have from the customer success lead's notes. (2) Fees at Crumb's volume. (3) Effort for the developer to build. (4) How hard it is to leave later.

5. Options. Provider A, Provider B, and C: keep invoices until January and decide then. The vanishing options test adds D: let bakeries use their own card terminals and record payments in Crumb.

6. Independent views. Each contributor answered before the meeting: the founder A (60%), the sales lead A (70%), the customer success lead A (55%), the developer C (65%), because their team is busy with the October release.

7. Pre-mortem. Top reasons it failed: payouts delayed and bakeries left; the build slipped past Christmas orders. Tripwires: the customer success lead tracks payout complaints weekly; the developer flags by 1 Dec if the build is at risk.

8. Decision and record. The founder chooses A, about 65% sure. The developer disagrees, agrees to be named, and commits. Revisit: "five or more payout complaints by 31 Jan, or the build not live by 10 Dec; the customer success lead and the developer check." The old June record is marked superseded and linked.

9. On record. The AI shows the founder the record, then writes it to decisions/2026-10-22-card-payments.md. hand_out asks the developer and the sales lead to agree, with the founder's line "Please agree or tell me what's missing by Friday"; the team gets it to read. A task for the founder is due 31 Jan to look at it again.