Shifting the Burden

Description

The archetype "Shifting the Burden" is the classic addiction metaphor in architecture. A system suffers. The actors can choose between a painful, long-running root treatment, the fundamental solution, and a convenient painkiller that works immediately, the symptomatic solution. Most people choose the pill because it provides instant relief. The devilish part is that the more often the pill is taken, the more motivation and capacity for the real solution collapse.

Feedback Loops

The system is split into three loops. The two upper loops are competing balancing loops.

Upper loop, symptom treatment: The symptom appears, a bandage is applied, the symptom disappears. It is an immediate reward loop.

Lower loop, fundamental solution: The symptom appears, deep architectural work begins, and after a delay the problem is solved. It is a hard, punishing loop.

Killing loop, side effect: A hidden reinforcing loop branches off the symptom treatment. Every quick fix further reduces the system's capacity for the fundamental solution. The organization forgets the craft and becomes addicted to symptom relief.

Architecture Example

A monolithic database performs terribly on complex joins. The fundamental solution would be a refactoring of the read and write models, for example along CQRS lines. That takes months and demands abstract design work. Instead the team chooses the quick fix: just add more CPU and RAM and put a huge Redis cache in front of it. Latency improves immediately. Half a year later the problem returns. Instead of finally fixing the design, the team scales hardware into the stratosphere because it has completely forgotten how its own legacy database model actually works.

Organizational Example

A project manager realizes that feature requirements are reaching developers in a way that is far too vague because domain expertise is missing. This causes hundreds of rework loops. Instead of training developers deeply in domain-driven design, the PM team builds the quick fix: an army of business analysts, proxies, and translators between the business and engineering. Communication feels smoother in the short term. In the long term, developers become emotionally detached from the business. Without the translators, no feature can be built anymore.

Diagnostic Questions

1.Where are we reflexively solving scaling problems with excessive cloud spending through autoscalers and hardware overprovisioning because nobody dares touch the code?

2.Where are we outsourcing core system intelligence, business logic, into opaque low-code or plug-and-play SaaS products whose failure would create a total black-box disaster?

3.Which provisional workarounds, such as manual cron-based database cleanups, have been running quietly for more than two years while nobody knows how to remove them?

Diagram

How to Recognize the Pattern in Daily Work

The fatal property of this network is the slow bleeding out of resilience. The system's pain threshold becomes numbed by the pills. If the quick fix eventually fails after years, because Redis can no longer hold terabytes, the fundamental burden slams back into the organization with such force that the company can fail. Architects have to learn that a perfectly masked application is not a quality signal. It is a hidden bomb of toxic debt.

What Distinguishes the Pattern from Similar Dynamics

Unlike *Fixes That Fail*, where the fix actively creates a poisonous side effect that directly worsens the core problem, *Shifting the Burden* works passively. The fix does not itself create the error. It simply makes the system blind and deaf to reality by killing the only chance for genuine learning and structural change.

How to Move from Pattern to Response

Acknowledge the human reality: organizations need short-term fixes to keep breathing. The crucial step is not abolishing every fix, but creating forced coupling. Any permission to deploy a symptom fix must be tied immediately and irreversibly to a parallel implementation of the fundamental solution. You may turn the database autoscaler up a few notches only if the CTO also approves the capacity needed to ship the query optimization in the same decision cycle.

First Next Steps

Understand that withdrawal from an addiction hurts enormously. If teams are used to throwing quality assurance, refactoring, or testing out the window whenever stress rises, then you have to lead them firmly through the discomfort of relearning. No, you do not deploy without tests, even if the deadline slips.

How to Recognize the Pattern with Confidence

Do our IT budgets and ticket systems clearly separate spending on operational tape and bandages from engineering work on fundamental refactoring so that we can see how strong our painkiller addiction has already become?

Sources

The Systems Thinker: Shifting the Burden

Peter Senge - The Fifth Discipline, ch. 6: Shifting the Burden

Wikipedia: System Archetypes - Shifting the Burden