Closing the Loop: Why Fires Keep Coming Back
There's a visible loop and a hidden loop. Everyone closes the visible one. No one has time to close the hidden one.
Situation
10 tickets in the queue. PM chasing. Lead chasing. Fix this one, move to next.
Complication
We refined the process. Added SOPs. Shorter standups. Clearer priorities. Better tools.
And still — the team looks tired. Urgent issues every day. Same patterns. Same fires.
A few years into building this product, we’ve optimized everything we could think of. And nothing changes.
Question
Why is the team still exhausted after years of refinement? What are we missing?
Answer
There’s a visible loop — ticket comes in, you fix it, you close it. Everyone lives here.
Then there’s a hidden loop — the system keeps producing the same tickets. The same bugs come back. The same gaps reappear.
Closing the visible loop is necessary. But it’s not enough.
A closed loop has two layers:
- Learn from the mistake — not just fix it, understand why it happened
- Fix the system — not just this ticket, fix the pattern that produces the next one
The step people skip: asking why. Why does this keep coming back? What’s actually broken?
Five Whys
What it is: An iterative technique from Taiichi Ohno at Toyota. You ask “why” five times, each time directing the next “why” at the answer of the previous one.
Why five? Not a magic number. You stop when the answer points to a broken process, not a broken person. If your fifth why still blames an individual instead of a system — you’ve gone wrong somewhere.
The discomfort point: The fifth why often gets uncomfortable. It usually reveals something the team or org is doing — or not doing. That’s the real root cause. Most people stop at “why it broke” and miss “why the system let it break.”
When to use it: For recurring problems with a clear cause-and-effect chain. If the problem has multiple contributors, use fishbone instead.
Five Whys — Real Example
Why is there always an accounting gap between the provider and us? Because we missed implementing a special logic for this provider.
Why did we miss it? Because we only focused on that specific case — ticket says X, we do X, we close it.
Why don’t we scan for similar or adjacent cases before implementation? Because there’s no process for it. We fix what’s reported. We don’t look for what’s not reported yet.
Why is there no scanning process? Because everyone is busy closing the visible loop. No one has time to look at the pattern.
Why can’t anyone find the time? Because the team is always firefighting. Closing the hidden loop is a luxury when ten tickets are waiting.
The fifth why is the real answer: the process rewards speed of closing tickets, not thoroughness of fixing the system.
Fishbone Diagram (Ishikawa)
What it is: A cause-and-effect diagram created by Kaoru Ishikawa at Kawasaki shipyards in the 1960s. One of the Seven Basic Tools of Quality.
The shape: Head on the RIGHT, causes on the LEFT. The spine runs left-to-right — causes contribute to effect.
Head orientation:
- Head on RIGHT (standard) — for root cause analysis. You have a problem and want to find what caused it.
- Some teams reverse the layout for presentation, but the method is still the same: map causes contributing to an effect.
For our post, we’re using the standard (head RIGHT) because we’re doing root cause analysis.
The 6Ms — categories for causes:
- Man/People — Skills, knowledge, fatigue, capacity
- Machine — Tools, systems, automation
- Material — Inputs, data, dependencies
- Method — Process, SOPs, workflows
- Measurement — Metrics, what gets tracked
- Environment — Conditions, context, pressure
Not every category applies. Pick the ones relevant to your problem.
When to use it: When root cause isn’t obvious. When multiple factors contribute. When Five Whys keeps circling back to the same answer without actionable insight.
Fishbone Diagram — Our Situation
For the accounting gap between the provider and us, only two categories matter:
People — knowledge is siloed. One person knows the provider logic. That person leaves or is busy, the gap appears.
Method — no systematic scan before building. We handle cases one by one. We close tickets, not systems.
The fix isn’t a fix — it’s a system change.
Document the logic. Cross-train. Add a “potential cases” check before implementation.
Closing
“We got good at fighting fires. We forgot to ask why the wood was always dry.”