Dr. Wallace’s Favorite Mental Models

Fixes That Fail

Learn it → Apply it → Save as Skill

A quick fix that relieves a problem right now can quietly grow a delayed side effect that makes the same problem worse later — pushing you to reach for the same fix again, at a higher cost each time. The relief is real and immediate. The consequence is real too, but it only shows up after a lag, so the two are rarely connected in anyone's mind.

Why This Library Is Different

Learn it. Apply it. Save as Skill.

The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.

Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.

30-Second Understanding
Quick relief now. Bigger problem later.

A problem symptom appears and someone applies a fast corrective action. The symptom drops — a genuine, visible win. But the fix also sets off a second, slower-moving effect that builds on itself and adds back onto the original problem. Because a delay separates the two, the connection is easy to miss, and the usual response is simply to apply the same fix again, harder.

Core question: Does this fix remove the root cause of the problem, or does it only relieve the symptom while a delayed side effect quietly grows underneath it?

The memorable shorthand

Relief
Buildup

Important: the fix genuinely works on the visible symptom — that part is not an illusion. The problem is what's happening in the other bar, quietly growing out of sight, until the delay runs out.

Mental Model Compass

Use it when the same problem keeps coming back despite repeated fixes.

The model is most useful when a corrective action produces fast, visible relief, but you suspect — or have seen before — that the relief doesn't last and the problem returns bigger.

DiagnosePrimary use case
IntermediateDifficulty
3 minUnderstand
15–30 minApply with data
Crisis & incident managementTechnical debtOrganizational changePublic policyHealth & habitsOperations & maintenance
Model at a Glance

Diagnose → Trace → Test → Treat.

This method tells you whether a recurring problem is being solved or just restocked. It does not by itself tell you what the fundamental solution should be.

01Diagnose

Name the symptom and the quick fix currently being used to relieve it, and who benefits from applying it.

02Trace

Follow the fix forward. What slower-building side effect does it feed, and roughly how long is the delay before that side effect becomes visible?

03Test

Check for the warning sign: is the same fix now needed more often, or in a larger dose, to produce the same relief?

04Treat

Decide whether to keep the fix only as a deliberate way to buy time, while building — and actually resourcing — a fundamental solution to the root cause.

When Should I Use This?

Recognize the situation.

Open a use case to see what the model changes.

Engineering & tech
A hotfix ships to beat a deadline

Patching the symptom — the crash, the failing test — under time pressure can quietly raise the system's overall defect rate and code complexity. Watch whether the same class of incident needs patching again within weeks, at a larger scope each time; that recurrence, not the individual patch, is the warning sign.

Organizational change
A "firefighter" keeps getting praised for saving the day

When whoever contains the latest crisis is rewarded and promoted, and whoever inherits the recurring problem later gets blamed, the organization is structurally reinforcing the fix instead of the root cause — sometimes called the hero–scapegoat cycle.

Public policy
A tax or rule is raised to close a budget or safety gap

Raising a targeted tax to close a shortfall can push the taxed activity into an untaxed channel — for example, smuggling — which quietly shrinks the very tax base the increase was meant to grow.

Health & habits
Reaching for caffeine, a painkiller or a drink to get through the day

Each dose relieves the immediate symptom — tiredness, pain, stress — right away. The underlying cause, whether a sleep deficit, an untreated injury or an unmanaged stressor, keeps building underneath the relief, often requiring a larger dose next time.

Agriculture & operations
A pest or fault keeps requiring a stronger treatment

Heavier fungicide or pesticide use can breed resistance in the target population, so each round requires a stronger dose than the last to achieve the same result — a textbook escalation signature.

Maintenance & budgeting
Deferred maintenance balances this quarter's budget

Skipping scheduled maintenance frees up cash immediately. The equipment keeps degrading in the background, and the eventual breakdown and repair bill usually costs far more than the maintenance would have.

Worked Example

Six quarters of the same "emergency patch."

This is an illustrative example designed to teach the method, not a disclosure of any real company's data.

Q1 — 40h
Q2 — 55h
Q3 — 68h
Q4 — 90h
Q5 — 120h
Q6 — 160h
SITUATIONA 40-person engineering team relies on hotfixes to keep production stable
MEASUREHours spent on emergency patches per quarter
CHART40, 55, 68, 90, 120, 160 hours across six quarters
COMPAREQuarter 1 = 40h · Quarter 6 = 160h — a 4x rise
INSIGHTEach patch still works; the dose needed to get relief keeps growing
NEXTFreeze one sprint for a root-cause fix instead of another patch
Notice the shape: the symptom drops right after every single patch — on a week-by-week chart, the fix always looks like it worked. It's only the quarter-over-quarter total that reveals the reinforcing loop hiding behind the balancing one.
History & Accuracy

A systems archetype, a causal loop, and an easy mix-up.

Expand for where the pattern comes from, how the loop is structured, and the archetype it's most often confused with.

Where does this systems archetype come from?

