System Archetypes in Delivery

---

Origins

System archetypes were catalogued by Peter Senge in The Fifth Discipline¹, drawing on the work of Jay Forrester and the System Dynamics field at MIT. The archetypes describe recurring structural patterns in social and technical systems that produce predictable, often counter-intuitive outcomes.

The patterns matter for delivery teams because most chronic problems in software organizations are instances of one or more of these archetypes. Teams that recognize the pattern can address the structure producing it; teams that don't keep trying the same fix and getting the same result.

Shifting the Burden

A symptom is addressed with a quick fix that works in the short term but obscures the deeper problem. Over time, the team becomes dependent on the quick fix, the underlying problem worsens, and the deep solution becomes harder to apply.

Delivery examples:

• Tests fail intermittently. Team retries the build until it passes (quick fix). The flaky test is never investigated; eventually the whole suite is unreliable.
• Incidents require manual operational intervention. Team gets good at the intervention (quick fix). Automation that would prevent the incident class is never built.
• Estimates are inaccurate. Team pads them (quick fix). The estimation skill never improves; teams become dependent on padding that grows over time.

The structural response: notice when the team is treating symptoms and invest in the underlying capability, even when the quick fix is working.

Fixes That Fail

A solution that works in the short term creates a worse problem in the long term. The original problem returns, often more severely, and the team applies the same fix again.

Delivery examples:

• To hit a deadline, the team cuts testing. The release ships on time; post-release defects consume the next two sprints; the next deadline is even tighter; testing gets cut again.
• To reduce on-call load, the team raises alert thresholds. Pages drop in the short term; missed incidents accumulate; one becomes a major outage; team responds by adding more alerts.
• To improve velocity, leadership adds more developers to the team. Onboarding overhead spikes; velocity drops further; leadership adds more people.

The structural response: trace the consequences of the fix forward several steps before committing to it. What new problems does this create?

Success to the Successful

Two parties or initiatives compete for limited resources. The one that gets early success gets more resources, which produces more success, which gets more resources. The loser is starved into permanent disadvantage regardless of underlying merit.

Delivery examples:

• Two teams own related services. One gets the better tooling allocation early. Its delivery accelerates, justifying further investment. The other team's tooling debt grows.
• Customer A produces fast revenue. Sales focuses on A's segment. Product follows. The system optimizes for A; potentially larger segment B is never developed.
• One developer becomes "the person who knows" a critical system. They're given more work on it. They learn it deeper. Nobody else gets access. The system becomes unmaintainable when they leave.

The structural response: deliberately invest in the underdog. Equal allocation in the face of unequal results is what prevents the runaway.

Tragedy of the Commons

A shared resource is consumed by multiple parties acting in their own interest. Each party rationally maximizes their use; collectively the resource is destroyed.

Delivery examples:

• CI/CD compute capacity is shared. Each team uses what they need. Build times grow for everyone as collective demand exceeds capacity.
• A shared codebase has shared technical debt. Each team takes shortcuts to ship their feature. Collective complexity grows until the codebase is hostile to all changes.
• An on-call rotation is shared across multiple services. Each team adds features to their service. Page volume crosses what the rotation can sustainably handle.

The structural response: explicit ownership, accountability for consumption, or governance of the shared resource. The default of "everyone is responsible" rarely works.

Limits to Growth

A growth process produces increasing results until it hits a constraint that isn't yet visible. Beyond that point, the same actions produce diminishing returns or active harm.

Delivery examples:

• Adding test coverage improves quality — until the test suite becomes so slow that developers stop running it, at which point coverage stops protecting quality.
• Adding monitoring improves visibility — until alert volume exceeds what the on-call can absorb, at which point monitoring produces ignored noise.
• Adding process improves consistency — until process overhead exceeds the value of consistency, at which point teams route around the process.

The structural response: notice when the growth curve is bending, and either remove the constraint or stop doing more of what's producing diminishing returns.

Drift to Low Performance

Performance gradually declines because the system slowly adjusts its standards to match its current performance, rather than measuring against its original goal.

Delivery examples:

• Deployment frequency drops over months. The team accepts the new normal. Eventually deploying becomes a monthly event the team dreads.
• Code review thoroughness erodes as the team grows. Reviewers approve faster to keep up. Defect rate rises; quality bar slides; the new normal becomes the standard.
• SLOs are missed. Targets are adjusted downward to "be realistic." The real performance never recovers because the team is now measuring against the degraded baseline.

The structural response: anchor measurements to historical or aspirational targets, not to current performance. Notice drift and name it explicitly.

How to Use the Archetypes

The archetypes are diagnostic tools. When the team encounters a recurring problem, work through them:

• Have we been applying quick fixes to a deeper problem? (Shifting the Burden)
• Did a past fix create the current situation? (Fixes That Fail)
• Is one team or initiative starving another? (Success to the Successful)
• Are we depleting a shared resource? (Tragedy of the Commons)
• Did this used to work and stopped? (Limits to Growth)
• Have we adjusted standards instead of improving? (Drift to Low Performance)

Naming the archetype usually reveals the structural intervention. The intervention is rarely doing more of what produced the problem — it is changing the structure that keeps producing it.

Coaching Tips

Match the Pattern Out Loud

When you spot an archetype, name it in the conversation. "This looks like Shifting the Burden — we're treating the symptom." Naming opens the path to structural fixes.

Trace Fixes Forward

Before committing to a fix, ask "what new problem does this create in three months?" Most Fixes That Fail are obvious in advance if you ask.

Watch the Drift

Performance metrics that slide quietly are how Drift to Low Performance happens. Anchor against original or aspirational targets, not current numbers.

Surface Shared-Resource Patterns

If multiple teams complain about the same shared thing, you're in Tragedy of the Commons. The fix is ownership and accountability, not better behavior.

Invest in the Underdog

If you spot Success to the Successful happening at the expense of something the org needs, allocate deliberately against the gravity of the pattern.

Don't Stop at Diagnosis

Recognizing the archetype is half the work. The other half is the structural intervention. Coaches who name patterns without naming what to change leave the team where it was.

Summary

Delivery teams encounter the same patterns over and over: workarounds that become dependencies, fixes that worsen what they tried to fix, runaway concentration of success or failure, shared resources degraded by uncoordinated use, growth that hits invisible ceilings, performance that slowly drifts away from intent. The patterns are predictable enough to have names.

Knowing the names doesn't solve the problems, but it dramatically shortens the diagnosis. A team that recognizes Shifting the Burden in its build-retry habit can start the right conversation immediately, rather than spending months trying ever-more-clever build retry strategies. The archetype is the doorway to the structural response.

Back to DevOps