Shifting the Burden

Description

The archetype "Shifting the Burden" describes a dynamic in which a system is repeatedly relieved symptomatically while the fundamental solution is neglected. The fast measure produces an immediately visible effect, for example more hardware, a workaround, or an external tool. The structural solution is slower, more demanding, and often harder organizationally. The more often the symptomatic treatment is used, the less motivation and capability remain for the fundamental solution.

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 quick fix is applied, and the symptom disappears. This creates an immediate reward loop.

Lower loop, fundamental solution: The symptom appears, structural analysis begins, and after a delay the problem is solved more durably. This loop is slower, but builds real problem-solving capability.

Side-effect loop: A hidden reinforcing loop branches off the symptom treatment. Every quick fix further reduces capacity for the fundamental solution. The system becomes dependent on the symptom fix.

Architecture Example

A monolithic database becomes slow on complex joins. The fundamental solution would be a refactoring of the read and write models, for example toward CQRS. That takes months and requires deeper architectural understanding. Instead, the team first adds more CPU, more RAM, and a Redis cache. Latency improves in the short term. When the problem returns later, more hardware is added again while understanding of the actual legacy data model continues to decline.

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 problematic property of this pattern is the loss of resilience. Symptom treatment hides how large the underlying structural burden has become. When the quick fix later no longer works, the original problem returns with much greater scope. An application that appears stable only because of workarounds is therefore not a quality signal, but an indication of hidden follow-on costs.

What Distinguishes the Pattern from Similar Dynamics

Unlike Fixes That Fail, where the fix actively creates a harmful side effect that directly worsens the core problem, Shifting the Burden works more passively. The fix does not necessarily create the error itself. It reduces the system's ability to notice reality and invest in learning and structural change.

How to Move from Pattern to Response

Acknowledge the human reality: organizations sometimes need short-term fixes to remain operational. The crucial step is not abolishing every fix, but coupling symptom treatment to structural work. Any decision to deploy a symptom fix should also create capacity, ownership, and a delivery path for the fundamental solution. Raising the database autoscaler can be legitimate if the same decision also reserves time for query optimization or model refactoring.

First Next Steps

Make clear that returning to the fundamental solution may initially feel slower. If teams are used to reducing quality assurance, refactoring, or testing under pressure, they need binding guardrails: no deployment without tests, visible technical follow-on work, and planned capacity for structural engineering.

How to Recognize the Pattern with Confidence

Do our budgets and ticket systems clearly distinguish symptom treatment from structural engineering, so we can see how much capacity goes into real problem solving?

Sources

The Systems Thinker: Shifting the Burden

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

Wikipedia: System Archetypes - Shifting the Burden