Fix the Symptom or the System Behind It (Decision Tree)
Why this matters
Something just went wrong on a job. A part was missing, an appointment got blown, a customer got a bill they did not expect. You can fix the thing in front of you, the symptom, and move on. Or you can fix the system that produced it so it cannot happen the same way again. Do the first every time and you will fix the same problem for the rest of your career. Do the second on everything and you will over-engineer a shop into paralysis. This tree tells you which one a given problem earns.
Safety first: if the symptom is a live hazard, make it safe before anything else
If the thing that went wrong is an active danger, an energized part, a gas smell, a customer or crew member at risk, stop and remove the hazard first. De-energize and verify dead, evacuate, relieve pressure, whatever the situation demands. The system-versus-symptom decision is a management call you make afterward, never a reason to leave a hazard live while you think. (See related: Is This Safe to Leave Running.)
Start here: contain the symptom now, decide about the system later
These are not either-or in the moment. Almost always you fix the symptom immediately, because a customer is waiting and the harm is real right now: drive the part out, apologize, re-cut the invoice. Do that. The real decision is what happens after the customer is taken care of, when you choose whether the system behind it is worth changing. Containing the symptom buys you the time to make that call with a clear head, not in a panic.
The three triggers: does the system earn a fix?
A symptom fix is the right final answer more often than improvement zealots admit. The system behind it earns a real fix when any one of these three is strong. You are not looking for all three; one is enough.
- Recurrence. How likely is this to happen again? A problem baked into a step you run every day will absolutely return. A freak combination of events may never repeat. If you have already seen this more than once, recurrence is settled, go fix the system. (See related: The Recurring Firefight: Root Cause vs Bandaid.)
- Severity if it recurs. How bad is it when it happens? A rare problem that risks an injury, a lost customer, or a safety event earns a system fix on the very first occurrence. Do not wait for the pattern when the pattern could be a disaster.
- Blast radius. How many does it affect? A problem that can only ever hit one customer is smaller than the same problem sitting in a step that touches every job you book. Width matters as much as frequency.
If all three are low, a rare, minor, contained one-off, containing the symptom is the correct final answer. Building a system around it is waste. If any one is high, the system behind it is worth your time.
Then pick the right level to fix
"The system behind it" is not one thing. It sits at levels, and fixing at the wrong level is why fixes fail. Walk up only as far as the cause actually lives:
- The instance. This one job. Fix it and stop, if the triggers are low.
- The step. The specific task that failed: a missing checklist line, an unclear form field.
- The handoff. Where the job passed between people and information dropped: office to tech, sales to install.
- The workflow. The whole sequence is wrong or out of order.
- The structural cause. Staffing, scheduling load, or incentives that make the failure almost inevitable no matter who is doing the work.
Fix too shallow and the problem returns from the level above. Fix too deep and you rebuild a workflow when a single checklist line would have held. Find the lowest level that fully explains the failure, and change that.
Symptom fix vs system fix at a glance
| Symptom fix | System fix | |
|---|---|---|
| What it does | Resolves this instance | Changes the process so it cannot fail the same way |
| Cost now | Small, immediate | Larger, up front |
| Cost later | Paid again every recurrence | Paid once |
| Right when | Rare, minor, contained | Any trigger is high: recurs, severe, or wide |
| Risk | The same fire, forever | Over-engineering a one-off |
The recap
- Hazard? Make it safe first.
- Contain the symptom now so the customer is handled.
- Score the three triggers: recurrence, severity, blast radius.
- All low: the symptom fix is done, move on without guilt.
- Any high: fix the system, at the lowest level that explains the failure.
The judgment to bank: containing the symptom is never wrong, but calling it a system fix when it was only a patch is how a shop stays stuck.
References
- Plan-Do-Check-Act improvement cycle and root-cause practice, standard continuous-improvement method
- See related: The Recurring Firefight: Root Cause vs Bandaid Decision Tree; Getting to Root Cause Instead of Blaming the Person
- Trade-standard practice for operational problem-solving