Five Whys

🎯Define the problem #

One measurable sentence, no adjectives

Start not with 'deploys break often' but with a sentence carrying numbers and a period, like '3 of 12 deploys in the last 4 weeks were rolled back'. If the problem statement is fuzzy, participants start analyzing different problems from the very first why. One Five Whys handles one incident; lump several incidents together and the causes get smeared together too.

Why 1 #

The direct cause: what happened in that moment

The answer to the first why is usually a visible technical or physical fact, for example 'the migration script failed'. If several answers surface here, pick the one with the largest contribution and split the rest into separate chains. Answers at this level must be immediately verifiable through logs, records, or reproduction.

Why 2 #

Why did that direct cause occur

From the second why, answers shift from facts to conditions, like 'staging did not have the same data as production'. This is where 'it seems like' starts creeping in, so write the verification method next to each answer and do not descend to the next why before confirming. A third why built on a guess is entirely wasted work.

Why 3 #

Why was that condition left in place

Around the third why, an individual's action tends to appear: 'the engineer skipped the check'. The temptation to stop is strongest here. When a human error shows up, change the question: why was that mistake possible in the first place, and why was it not caught? The system that allowed the mistake is the subject of the next why.

Why 4 #

The layer where structure and process defects surface

In a well-run chain, around the fourth why the answer stops being a specific event and becomes a repeatable pattern: 'the checklist has no such item', 'no stage exists that owns that verification'. If the answer is still about a specific person or a specific day's circumstances, the chain has drifted; go back to why 2 or 3 and pick the branch again.

🧨Why 5 = root cause candidate #

The point where fixing it blocks recurrence

The test for a root cause is not depth but effect: if you fix this, does the same family of problems stop happening? Confirm with the reverse test: starting from why 5, walk back up with 'therefore' and if it flows naturally all the way to the problem statement, the chain holds. Filling in five whys is not the goal, so if you arrive at the third, stop at the third.

Where to stop #

Done when you reach a process you control

A chain that keeps descending forever is not analysis, it is escape. The stopping point is the deepest process your team can control. When the answer becomes something out of reach, like 'the recession' or 'human nature', climb one level up and make that the root cause. Causes outside your control are not things to fix; they are premises to design around so you can withstand them.

🛠️Countermeasures #

Remove the cause, or absorb the error

Countermeasures come in two kinds: eliminating the cause itself, and buffers that keep the cause from turning into an incident even if it remains. 'Be more careful' and 'do training' are not countermeasures, they are wishes; you need structural changes that do not depend on human memory, such as automation, changed defaults, or enforced checks. New side effects each countermeasure might create are written down at this stage too.

Verify 1: recurrence metric #

Set a window to observe the effect in numbers

Before applying the countermeasure, decide what to observe and for how long before calling it a success, for example 'zero rollbacks of the same type for 8 weeks after rollout'. A Five Whys closed without a metric and a window gets redone from scratch at the next incident. If it recurs, suspect a wrong diagnosis before you suspect a failed countermeasure.

Verify 2: reverse reading #

Audit the chain with the 'therefore' test

Before finalizing the countermeasure, read the whole chain backwards. Start at the root cause, connect upward with 'therefore', and the point where a sentence turns awkward is where a logical leap is hiding. Having a third party read it backwards is the cheapest and fastest audit; the author cannot see their own leaps.

⚠️Common traps #

Three habits that ruin the chain

When Five Whys degenerates into an empty ritual, the cause is the operation, not the tool. Three habits account for most failures: stopping at a person, settling for the first answer, and linking by guesswork. Simply announcing these three as explicit rules before the meeting changes the quality of the chain.

Trap 1: stopping at blame #

When a 'who' appears, you are only halfway

'The new hire made a mistake' can never be a root cause; if that person resigns tomorrow, the same incident still happens. When a name appears, turn the question back to structure: why did that mistake pass through the system? The blameless principle is not about kindness, it is about accuracy; the moment punishment is expected, information starts hiding from the next incident onward.

Trap 2: settling for the first answer #

The plausible answer is the most dangerous one

The first plausible answer is usually a restatement of the symptom or a hypothesis everyone already believed. Asking 'is another explanation possible?' once at each level deepens the chain by a full layer. Be especially suspicious when the answer arrives unanimously within five minutes of the meeting starting; consensus without verification is memory, not analysis.

Trap 3: linking without verification #

A chain of hypotheses always collapses

The answer to each why must be backed by one of: data, logs, or confirmation from the people involved. If even one is a guess, everything below it stands on sand. When an unverifiable answer comes up, pause the chain and verify first. Five Whys is not a ceremony that must finish within one meeting; it is an investigation that may take days between confirmations.

🌿When causes fork #

The chain becomes a tree

Real problems often have more than one cause. When a why yields two or more answers, do not force a single choice; split the chain per branch. But do not dig every branch to the same depth: dig the branch with the largest contribution first and leave the rest explicitly marked as deferred. The record of the fork itself becomes the map for the next similar incident.