The Surface Fix Trap
Project late? Add more people. Customers leaving? Offer a discount. Employees disengaged? Plan a pizza party.
These are surface fixes. They address what happened without asking why it happened. And they guarantee the problem returns. Usually bigger.
Most teams know about root cause analysis. Few teams actually do it well. The gap between knowing and doing costs organizations millions annually in repeated problems, rework, and band-aid solutions that create new problems.
The 5 Whys: Simple and Underused
Root Cause Analysis is one of six key learnings in the Save the Titanic experience. The version we use is the 5 Whys. Ask why five times. Each answer peels back a layer until you reach the cause that, if fixed, prevents the problem from recurring.
Here's what it looks like:
The project was late. Why? The testing phase took twice as long as planned. Why? We found 47 defects that could have been caught earlier. Why? The development team didn't have clear acceptance criteria. Why? The requirements document was written by someone who didn't talk to the end users. Why? We don't have a process for including end users in requirements gathering.
That fifth why is the root cause. Fix it, and you fix every future project that would have suffered the same problem. Fix the first why — add more testers — and you just made late projects more expensive without preventing them.
Where Teams Stop Too Early
Most teams ask why once. Some ask twice. Almost nobody gets to five. Here's where they stop and why.
They stop at the comfortable answer. "The project was late because testing took too long." That answer doesn't implicate anyone in the room. It points at a process. It's safe. The real answers — "we don't include end users" or "our requirements process is broken" — implicate decisions made by people in the room. Those answers feel dangerous. So teams avoid them.
They stop at the technical answer. "The system crashed because the server ran out of memory." Technical answers feel definitive. They sound like root causes. They're usually symptoms. Why did the server run out of memory? Why wasn't the memory issue caught in monitoring? Why doesn't the monitoring alert for this condition? The root cause might be that nobody owns infrastructure monitoring. That's a people problem wearing a technology costume.
They stop when someone gets defensive. Why three or four often points at a decision someone made. That person pushes back. The team backs off. The root cause stays hidden because the environment doesn't support speaking up about uncomfortable truths.
The Shortcut: Start With Why Three
Here's the shortcut most teams miss. When you face a recurring problem, skip the first two whys. You already know them. Start at why three.
Why three is where the problem shifts from event to pattern. The first two whys describe what happened. Why three starts to reveal why it keeps happening.
"The project was late because testing found defects because we didn't have clear criteria." That's why three. Now ask why two more times. You'll reach the systemic cause in less time with less resistance.
In the Save the Titanic simulation, participants learn this by experience. When the iceberg is the problem and your first two attempts to fix it fail, you're forced to dig deeper. The teams that save the ship are the ones who stop fixing leaks and start asking why the leaks keep appearing.
Making It Work in Your Team
When ArcelorMittal's 710 leaders practiced this with Duke Corporate Education through our experience, three things made the difference.
Use a facilitator, not a leader. The person asking "why" shouldn't be the person who made the decisions being examined. A neutral facilitator keeps the inquiry productive and prevents defensiveness from shutting it down.
Separate the problem from the person. Frame every why as "what in our system allowed this?" not "who caused this?" Systems thinking removes blame and opens honesty. The accountability framework works the same way. Hold the system accountable before holding individuals accountable.
Document every why. Write each answer on a board where everyone can see it. The Capturing Ideas technique applies here. When the chain of whys is visible, the team can see the path from symptom to root cause. It's harder to stop at why two when whys three, four, and five are staring back at you as empty spaces.
The Compound Return
Teams that practice root cause analysis don't just fix individual problems. They fix categories of problems. Every root cause you eliminate prevents dozens of surface symptoms from recurring.
Learn2 clients see this compounding effect. Rogers converted 26,000 customers in 6 weeks — not by addressing individual customer objections, but by fixing the root cause of how their team handled objections. Fix the root, and the branches take care of themselves.
The ROI of this approach is straightforward. Calculate how much your organization spends fixing recurring problems annually. That's the cost of shallow analysis. Root cause analysis converts that cost into permanent solutions.
Practice It This Week
Take one problem your team has fixed more than once. Run the 5 Whys. Start at why three if you already know the surface causes. Get to a root cause that, if fixed, eliminates the category of problem.
Then fix it. Not the symptom. The cause.
If your team has trouble getting past why two, the issue isn't technique. It's environment. A 3.5-hour immersive experience builds the trust and frameworks needed to dig deep honestly. The simulation makes shallow analysis fail visibly. When the ship sinks because you fixed a symptom, you remember. And the next time you dig deeper.
Book a 20-minute walkthrough and I'll show you how the simulation trains your team to find and fix the real problems — not just the visible ones.
Read next: Why Your Team Solves Symptoms, Not Problems