Five whys
A root cause analysis of why we never do root cause analysis
The Five Whys is an elegant problem-solving technique. You encounter an issue. You ask “why?” You record the answer, and ask “why?” again. You keep going until you’ve followed a single thread far enough to find a root cause rather than a symptom.
For example
A customer reports that their data export is wrong.
Why?
Because new validation was added to the system last week, reformatting some reports.
Why?
Because a new column was added to the underlying table.
Why?
Because a partner integration required it.
Why?
Because the company is extending its services and the impact of changing the table wasn’t understood.
Why?
Because the team that built the integration were working from outdated documentation and didn’t know about the reporting dependency.
The surface problem was a broken export. The root cause was that nobody knew the systems were connected, and there was no documentation for this reporting dependency. Fixing the symptom will sort out the immediate issue. Identifying and fixing the cause will ensure no repetition of the problem.
What?
Toyota developed the five whys technique as part of its Toyota Production System. It requires no software, no certification, and no consultants. You’d think it would be everywhere.
It isn’t.
Why?
There’s a legitimate criticism that complex problems have more than one root cause; that’s certainly true. There are versions of the technique that acknowledge multiple causes through branching off a fishbone diagram. Some companies have embraced digging deeper than five whys, using seven whys.
However, I don’t think that simplification has been the barrier to adoption. I don’t see any evidence that more complex tools have replaced five whys anywhere. I think that many organisations lack the curiosity to even follow a single thread to the end to fix an issue.
Why?
Why don’t organisations show that curiosity?
Because someone is waiting for an answer. The support ticket needs to be closed, the stakeholder needs a date, the customer needs a response. The pressure to act is immediate. The pressure to investigate underlying causes dissipates once that response is given.
So, short-term fixes get rewarded. Workarounds get created. Sometimes they even get documented. The issue is parked until the next time something similar happens.
Why?
Why don’t we fix the underlying problem?
Tracing a problem to a root cause can be complex. It can take time and consideration. Many organisations don’t allocate time to the possibility of failure. Others don’t give sufficient value to the idea of improvements through retrospective analysis.
These two blind spots prevent the organisation from being able to see how to fix its problems. Without retrospectives, learning takes a back seat. Without scenario planning, the planning fallacy puts the team in conflict with reality, and reality always wins. In organisations that optimise for capacity, and not for flow, teams are always operating under pressure.
Why?
Why don’t organisations plan with slack so that we won’t necessarily have to pivot when the unexpected happens?
Often, it’s about trust. Leaders in low-trust organisations hear of planning to 80% capacity and they see waste. They think that teams will slack off if they’re given slack time.
So every gap is filled. The planning fallacy dictates that we assume perfect conditions, perfect information, and perfect execution. The leader who pretends certainty is rewarded. The leader who presents a plan with deliberate gaps is treated like the dog ate their homework.
Why?
Why does the organisation reward certainty over honesty?
Because certainty is easy to communicate. “We’ll deliver X by March” fits in a subject line and gives an executive something they can report upwards with confidence. “We believe X is achievable by March, assuming no significant unknowns emerge and the dependencies we’ve identified hold, but there’s meaningful uncertainty around the integration layer” doesn't fit easily in a C-suite update.
Over time, the communication becomes the culture. It’s like a fairground mirror version of Conway’s Law. If honest uncertainty never makes it into the room where decisions are made, the organisation is geared to reward certainty, to treat every forecast as a commitment.
As a result, unforeseen challenges are treated as failures of planning rather than features of complex work. The entire operating model assumes that with enough rigour, enough process, enough estimation, we can eliminate surprise. That if we just plan harder, reality will cooperate.
It won’t. Software development is complex work happening in a socio-technical system. Uncertainty isn’t a bug. It isn’t even a feature. It’s the system.
Using five whys to understand why organisations don't use five whys may feel meta. But the technique works. At least one of those roads leads to trust. This is where we leave the whys behind and move onto how. How do you build that trust in your organisation?