Recognizing Recurring Structures
You do not need to map every system from scratch. Researchers have identified recurring patterns — called System Archetypes — that appear across industries, organizations, and technologies. Learning to recognize these archetypes lets you diagnose problems faster and avoid known traps.
Archetype 1: Fixes That Fail
A quick fix addresses a symptom but creates a side effect that makes the original problem worse over time.
- Structure: Problem → Quick Fix → Symptom improves (Balancing Loop). But Quick Fix → Side Effect (with delay) → Problem gets worse (Reinforcing Loop).
- Example: A service is slow → You add a caching layer (quick fix) → Response times improve immediately. But the cache introduces stale data bugs → Users report incorrect data → Engineers add cache invalidation logic → The invalidation logic adds complexity and latency → The service is slow again, but now it is also more complex and harder to debug.
- The Tell: The same problem keeps coming back, and each time it is harder to fix.
Archetype 2: Shifting the Burden
A symptomatic solution is used instead of a fundamental solution. Over time, the symptomatic solution weakens the organization's ability to apply the fundamental solution.
- Structure: Problem → Symptomatic Solution (easy, fast) → Problem temporarily improves. Meanwhile, Problem → Fundamental Solution (hard, slow) is neglected. Over time, reliance on the symptomatic solution atrophies the capability needed for the fundamental one.
- Example: Deployments keep breaking → You add a manual approval gate (symptomatic solution) → Fewer broken deployments. But the fundamental solution (better automated testing, smaller changes, canary deployments) is never built because "the approval gate works." Over time, the team loses the skills and confidence to deploy without manual approval, and the gate becomes a permanent bottleneck.
- The Tell: You have a workaround that everyone knows is temporary, but it has been in place for years.
Archetype 3: Limits to Growth
A reinforcing loop drives growth, but eventually hits a constraint that slows or stops it.
- Structure: Reinforcing Loop drives growth → Growth hits a Balancing Loop (the constraint) → Growth stalls or reverses.
- Example: A microservices team ships features rapidly (reinforcing loop: small services → fast iteration → more features → more services). But eventually, the number of services overwhelms the team's ability to operate them (balancing loop: operational overhead). Feature velocity plateaus and then drops as the team spends more time firefighting than building.
- The Tell: Something that used to work brilliantly has stopped working, and "doing more of it" does not help.
Key Point: When diagnosing a system problem, try fitting it to a known archetype before building a custom model. Archetypes give you a head start: each one has a known set of leverage points and known interventions that work (and known interventions that make things worse). "Fixes That Fail" is resolved by addressing the root cause instead of the symptom. "Shifting the Burden" is resolved by investing in the fundamental solution before the symptomatic one atrophies your capability. "Limits to Growth" is resolved by identifying and removing the constraint — not by pushing harder on the reinforcing loop.