Resulting

An outcome is one draw. The decision was the bet.

October 9, 2026 7 min read

A launch slips, and the retro spends an hour on who made the call. A different launch, decided on a hunch that skipped every check, lands well and quietly becomes how the team does launches now. Both lessons came from the same place: the outcome. Neither came from the decision.

Poker players have a name for this: resulting. Annie Duke built the first chapter of Thinking in Bets (2018) around it. Resulting means grading a decision by its outcome alone, treating a good result as proof of a good call and a bad result as proof of a bad one.

Outcomes do carry information. The trouble is that a single outcome mixes the quality of the decision with luck and with facts nobody could have known, and resulting assigns all of it to the decision.

Four quadrants, two of them misleading

Every decision lands in one of four places once the result comes in.

The two rows where decision and outcome disagree are where teams learn the wrong lesson. They also compound. A team that drops a sound process after one unlucky result has to relearn it later. A team that adopts a lucky shortcut keeps running the same bet until the odds catch up.

Why thinking harder in the retro doesn't fix it

The obvious remedy is to ask, during the retro, what the decision looked like before anyone knew the result. Baruch Fischhoff tested how well people can do that. In "Hindsight is not equal to foresight" (1975), he gave people short accounts of events with several possible outcomes. Some were told which outcome had actually happened, then asked how likely each outcome had seemed. Those who knew the outcome rated it as more likely than people who didn't. Fischhoff called this creeping determinism: once you know how something ended, the ending starts to look like it was always coming.

That is the trap inside every retro. The people judging the decision already know the outcome, and knowing it changes their sense of what was predictable. Asking them to set it aside is asking them to unknow something.

So the fix has to come from a witness that never learned the outcome.

Grade the decision on what was known

Duke's alternative is to treat each decision as a bet and judge the bet rather than the payout. One practical way to apply that is three questions, each answered from the time of the decision, not from today:

1. What did we know? The information available when the call was made, including what was uncertain.
2. What did we expect? The outcome the team thought most likely, and the outcomes it thought possible.
3. Why this option? The reasoning that connected the first two to the choice.

A bad outcome inside the range the team expected says little about the decision on its own; the question is whether that range was reasonable. A bad outcome the team never considered, but reasonably could have, is evidence about the decision. A good outcome that relied on something nobody expected is the dangerous one, because it looks like skill.

None of these questions can be answered reliably after the fact, for the reason Fischhoff found. They can only be read from something written before the outcome arrived.

Where this fits at Brief

Fischhoff's result is why a decision record does more than help people remember. A record written at the time of the decision is the one witness in the retro that doesn't know how things turned out. Everyone in the room has hindsight. A record left as it was written has only foresight.

Brief's decision records carry the pieces a fair retro needs. When a team logs a decision from Slack, the Slack integration captures the decision itself, the rationale from the message, who logged it, a timestamp, and the channel where the conversation happened. A coding agent or teammate can record the same thing from the CLI with brief decisions create --decision "..." --rationale "...". The rationale answers the third question directly. The timestamp is what makes it foresight: it dates the reasoning to before the result existed, so the retro reads what the team thought then instead of what anyone, including the person who made the call, remembers thinking now.

The record also protects the decision after it changes. When a bad outcome leads a team to reverse course, Brief keeps the old decision as history and marks that a newer one replaced it, the relationship the supersession post describes. The original call and its reasoning stay readable after they stop governing. That matters for resulting specifically. A team asking "did we learn something, or did we just get unlucky?" six months later can read what the first decision assumed, compare it with what actually happened, and see whether the reversal answered a flaw in the reasoning or a bad draw.

The second question is the one most records miss, and Brief's do too unless someone writes it in. Brief stores the rationale it is given. It doesn't ask for a probability or an expected range on its own. The cheapest fix is to put the bet in the rationale: "we expect most of the accounts we contacted to switch plans within a quarter; if almost none do, the pricing assumption was wrong." That one sentence turns a later bad result from a verdict into a comparison, and it is the same move a tripwire makes: decide in advance what evidence would mean you were wrong.

The limits are worth stating. A record only helps if it was written at the time and left alone afterward; a rationale reconstructed or edited after the result carries the same hindsight as the retro. A rationale also says what the team believed, not whether the belief was reasonable, so grading the decision still takes judgment. What the record changes is what that judgment has to work from: the reasoning as it stood before anyone knew the answer, instead of a memory that already does.

Think about the last decision your team reversed after a bad result. Could anyone show what the team expected before it knew?

Frequently asked questions

What is resulting? Judging a decision by its outcome alone. The term comes from poker, and Annie Duke's Thinking in Bets (2018) popularized it. It treats a good result as proof of a good decision and a bad result as proof of a bad one, ignoring luck and the limits of what could have been known at the time.

Is resulting the same as hindsight bias? They are related. Hindsight bias, which Baruch Fischhoff studied in 1975 under the name creeping determinism, is the tendency to see an outcome as more predictable once you know it. Resulting is the judgment that follows: blaming or crediting the decision for an outcome that hindsight makes look inevitable.

Do outcomes ever tell you anything about a decision? Yes. An outcome the team never considered, but reasonably could have, is evidence about the reasoning, and many outcomes from the same kind of decision say more than one. A single outcome inside the range the team expected says little about whether the decision was sound.

How does Brief help avoid resulting? Brief records decisions with their rationale, author, and timestamp, and keeps a replaced decision as history instead of deleting it. That gives a retro a dated version of the reasoning, which helps as long as it was written before the outcome and not edited afterward. Brief doesn't record the odds the team expected unless someone writes them into the rationale.