The 90-second problem that lasted hours A few weeks ago, a power outage lasting 90 seconds caused rail chaos across parts of the UK. Ninety seconds. The disruption lasted hours. This is what cascading failure looks like. One thing breaks. Then another. Then another. By the time you are dealing with the third or fourth problem, you have lost sight of what actually started it all. I see this constantly with people running their own thing. A supplier misses a deadline by two days. That delays your delivery. The delayed delivery triggers a refund request. The refund request creates a cash flow gap. The cash flow gap means you cannot pay for the next batch of materials. Now you are three weeks behind on everything. The original problem? A two-day delay. The actual damage? Three weeks of chaos. This is where 5 Whys becomes essential. But most people use it wrong when failures cascade. Why standard 5 Whys fails on chain reactions The classic 5 Whys method works well for isolated problems. Something broke. Ask why five times. Find the root cause. Fix it. But cascading failures are different. You are not dealing with one problem. You are dealing with a sequence of connected problems, each with its own cause. The mistake I see most often: people start their 5 Whys at the wrong point. They begin with the latest symptom, the thing currently on fire, and work backwards. This feels logical. It is not. When you start at the end of a cascade, you often end up with root causes that are actually just earlier symptoms. You fix something. The cascade happens again next month because you never found the actual trigger. Start at the origin, not the outcome The first step is identifying where the cascade began. Not where you noticed it. Where it started. This requires honesty. Often the origin point is something we dismissed as minor at the time. A small delay. A skipped check. An assumption that turned out to be wrong. I worked with someone in London last year whose business had a recurring problem: every few months, they would have a week where nothing worked. Orders wrong. Team frustrated. Customers complaining. Each time, they fixed the immediate fires and moved on. When we mapped out the last three incidents, we found they all started the same way: a key team member took leave, and their backup process did not exist. Every single cascade traced back to one person being unavailable and no one knowing how to cover their tasks. The visible problems were different each time. The origin was identical. Run parallel 5 Whys, then look for the intersection Here is the technique that actually works on cascading failures. First, identify each major failure point in the cascade. Not every small thing, but the moments where the situation got significantly worse. Then run a separate 5 Whys on each one. Treat them as independent problems initially. Finally, look for where the chains intersect. You are searching for the point where multiple 5 Whys sequences converge on the same underlying issue. This is where you find the real root cause. Not the thing that broke first. The thing that made everything else fragile enough to break in sequence. I have seen this reveal surprising things. One business owner discovered that 73% of their cascading problems traced back to one thing: they had no documented process for handling exceptions. Every time something unusual happened, someone improvised. Sometimes the improvisation worked. Sometimes it triggered a chain reaction. Document the cascade, not just the cause Once you have found the root cause, do not stop there. Map the entire cascade. Write down how problem A led to problem B led to problem C. Be specific about the time gaps between each stage. This matters because cascading failures can often be interrupted. Even if you cannot prevent the initial trigger, you can sometimes stop the chain reaction at stage two or three. In the rail example, the power outage itself might be unavoidable. But the question becomes: why did 90 seconds of lost power create hours of disruption? What failed to recover? What backup did not activate? Where could the cascade have been stopped? These are the questions that lead to useful answers. Build circuit breakers into your operations Electrical systems have circuit breakers for exactly this reason. When something goes wrong, the breaker trips and prevents the failure from spreading. Your business needs the same thing. Once you have mapped a cascade, ask: where could we have inserted a stop? Maybe it is a 24-hour buffer between dependent processes. Maybe it is a rule that certain decisions require a second check. Maybe it is keeping a small reserve fund that exists purely to absorb unexpected costs without triggering cash flow problems elsewhere. The goal is not to prevent all failures. That is impossible. The goal is to prevent single failures from becoming systemic ones. What to do this week Monday or Tuesday: Think about the last time something small in your business triggered a bigger mess. Write down the sequence. What happened first? What did that cause? Keep going until you reach the final impact. This is your cascade map. Wednesday or Thursday: Run 5 Whys on the origin point, not the final symptom. If you want a structured way to do this, there is a 5 Whys tool at alira.london that walks you through it properly. The point is to find what made the first domino fall. By Friday: Identify one circuit breaker you could install. One buffer, one check, one backup that would have stopped the cascade at stage two or three. Put it in place before you forget. Single failures are manageable. Cascading failures cost you weeks. The difference is whether you have thought about the chain reaction before it happens.