“I Know What Happened.”

The Problem

Confirmation bias in RCA rarely shows up as rushing. It shows up as certainty.

The most experienced people in the room recognize a failure pattern and unconsciously lock onto a familiar explanation. “It’s always that coupling.” “Same bearing issue again.” “We’ve seen this a hundred times.” The investigation might still look rigorous, but it quietly narrows. The team hunts for evidence that supports the veteran narrative, stops asking deeper questions, and lands on a surface-level physical cause.

The writeup is clean. The repair is real. And the recurrence rate stays stubborn — because the system that created the failure never got touched.

Getting to the Root Cause

The real root isn’t arrogance. It’s pattern dominance.

Experience is a performance advantage in troubleshooting, but it can be a liability in investigation. Troubleshooting rewards fast pattern recognition and restoring function. RCA requires the opposite — holding multiple hypotheses, interrogating systemic contributors, and being willing to discover a cause chain that doesn’t match the usual suspects.

Two conditions keep confirmation bias alive in RCA programs:

1. Tribal knowledge outranks evidence standards. When a program has no requirement to verify the leading hypothesis before accepting it, the most confident voice in the room sets the direction. Evidence gets collected to support the conclusion, not to test it.
2. Physical causes satisfy the form. Most RCA templates have a root cause field. A component failure fills that field cleanly. The systemic cause — the work process gap, the PM strategy failure, the design margin that was never adequate — has no box to live in, so it never gets found.

When “we’ve seen everything” becomes the ceiling on investigation, the organization gets very good at replacing parts and very bad at reducing risk.

Corrective Action (You Can Do This Week)

Add one lightweight rule to your next investigation before the team reaches a conclusion.

• Two-Layer Requirement. Every RCA must identify one physical cause and one systemic cause. Systemic causes include work process gaps, PM strategy failures, design margin issues, spares availability, training pathways, vendor management, operating envelope, and handoff discipline. If the systemic layer is blank, the RCA is not ready to close.
• Evidence Challenge. For the leading hypothesis — especially the one someone said first — require one written line: “What would we expect to see if this cause is true?” Then verify it against a trend, inspection result, condition data, or defect pattern before the branch gets accepted.
• Fresh Eyes Review. Before sign-off, have one person with no asset history review the cause chain. An ops lead from another line, a planner, someone from EHS or quality. Their job is one question: “What system allowed this to persist?” That outside read will surface assumptions the team stopped questioning two hours into the meeting.

What Do You Think?

In your plant, what’s the most common “we’ve seen this before” conclusion that keeps investigations stuck at the surface? And what finally pushed the team to look deeper?

Help If You Need It

If your RCAs consistently stop at the component level, it is usually a program design problem. The organization has not defined or enforced a standard for systemic cause quality, so component fixes quietly masquerade as prevention.

Root cause analysis training builds the facilitation discipline to reach latent causes consistently, and RCA software like EasyRCA can bake the two-layer quality gate directly into the investigation workflow so the systemic question gets asked every time, not just when the right facilitator is in the room.