Seeing What You Expect to See
When you have a theory about what's causing a problem, your brain starts filtering information. Evidence that supports your theory feels relevant and important. Evidence that contradicts it feels like noise, an edge case, or "probably unrelated." This is confirmation bias — the tendency to search for, interpret, and remember information in a way that confirms your pre-existing beliefs.
During Incident Response — The Most Dangerous Moment
An alert fires at 2:00 AM. You SSH into the server. The first thing you notice is high CPU usage. Your brain immediately forms a hypothesis: "It's a CPU bottleneck." From that moment, you are biased. You start looking at CPU metrics, process lists, and thread dumps. You spend 45 minutes investigating CPU. Meanwhile, the actual root cause — a network partition causing retries that happen to spike CPU — goes uninvestigated because you never looked at network metrics. They didn't fit your theory.
This is not hypothetical. Studies of incident response consistently show that engineers anchor on their first hypothesis and spend disproportionate time investigating it, even when early evidence should redirect them. The symptom (high CPU) is real; the hypothesis (CPU is the cause) is the bias.
During Architecture Decisions
You've been wanting to try Event Sourcing for months. A new project comes along. You research Event Sourcing and find five blog posts explaining how it solves problems similar to yours. You feel validated. But you didn't search for "Event Sourcing drawbacks" or "when not to use Event Sourcing." You didn't search with equal rigor for alternative approaches. Your research was a confirmation exercise, not an evaluation. The decision was made before the research began.
The Fix — Process Patches
- The "Prove Yourself Wrong" Rule: During incident response, after forming your first hypothesis, spend 5 minutes explicitly trying to disprove it. Check the metrics that would contradict your theory. If CPU is your hypothesis, check network, disk I/O, and memory first. If they're all clean, your CPU theory gains credibility. If network is degraded, you've just saved yourself 45 minutes.
- Architecture Decision Records (ADRs): Require a "Rejected Alternatives" section in every ADR. Force the author to document at least two other approaches they considered and why they were rejected with specific technical reasoning. This structurally combats confirmation bias by requiring engagement with alternatives.
- Devil's Advocate Role: In design reviews, assign one person the explicit role of arguing against the proposed solution. This isn't about being contrarian — it's about ensuring contradicting evidence gets a voice in the room.
- Hypothesis Rotation: During incidents, set a timer. After 10 minutes on one hypothesis, spend 5 minutes assuming it is wrong and listing alternative explanations. This is not a sign of indecision — it's disciplined investigation.
Key Point: Confirmation bias is especially dangerous during incidents because time pressure amplifies it. Under stress, the brain craves certainty and clings harder to its first hypothesis. The best incident commanders build explicit hypothesis rotation into their process: "We've spent 10 minutes on Theory A. Let's spend 5 minutes assuming Theory A is wrong. What else could cause these symptoms?" This one habit can cut mean time to resolution (MTTR) significantly.