Foundation #12

Symptoms vs Root Causes

Fixing the thing you noticed isn't the same as fixing the thing that caused it. Most "fixes" never get past the first one.

7 min read Deadband Life 2026
A stranded driver stands beside a smoking car with the hood open while the deeper mechanical failure is visible inside the engine compartment.
The thing that breaks is rarely the thing that caused the failure.

You missed a credit card payment again. This is the third time this year. You set up an automatic reminder after the first time. After the second time, you moved the due date to align with payday. And here you are again, a late fee on the statement, telling yourself you just need to be more careful next month.

You will not be more careful next month, because "be more careful" was never the actual fix — it was a description of the symptom dressed up as a solution. You fixed the reminder. You fixed the due date. You have now fixed two things that were never the actual problem, twice, and the actual problem is still sitting there, waiting to produce a fourth late fee.

The Root Cause: Treating the Visible Thing as the Real Thing

ROOT CAUSE: No feedback loop

A symptom is what you notice. A root cause is what's actually producing it. These are almost never the same thing, and the entire reason most personal fixes don't hold is that they target the symptom — the thing that was visible enough to annoy you — while leaving the actual mechanism untouched and fully capable of producing the next symptom right on schedule.

The missed payment is a symptom. So is the low balance the week before payday. So is the vague feeling that money "just disappears." None of these are the problem. They are evidence that a problem exists somewhere upstream, and the job of root cause analysis is to walk backward from the evidence until you reach the actual mechanism — not stop at the first explanation that's convenient or close enough to act on.

The Mechanism: The Five Whys

Root cause analysis has a formal lineage in quality engineering, where the cost of fixing the wrong thing is measured in recalled products and failed audits, not just late fees. One of the simplest and most durable tools from that discipline is the Five Whys: starting from a visible symptom and asking "why did that happen" repeatedly, using each answer as the input for the next question, until the chain stops at something you can actually act on

.

The method isn't magic. It's just a refusal to stop asking after the first plausible-sounding answer, which is exactly where most personal problem-solving stops.

Here's what that chain actually looks like applied to the missed payment, instead of stopping at "I forgot":

Why 1: Why was the payment missed? — The balance in checking was lower than expected that week.
Why 2: Why was the balance lower than expected? — A $200 expense came in that hadn't been planned for.
Why 3: Why wasn't that expense planned for? — There's no list of irregular, non-monthly expenses tracked anywhere.
Why 4: Why isn't there a list like that? — The budget only tracks fixed monthly bills, not irregular costs.
Why 5 — ROOT CAUSE: No system exists for irregular, non-monthly expenses — so they always arrive as unplanned shocks to the checking account, regardless of how the due date or reminder is set up.

Notice what didn't show up anywhere in that chain: forgetfulness, carelessness, or a character flaw. The actual root cause is a missing category in the budget design — something a better reminder system was never going to touch, no matter how many times it got rebuilt.

The Design: Fix the Bottom of the Chain, Not the Top

Once the chain reaches an answer you can't meaningfully ask "why" about again — something structural, not circumstantial — that's your root cause, and that's where the fix belongs. In the example above, the fix isn't a better reminder. It's adding an irregular-expenses category to the budget, with a small buffer sized to the kind of $100–$300 surprise that keeps showing up.

INPUT
A symptom: missed payment, low balance, recurring frustration
→
PROCESS
Ask "why" repeatedly until the answer is structural, not circumstantial
→
OUTPUT
A fix at the root, not a patch on the symptom

This is also the test for whether you actually found the root cause or just got tired of asking: if the fix is applied and the symptom comes back in a different costume next month, the chain stopped one level too early. A real root cause, once addressed, makes the entire category of symptom stop recurring — not just the specific instance you happened to notice this time.

Your Next 24 Hours

Run a Symptom Trace

Pick one recurring frustration you've "fixed" more than once without it actually going away. Open a blank document and write "Why did this happen?" five times, each time using your previous answer as the next question, until you land on something structural rather than circumstantial.