In 1988, Jonathan Baron and John Hershey gave people a set of medical decisions to grade. Each case described a doctor deciding whether a patient should have a risky operation, with the odds spelled out. The decision and the information were identical across versions; the only thing that changed was whether the patient lived. When the patient survived, people rated the doctor’s thinking as better and the doctor as more competent. When the patient died, the same reasoning on the same facts got marked down. The paper, Outcome Bias in Decision Evaluation, found the same pattern across five studies.

You might hope that was a quirk of a small 1980s sample. It wasn’t. A 2023 replication in the International Review of Social Psychology ran the first experiment again with 692 participants instead of the original 20 and found a larger effect than Baron and Hershey did. The detail that should worry every manager: the small group of participants who said outcomes should not matter when judging a decision still graded the successful decisions higher. Knowing about the bias did not switch it off.

That is outcome bias. It is the habit of grading a decision by how it turned out instead of by what the person knew and did when they made it. Poker players call it “resulting,” and Annie Duke, who played professionally before writing about decisions, puts it plainly: people link the quality of outcomes far too tightly to the quality of decisions.

The most expensive place it shows up is your own head

Most writing on this treats outcome bias as something you do to other people, usually in performance reviews. That happens. But the more corrosive version is the one you run on yourself, because your own decisions are the ones you learn from.

Early in my time running operations at a large telecom, I approved a firmware upgrade on a set of core switches during a weekday afternoon. The vendor had flagged it as urgent, the change board was a week out, and I decided the risk of waiting was worse than the risk of doing it live. It went perfectly. Nobody noticed. And for the next couple of years, I quietly treated “urgent vendor patch, do it live” as a reasonable call, because the one time I had made it, nothing broke.

It took a different upgrade, same reasoning, same confidence, to show me what I had actually learned from the first one: nothing. The second one dropped a chunk of traffic for forty minutes in the middle of the business day. The decision process was identical both times. I had simply been rewarded for a coin flip and filed it as skill.

The reverse costs you just as much. A manager who makes a sound call, gets unlucky, and then spends six months avoiding anything resembling that call has learned the wrong lesson too. If you have ever caught yourself saying “I’ll never do that again” after one bad result, check whether the decision was actually wrong or just unlucky. I wrote about the related trap of treating every decision as permanent; outcome bias is often what makes managers that cautious in the first place.

Pete Carroll, the Seattle Seahawks coach who called a pass from the one-yard line at the end of Super Bowl XLIX, had the cleanest public line on this I have heard. After the interception that lost the game, he called it “the worst result of a call ever” and added that if the pass had been caught, “nobody would have thought twice about it.” You can argue about the call. Notice that he separated the call from the result, which is the exact move most of us skip.

Near misses are where it does the real damage

Robin Dillon and Catherine Tinsley at Georgetown tested this with project managers in a 2008 Management Science study. Evaluators, including NASA employees and contractors, rated managers whose projects succeeded, failed, or nearly failed and were saved by luck. The near-miss managers were rated about the same as the outright successes. In a second round of studies, people who had seen near-miss information went on to pick riskier options, because the close call had made the risk feel smaller.

That matches what I saw on operations floors for two decades. A change that almost took down a service but didn’t gets logged as a success. The person who got lucky is praised for a smooth weekend. The process gap that nearly bit everyone stays exactly where it was.

A few habits that loosen the grip

You will not fix this by trying harder to be fair. The replication shows that intent is not enough. What works is changing what you look at, and when.

Write the reasoning down before the result arrives. For any call that matters, I jot three lines: what I know, what I’m betting on, and what would tell me I was wrong. It takes two minutes. When the result comes in, I compare it to the note, not to my memory, which will have rewritten itself to fit whatever happened.

Review good outcomes as seriously as bad ones. Most teams only hold a post-incident review when something breaks. Pick one success a month and ask the same questions you would ask about a failure: what did we know, what did we assume, how much of this was luck? A premortem works on the front end; this is its counterpart on the back end.

Grade near misses as misses. When something almost failed, treat it as data about your process, not as proof the process works.

Separate the two questions out loud. When someone on your team brings you a decision that went badly, ask “was this a good call with what you knew?” before you ask “what went wrong?” The order matters. If you start with the result, you will grade the person on the dice.

One decision is never enough evidence to judge a decision rule. The firmware call I made twice was the same call both times. Only one of the results was telling me anything about it, and it wasn’t the good one.