Craig Stanley
Home / Decisions / Bias field guide

Outcome bias: judging the decision by the luck

Good decisions sometimes turn out badly and bad ones sometimes work. Outcome bias is judging the decision by the result alone.

10 October 2026 · 2 min read · Craig Stanley
In short, explained

Sometimes you make a good choice and it still goes wrong, just by bad luck. That doesn't mean it was a bad choice.

Outcome bias is when we judge a decision only by how it turned out. A sensible decision can end badly through bad luck, and a reckless one can get lucky. To learn anything, judge the decision by what was known at the time.

Outcome bias conflates decision quality with outcome quality. Counter it by recording information, options, probabilities and reasoning at decision time, then reviewing against that record rather than hindsight.

What it looks like

A project manager approves a launch after reasonable testing. A rare fault slips through and causes an outage. In the review, the decision is called "reckless". Six months earlier, a colleague skipped testing entirely, got lucky, and was praised for speed.

The same thing happens with AI. A model that's right 98% of the time will eventually make a visible mistake. If one bad case is enough to switch it off, you'll lose the value of the other 98%.

Why it matters

Outcome bias teaches the wrong lessons. People learn to avoid visible risks rather than make good decisions. They learn that luck counts as skill. Over time, the organisation becomes cautious about the wrong things.

How to counter it

Write down the decision before the outcome is known. Record the options, what you knew, what you expected and how confident you were. The decision record gives a format.

Review against the record, not the result. Ask: given what we knew, was this a reasonable choice? Was there information we should have had? Were our probabilities sensible?

Look at many decisions together. One outcome tells you little. Twenty decisions made the same way tell you a lot.

Read next

A question to take awayWhich repeated decision would you trust a cheap model to score first, with a person checking the close calls?

About me

Craig Stanley

Microsoft AI consultant and technical architect, based in Whitley Bay. Over the last few years I've delivered Microsoft 365 Copilot, Copilot Studio agents, Azure AI Foundry work and governance for UK public sector and financial services organisations.

What interests me is the decision underneath the tool: what it costs, what it risks, and whether a small, transparent model can make it better. I write the methods up here and on Substack so anyone can use them.

Find me