Brilliant at Fixing the Wrong Thing
Your team is smart. They spot problems quickly. They jump into action. And three weeks later, the same problem is back.
That's because they solved a symptom. The real problem is still there, quietly producing the same results.
I've watched this pattern play out with over 100,000 participants across 25 years of team simulations. Smart people. Expensive people. Solving the wrong thing over and over, then wondering why the effort never sticks.
The Symptom Trap
Symptoms are loud. They're obvious. They feel urgent. "Our sales are down." "Customer complaints are up." "The project is behind schedule."
Each of those is a symptom. Not one of them tells you what's actually wrong.
In the Save the Titanic simulation, participants face this directly. The ship is sinking. Water is coming in. The obvious symptom is the water. The obvious move is to pump it out.
The teams that focus only on pumping water run out of time. The teams that ask "why is the water coming in faster than we expected?" find the move that changes the outcome. Same team, same information, two very different results — and the only difference is whether they stopped at the symptom.
The 5 Whys, Worked Through
Root Cause Analysis is one of six key learnings in the experience. The simplest version is the 5 Whys. You take a problem and ask "why" until you reach a cause you can actually fix. Five is a rule of thumb, not a law.
Here's what it looks like in practice.
The problem: sales are down this quarter.
- Why? Fewer proposals are going out.
- Why? The sales team spends its time on admin instead of selling.
- Why? The CRM needs too many manual entries.
- Why? It was never configured for the current workflow.
- Why? Nobody updated it after last year's reorganization.
The symptom was "sales are down." The root cause is an outdated CRM configuration. Fixing the CRM takes two weeks. Pushing salespeople to "sell harder" takes forever and doesn't work, because the real problem was never their effort.
A Second Example: The Deadline That Keeps Slipping
One example can look like luck. Watch it work on a different kind of problem.
The problem: this team misses every launch date.
- Why? The final testing phase always runs long.
- Why? Bugs show up late that should have been caught early.
- Why? The team starts testing only after everything is built.
- Why? Testing is treated as a phase at the end, not a habit throughout.
- Why? The plan rewards finishing the build, and nobody owns quality until the end.
The symptom was "we miss deadlines." The root cause is a plan that leaves quality until it's too late to protect. You could add more testers and still miss the date. Change when testing starts, and the date holds. That's the difference a root cause makes: it points to a change that actually moves the result.
Where the 5 Whys Breaks
The 5 Whys is simple, and simple tools get used carelessly. Here are the four ways teams get it wrong, and how to keep it honest.
It stops at a person. If your fifth "why" lands on "because Dave dropped the ball," you found a scapegoat, not a cause. Keep going. Why was it possible for one person to drop that ball with no backup? Root causes live in the system, not the individual.
It follows one thread when there are several. Big problems rarely have one cause. Sales dropped because of the CRM *and* because two senior reps left. Run the 5 Whys down each branch, then compare. A quick cause-and-effect map catches the branches a single line of questions misses.
It runs on opinion instead of evidence. "Why is the water coming in fast?" answered with a guess gives you a confident wrong answer. Each "why" needs a fact behind it. If you can't point to evidence, you've found the next thing to check, not the cause.
It stops at the first fixable answer. Teams love to stop the moment they hit something they can act on today. Ask one more "why" than feels necessary. The cause you can fix this afternoon is often still a symptom of the one worth fixing for good.
How to Run the 5 Whys in Your Next Meeting
You don't need a workshop. You need fifteen minutes and a whiteboard. Run it like this.
1. Write the problem as a fact, not a feeling. "Sales fell 12% in Q2," not "sales are bad." A vague problem produces vague causes. 2. Ask the first "why" out loud and write the answer where everyone can see it. Visible answers keep the group honest. 3. Back each answer with evidence. If nobody can point to a fact, that gap is your next task, not your cause. 4. When an answer names a person, ask why the system allowed it. Push past blame every time. 5. Split the thread when there's more than one cause. Follow each branch to its own root. 6. Stop when the cause is something you can change and the fix would prevent the problem from returning. That's the root. Assign it an owner before anyone leaves the room.
Do this once as a team and the habit starts to form. Do it under real pressure, with real stakes, and it becomes reflex. That's what most team problem-solving activities never build: a low-stakes puzzle never forces the team to dig past the obvious symptom, so the habit never forms.
Symptom or Root Cause? A 30-Second Check
Not sure whether you've found the real problem? Run these three checks.
- The "so what would we fix?" check. If the answer points to a specific, changeable thing, you're close to a root cause. If it points to "try harder" or "care more," you're still on a symptom.
- The recurrence check. Ask: if we fix this, would the problem stay gone? A symptom fix makes the problem quiet for a while. A root-cause fix makes it stop coming back.
- The evidence check. Can you point to a fact, not a hunch? Root causes survive contact with the data. Symptoms usually don't.
Why Teams Skip This Step
Teams skip Root Cause Analysis for one reason: it feels slow. When there's a crisis, the impulse is to act immediately. Analysis feels like delay.
It's the opposite. Five minutes of asking "why" saves weeks of solving the wrong thing.
Cadbury learned this through a Learn2 experience. They had contracts that took 8 months to renegotiate. After their team practiced Root Cause Analysis, they renegotiated 100% of their contracts in 8 weeks. The speed came from understanding the real problem, not working faster on the wrong one.
What the Simulation Reveals
In the simulation, the 5 Whys creates visible results. Teams that dig to root causes protect more of what matters. Teams that react to symptoms run out of time.
The learning lands differently when the stakes are visible. In a meeting room, Root Cause Analysis is a concept. In a 3.5-hour immersive experience, it's a survival skill. Participants feel the difference between treating symptoms and solving problems, and that feeling travels straight back to the workplace.
When Wharf Hotels used a Learn2 experience to address declining sales, they dug to root causes instead of treating it as a motivation problem. They found structural issues in how their teams worked together. Fix the structure, the sales follow. The result: a 173% increase in global sales revenue. The Team Performance approach helps teams close the distance between symptoms and solutions.
Start Asking Why
The next time your team faces a problem, resist the urge to jump to solutions. Take five minutes. Ask why until you reach a cause you can fix. Write down each answer, and back each one with a fact.
You'll be surprised how often the real problem is completely different from what it looked like on the surface — and how much faster the real solution appears once you stop fixing symptoms. This is also what reframing the problem does for a team: it moves the group off the obvious answer and onto the useful one.
If your team keeps solving the same problems over and over, the issue isn't effort. It's depth.
Read next: The Problem Reframing Exercise That Changes Everything