Decisions vs Outcomes (Resulting)

The idea

Annie Duke, a former professional poker player, argues in Thinking in Bets (2018) that the quality of our lives comes down to two things: the quality of our decisions and luck. Poker makes this obvious, because a well-played hand can lose and a badly played one can win. Most of life hides it.

Duke uses the poker term resulting for the habit of judging a decision by its outcome. Her book opens with a well-known American football play call that was widely condemned because it failed, and asks whether the call was bad or a reasonable bet that did not come off. A decision is a bet on an uncertain future, so it should be judged by what was known, the options considered and the reasoning used, not by the single result that luck produced.

Why it works

Outcomes are a small, noisy sample. One result says little about whether the decision was sound; it takes many outcomes to separate skill from luck.

Resulting teaches the wrong lessons. If a risky shortcut happens to work, it gets repeated; if a careful decision is unlucky, the team abandons a good practice.

Judging the process makes it improvable. You can change how you gather information, weigh options and set criteria. You cannot change luck.

Where it applies

• Post-incident and project reviews, where hindsight makes every warning look obvious and every choice look careless.
• Architecture decisions, where a design chosen for good reasons may meet conditions nobody could foresee.
• Vendor and technology bets, where a product's later failure or success often owes more to the market than to the choice.
• Performance conversations, so people are not rewarded for lucky gambles or blamed for sound calls that went wrong.

How to apply

1. Record decisions when you make them. Note the context, options, information available, expected outcome and confidence, for example in an architecture decision record.
2. Review wins as well as losses. Ask whether a success came from good reasoning or good luck.
3. Separate the four cases. Good decision with good outcome, good with bad, bad with good, bad with bad; only the decision is yours to fix.
4. Ask what information was worth getting. Some bad outcomes reveal a cheap check or prototype that should have come first.
5. Judge people by their process, and make it safe to say "we made the right call and were unlucky".

Example scenario

A team chose a managed queue service after load tests and a review of the provider's track record. Six months later a regional outage at the provider took the system down for hours, and leadership demanded to know who had approved such a risky design.

The architect brought out the decision record. It showed the options, the expected availability, and the decision to accept single-region risk for cost reasons, signed off with the business. The review then asked the right questions: was the risk accepted knowingly, and has anything changed? It had, because usage had grown, so they added a second region, without blaming the original choice or pretending it had been foolish.

Questions to ask

When not to use it

• Repeated outcomes that point the same way. A pattern of bad results is evidence about the process, not just bad luck.
• Decisions with no uncertainty, where a bad outcome really does reveal a mistake.

How it misleads you