"Fixes that Fail" (also called "fixes that backfire") is one of the systems archetypes popularized by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization (Doubleday, 1990). The archetypes themselves grew out of the system dynamics field founded at MIT by Jay Forrester in the 1950s and 60s. Senge and colleagues working in organizational learning catalogued the recurring causal-loop patterns — including this one — into a shared vocabulary that later systems-thinking writers, including Daniel Kim, Robert Flood and William Braun, went on to extend and cross-reference.

What is the actual loop structure?

The archetype pairs two loops around one fix. A balancing loop (often labeled B1) connects the symptom to the fix: the symptom appears, the fix is applied, and the symptom drops. A reinforcing loop (often labeled R2) connects the same fix to an unintended consequence: the fix produces a side effect that builds on itself and feeds back into the original symptom. A delay sits between the fix and that consequence, which is why the two rarely get connected — by the time the consequence is visible, the fix already looks like a success story.

How is this different from the "Shifting the Burden" archetype?

The two are closely related and easy to conflate, but the structures differ. Fixes That Fail involves one quick fix whose own side effect eventually makes the original symptom worse. Shifting the Burden involves two competing responses — a quick fix and a more fundamental solution — where relying on the quick one actively erodes the capacity or motivation to pursue the fundamental one. Confusing the two matters in practice: the remedy for Fixes That Fail is to spot and interrupt the hidden side effect, while the remedy for Shifting the Burden is to protect the fundamental solution from being crowded out by the quicker one.

What documented examples does the systems-thinking literature actually use?

Commonly cited illustrations include: cutting maintenance spending to save money, which leads to more breakdowns and higher eventual cost; drilling deeper wells to fix a water shortage, which lowers the water table further; taking out a new loan to cover this period's interest, which generates more interest later; raising a targeted tax to close a shortfall, which can push the taxed activity into an untaxed channel such as smuggling and shrink the tax base; and heavier pesticide or fungicide use, which breeds resistance that then requires still heavier use. A related organizational pattern — sometimes called the hero-scapegoat cycle — describes a manager who is promoted for applying a fix, while a successor is later blamed when the same problem returns.

Common Mistakes

Easy to misread, easy to over-claim.

Confusing this with Shifting the Burden

Both archetypes involve a quick fix and a slower-building problem, but they aren't the same failure. Here there is only one fix, and its own side effect is what later worsens the symptom — treating the two archetypes as interchangeable can point you at the wrong remedy.

Treating symptom relief as proof the fix worked

The relief is real, but a delay separates the fix from its consequence. Early relief isn't evidence the fix resolved the root cause — only that it addressed the symptom, which this archetype never disputes.

Missing the escalation signature

The clearest fingerprint of this pattern is a rising dose: the same fix, applied again, now needs to be larger, more frequent or more drastic to produce the relief it once delivered easily.

Rewarding the fixer, blaming the inheritor

Promoting whoever contains this quarter's crisis, while blaming whoever has to deal with its return next quarter, structurally rewards continuing the fix and punishes anyone who tries to remove it.

Ignoring the delay and blaming something else

Because the side effect surfaces well after the fix, people reasonably but incorrectly blame something unrelated — a new hire, bad luck, an unrelated policy change — when the earlier fix was the actual cause.

Refusing to use any quick fix, ever

A quick fix used deliberately to buy time while a fundamental solution gets built is not the failure mode. The failure mode is leaning on the quick fix repeatedly as if it were the fundamental solution.

When Not to Use It

Not every fix is secretly this pattern.

Use another lens when...

the first fix actually removes the verified root cause and no delayed side effect has ever shown up or is plausible.

Use Shifting the Burden when...

two distinct solutions — one quick, one fundamental — are competing for attention and resources, and relying on the quick one is eroding capacity to pursue the fundamental one.

Use the Iceberg Model when...

you need to go deeper than one fix-and-consequence loop, into the underlying structures and mental models that keep generating this whole family of symptoms.

Counterpoint: a fix can look identical to this archetype and still be the right call, at least for now. The deliberate, time-bounded use of a quick fix while a fundamental solution is being built is not the failure mode this model warns against.
Combine It With

One model rarely does the whole job.

Try It Yourself

Build a fixes-that-fail diagnosis prompt.

This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.

Your AI-ready prompt

Complete the fields, then build your prompt.
Save as Skill

Turn this mental model into a reusable AI skill.

Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Fixes That Fail, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.

Build your own Mental Models Skills Library

Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.

Go Deeper

For readers who want the nuance.

Is this the same as "firefighting culture"?

"Firefighting" is the colloquial name many engineering and operations teams use for living inside this archetype: always reacting to the latest symptom, never finding time for the fundamental fix. The systems-archetype name is more precise because it specifies the actual causal structure — a balancing loop plus a delayed reinforcing loop — rather than just describing the feeling of being busy.

Can a fix "fail" and still be the right call?

Yes. A quick fix is often the only responsible option in the moment: stabilizing a system, stopping a loss, keeping a promise to a customer. It "fails" in the archetype's sense only when it is relied on repeatedly as a substitute for the fundamental solution, not when it is used once, deliberately, to buy time.

Why does the delay matter so much?

If the side effect showed up immediately, most people would connect it to the fix and stop repeating it. The delay is what makes the pattern durable: by the time the consequence is visible, enough time and other events have passed that the fix rarely gets blamed for it.