Hindsight Bias

"I Knew It All Along"

After any event occurs, the human brain retroactively adjusts its sense of how predictable that event was. Once you know the outcome, the path that led to it seems obvious — even inevitable. This is hindsight bias, sometimes called the "knew-it-all-along effect."

Consider this sequence:

• Monday 10:00 AM: An engineer deploys a configuration change that updates the database connection pool size from 20 to 50. The change was reviewed by two peers. The staging environment showed improved throughput. The deploy follows all standard procedures.
• Monday 10:47 AM: The database runs out of connections. The application returns 500 errors for 12 minutes until the change is rolled back.
• Monday 2:00 PM (Post-Mortem): A senior engineer says: "Why would you increase the pool size to 50? The database max_connections is set to 100, and we have 3 application replicas. 3 × 50 = 150. That's obviously more than 100."

The math is obvious now. But on Monday at 10:00 AM, the deploying engineer didn't know (or didn't remember) that max_connections was 100. The staging environment had a different database configuration. The two peer reviewers didn't catch it either. The decision was reasonable given the information available at the time. The word "obviously" in the post-mortem is the fingerprint of hindsight bias.

Why This Matters for Engineering Culture

Hindsight bias is the single biggest threat to blameless post-mortems. When the outcome is known, every decision that contributed to the failure looks like negligence. "How could they not see this coming?" The answer is: they couldn't, because they didn't have the information you have now.

When post-mortems become blame sessions, engineers learn to:
- Avoid making changes (velocity drops)
- Hide mistakes instead of reporting them (reliability drops)
- Optimize for "not getting blamed" rather than "making the best decision" (quality drops)

The irony is that blame-focused post-mortems make systems less reliable, not more. They suppress the information flow that would allow the team to identify and fix systemic problems.

The Fix — Process Patches

• The "What Did They Know?" Test: During every post-mortem, explicitly reconstruct the information available to each decision-maker at the time of their decision. Write it on the whiteboard. Then ask: "Given only this information, was the decision reasonable?" Usually, the answer is yes — which redirects the conversation from "who failed" to "what information was missing from the system."
• Separate Decisions from Outcomes: A good decision can have a bad outcome (you deployed a well-tested change that hit an unknown edge case). A bad decision can have a good outcome (you deployed without testing and got lucky). Judge the decision process, not the result. If you only punish bad outcomes, you punish good decision-making that got unlucky — and you reward bad decision-making that got lucky.
• Pre-Mortems (Prospective Hindsight): Before a major change, imagine it's next week and the change caused an outage. Ask: "What went wrong?" This leverages the brain's hindsight machinery before the event, surfacing risks that are hard to see when looking forward but easy to see when looking backward — even from an imagined future.

Key Point: Hindsight bias doesn't just affect how we judge others — it affects how we judge ourselves. After causing an incident, engineers often think "I should have known better," leading to shame and reduced confidence. A healthy engineering culture explicitly names this bias and reminds people: "You made a reasonable decision with the information you had. The system failed to surface the information you needed. Let's fix the system." The goal of a post-mortem is to improve the system, not to improve the person.