# Systems Archetypes Reference ## Overview **System archetypes are recurring structural patterns that produce characteristic behaviors.** Recognizing the archetype reveals the intervention strategy - you don't need to re-solve the problem, you can apply known solutions. **Core principle:** Systems are governed by archetypal structures. The same 10 patterns appear across domains. Once you recognize the pattern, you know how to intervene. **Required foundation:** Understanding of feedback loops, stocks/flows, and leverage points. See recognizing-system-patterns and leverage-points-mastery skills. ## The 10 System Archetypes Quick reference table - detailed explanations follow: | Archetype | Signature Pattern | Primary Loop | Key Intervention | |-----------|-------------------|--------------|------------------| | 1. Fixes that Fail | Solution works temporarily, then problem returns worse | Reinforcing (symptom relief → side effect → worse problem) | Address root cause, not symptom | | 2. Shifting the Burden | Symptom relief prevents fundamental solution | Balancing (quick fix) overpowers balancing (real fix) | Make quick fix difficult or undesirable | | 3. Escalation | Two parties each escalate responses to each other | Reinforcing (A→B→A) | Unilateral de-escalation or shared goal | | 4. Success to the Successful | Winner gets more resources, creates brittleness | Reinforcing (success → resources → more success) | Level the playing field or diversify | | 5. Tragedy of the Commons | Individual optimization degrades shared resource | Reinforcing (individual gain → commons depletion → less for all) | Regulate commons or create feedback | | 6. Accidental Adversaries | Well-intentioned actions hurt each other | Reinforcing (A helps self, hurts B; B helps self, hurts A) | Align incentives or coordinate | | 7. Drifting Goals | Standards erode gradually from complacency | Balancing (gap → lower standard rather than improve) | Make gap visible, fix standards | | 8. Limits to Growth | Growth slows despite effort, hits ceiling | Balancing (growth → constraint → slow growth) | Remove constraint or shift focus | | 9. Growth and Underinvestment | Growth creates need for capacity, underfunded | Reinforcing (growth → insufficient capacity → quality drops → growth slows) | Invest ahead of demand | | 10. Eroding Goals (Pessimistic) | Standards lower in response to performance pressure | Reinforcing (pressure → lower standards → worse performance → more pressure) | Break cycle, re-establish standards | ## 1. Fixes that Fail ### Structure ``` Problem Symptom ↓ Quick Fix Applied ↓ Symptom Relieved (temporarily) ↓ Unintended Side Effect ↓ Problem Returns Worse ↓ Apply More of Same Fix ↓ [REINFORCING LOOP - Gets Worse Over Time] ``` **Causal Loop Diagram:** ``` Problem --+--> Quick Fix --+--> Symptom Relief ^ | | ↓ +------o----- Unintended Side Effect (delay) R: Fix amplifies problem via side effects ``` ### Software Engineering Examples **Database Performance** - Problem: Slow queries - Fix: Add indexes - Works temporarily: Queries faster - Side effect: Data grows, indexes can't keep up, worse than before - Root cause unaddressed: Unbounded data growth, no archival **Alert Fatigue** - Problem: Missing incidents - Fix: Add more alerts - Works temporarily: Catch more issues - Side effect: Alert fatigue, engineers ignore alerts - Root cause unaddressed: Incident rate, system reliability **Hiring for Velocity** - Problem: Team too slow - Fix: Hire more engineers - Works temporarily: More hands - Side effect: Onboarding burden, communication overhead, slower overall - Root cause unaddressed: Process inefficiency, tech debt ### Diagnostic Questions - Does the solution work at first, then stop working? - Are you applying more of the same solution repeatedly? - Is there a delay between fix and side effect appearing? - Are side effects making the original problem worse? **If YES to these:** Likely Fixes that Fail ### Intervention Strategy **Level 3 (Goals):** Change goal from "relieve symptom" to "solve root cause" **Level 6 (Information):** Make side effects visible early (before they dominate) **Level 5 (Rules):** Prohibit applying the same fix more than twice without root cause analysis **What NOT to do:** - ❌ Apply more of the failing fix - ❌ Ignore the side effects as "unrelated" - ❌ Speed up the fix (makes side effects appear faster) **What to DO:** - ✅ Identify the root cause being masked - ✅ Trace the path from fix → side effect → worsened problem - ✅ Solve root cause OR accept living with symptom ## 2. Shifting the Burden ### Structure ``` Problem Symptom ↓ ┌─────────Quick Fix (Path A) │ ↓ │ Symptom Relieved │ ↓ │ Side Effect: Fundamental │ Solution Never Pursued │ ↓ └── Problem Returns → Quick Fix Again Fundamental Solution (Path B) ← Never taken ``` **Key difference from Fixes that Fail:** Two pathways compete - symptom relief vs. fundamental solution. Quick fix actively prevents fundamental solution by reducing pressure. ### Software Engineering Examples **QA Team vs. Quality Culture** - Symptom: Bugs in production - Quick fix: Add QA team to catch bugs - Fundamental: Teams build quality in - Burden shift: Dev teams never learn quality practices, depend on QA - Result: QA becomes bottleneck, teams can't ship without them **Outsourcing vs. Skill Building** - Symptom: Team lacks skill X - Quick fix: Outsource or hire contractor - Fundamental: Train existing team - Burden shift: Team never gains capability, permanent dependency - Result: Can't maintain what contractors build **Framework vs. Understanding** - Symptom: Complex problem - Quick fix: Import framework/library - Fundamental: Understand and solve directly - Burden shift: Team never learns underlying concepts - Result: Can't debug framework issues, framework lock-in ### Diagnostic Questions - Is there a "quick fix" and a "fundamental solution" to the same problem? - Does the quick fix reduce pressure to pursue fundamental solution? - Is the team becoming dependent on the quick fix? - Does the quick fix have ongoing costs (time, money, capability drain)? **If YES:** Likely Shifting the Burden ### Intervention Strategy **Level 5 (Rules):** Make quick fix expensive or inconvenient (force fundamental solution) **Level 6 (Information):** Track total cost of quick fix over time, make dependency visible **Level 3 (Goals):** Prioritize capability building over symptom relief **What NOT to do:** - ❌ Make quick fix easier/cheaper (strengthens burden shift) - ❌ Remove fundamental solution resources (makes shift permanent) - ❌ Accept "this is just how we work" (normalization of dependency) **What to DO:** - ✅ Simultaneously apply quick fix AND start fundamental solution - ✅ Set sunset date for quick fix - ✅ Measure capability growth, not just symptom relief ## 3. Escalation ### Structure ``` Party A's Action --+--> Threat to Party B ↓ Party B's Response --+--> Threat to Party A ↓ ↓ More Aggressive Response (loop continues) ↓ [REINFORCING LOOP - Accelerating Conflict] ``` **Characteristic:** Both parties think they're being defensive, both are actually escalating. ### Software Engineering Examples **Tech Debt vs. Feature Pressure** - Party A (Management): Pressure to ship features faster - Party B (Engineering): Take shortcuts, accumulate debt - Escalation: Debt → slower velocity → more pressure → more shortcuts → more debt - Result: Velocity approaches zero, both sides blame each other **Security vs. Usability** - Party A (Security): Add restrictions (2FA, password policies, access controls) - Party B (Users): Find workarounds (shared passwords, written down, disabled 2FA) - Escalation: Workarounds → more restrictions → more creative workarounds - Result: Security theater, actual security compromised **Performance Team vs. Feature Team** - Party A (Features): Add features that slow system - Party B (Performance): Add rules/gates that slow feature delivery - Escalation: Slower features → pressure to bypass gates → worse performance → stricter gates - Result: Gridlock, both teams frustrated ### Diagnostic Questions - Are two parties each making the other's problem worse? - Does each side think they're being defensive/reasonable? - Is the conflict intensifying despite both sides "trying harder"? - Would unilateral de-escalation feel like "giving up"? **If YES:** Likely Escalation ### Intervention Strategy **Level 3 (Goals):** Create shared goal that supersedes individual goals **Level 6 (Information):** Make each party's actions visible to the other (break assumptions) **Level 2 (Paradigm):** Shift from "zero-sum" to "collaborative" mindset **What NOT to do:** - ❌ Escalate further ("fight fire with fire") - ❌ Blame one party (both are trapped in system) - ❌ Split the difference (doesn't break the loop) **What to DO:** - ✅ Unilateral de-escalation by one party (breaks cycle) - ✅ Create joint accountability (merge teams, shared metrics) - ✅ Make escalation cost visible to both parties ## 4. Success to the Successful ### Structure ``` Team A's Success --+--> More Resources to Team A ↓ Team A More Successful ↓ Even More Resources to Team A Team B Struggles ---o-> Fewer Resources to Team B ↓ Team B Struggles More ↓ Even Fewer Resources [REINFORCING LOOP - Rich Get Richer, Poor Get Poorer] ``` **Result:** Concentration risk - over-dependence on "winner" ### Software Engineering Examples **Enterprise vs. SMB Product** - Winner: Enterprise team (big deals) - Gets: Custom features, eng resources, exec attention - Result: 90% revenue from 5 customers, SMB product dies - Risk: One enterprise customer leaves = company crisis **Popular Service Gets Resources** - Winner: Service A (high traffic) - Gets: More engineers, better infra, attention - Result: Service A dominates, Service B atrophies - Risk: Service B fails, takes down Service A (hidden dependency) **Star Developer Effect** - Winner: Senior dev who delivers fast - Gets: Best projects, promotions, resources - Result: Junior devs never get growth opportunities, team dependent on one person - Risk: Star leaves = team collapses ### Diagnostic Questions - Is one team/project/person getting disproportionate resources? - Is the gap between "winner" and "loser" widening? - Is the organization becoming dependent on the winner? - Would the loser's failure create cascading problems? **If YES:** Likely Success to the Successful ### Intervention Strategy **Level 5 (Rules):** Resource allocation must consider portfolio balance, not just current ROI **Level 6 (Information):** Make concentration risk visible (dependency graphs, customer concentration) **Level 4 (Self-organization):** Let "losers" experiment with different approaches **What NOT to do:** - ❌ "Double down" on winners exclusively - ❌ Let losers die without understanding systemic value - ❌ Assume current success predicts future success **What to DO:** - ✅ Limit maximum resource allocation to any single entity (diversify) - ✅ Invest in "losers" as strategic options (portfolio thinking) - ✅ Rotate resources to prevent permanent advantage ## 5. Tragedy of the Commons ### Structure ``` Individual A Optimizes for Self --+--> Uses Shared Resource Individual B Optimizes for Self --+--> Uses Shared Resource Individual C Optimizes for Self --+--> Uses Shared Resource ↓ Shared Resource Degrades ↓ Less Available for All ↓ Individuals Use MORE (scarcity response) ↓ [REINFORCING LOOP - Accelerating Depletion] ``` ### Software Engineering Examples **Database Connection Pool** - Shared resource: DB connections - Individual optimization: Each service opens more connections for speed - Result: Pool exhausted, all services slow - Commons degraded: Database becomes bottleneck for everyone **Production Deployment Windows** - Shared resource: Production stability - Individual optimization: Each team deploys whenever ready - Result: Too many changes, hard to debug issues - Commons degraded: Production unstable for all teams **Shared Codebase Quality** - Shared resource: Code maintainability - Individual optimization: Each team ships fast without refactoring - Result: Tech debt accumulates, codebase unmaintainable - Commons degraded: Everyone slowed by poor code quality ### Diagnostic Questions - Is there a shared resource that multiple parties use? - Does each party optimize individually without considering others? - Is the resource degrading over time despite (or because of) individual optimization? - Would regulation/limits be resisted as "unfair" by individuals? **If YES:** Likely Tragedy of the Commons ### Intervention Strategy **Level 5 (Rules):** Regulate access to commons (quotas, rate limits, governance) **Level 6 (Information):** Make individual impact on commons visible (usage dashboards) **Level 3 (Goals):** Align individual goals with commons health (team incentives) **What NOT to do:** - ❌ Appeal to good behavior without enforcement - ❌ Wait for commons to collapse before acting - ❌ Blame individuals (system incentivizes this) **What to DO:** - ✅ Create feedback loop: usage → visible cost → self-regulation - ✅ Privatize commons OR enforce collective management - ✅ Charge for usage (make externalities internal) ## 6. Accidental Adversaries ### Structure ``` Party A Takes Action to Help Self ↓ Action Inadvertently Hurts Party B ↓ Party B Takes Action to Help Self ↓ Action Inadvertently Hurts Party A ↓ [REINFORCING LOOP - Mutual Harm Despite Good Intentions] ``` **Key difference from Escalation:** Not intentional conflict - each party solving own problem, unaware they're hurting the other. ### Software Engineering Examples **API Rate Limiting** - Party A (Platform): Add rate limits to protect servers - Hurts B: Users hit limits, break integrations - Party B (Users): Create multiple accounts to bypass limits - Hurts A: More load, harder to detect abuse, stricter limits needed - Result: Arms race, both worse off **Microservices Boundaries** - Party A (Team A): Optimizes their service, changes API frequently - Hurts B: Team B's service breaks from API changes - Party B (Team B): Adds defensive caching, duplicates data - Hurts A: Team A can't deploy changes, data consistency issues - Result: Tight coupling despite microservices **Oncall Rotation** - Party A (Oncall eng): Deploys quickly to reduce queue, incomplete testing - Hurts B: Next oncall gets incidents from rushed deploy - Party B (Next oncall): Adds deployment gates and approvals - Hurts A: Original oncall's deploys now blocked, queue grows - Result: Slower deploys, more incidents ### Diagnostic Questions - Are two parties pursuing legitimate goals? - Do their solutions inadvertently harm each other? - Is neither party trying to cause harm? - Is the relationship deteriorating despite good intentions? **If YES:** Likely Accidental Adversaries ### Intervention Strategy **Level 6 (Information):** Make impact visible - A sees how they hurt B, B sees how they hurt A **Level 5 (Rules):** Coordinate actions (shared calendar, RFC process, communication protocols) **Level 3 (Goals):** Create joint success metric that requires cooperation **What NOT to do:** - ❌ Blame either party (both acting rationally) - ❌ Let them "work it out" without structural change - ❌ Optimize one party at expense of other **What to DO:** - ✅ Joint planning sessions, shared visibility - ✅ Align incentives (both rewarded for cooperation) - ✅ Create shared ownership or merge teams ## 7. Drifting Goals (Complacency-Driven) ### Structure ``` Target Goal: 95% Actual Performance: 94.8% ↓ Small Gap - "Close Enough" ↓ Lower Target to 94% ↓ Actual Drops to 93% ↓ Lower Target to 93% - "Be Realistic" ↓ [REINFORCING LOOP - Standards Erode Gradually] ``` **Key characteristic:** Driven by complacency, not necessity. Team CAN achieve target but chooses not to. ### Software Engineering Examples **Test Coverage Erosion** - Started: 90% coverage standard - "Just this once": 70% for urgent feature - New normal: 75% "is realistic" - Current: 60%, bugs increasing - Team accepts: "Given constraints, 60% is good" **Code Review Standards** - Started: 2 reviewers, thorough feedback - Drift: 1 reviewer "to move faster" - Current: Rubber-stamp reviews - Result: Quality declined, but normalized **Deployment Frequency** - Started: Deploy daily - Drift: Deploy weekly "to reduce risk" - Current: Deploy monthly - Result: Releases become risky big-bang events, confirming fear ### Diagnostic Questions - Did standards start higher? - Was there a gradual lowering over time? - Are current standards justified by "being realistic" rather than necessity? - Can the team achieve original standards with current resources? **Critical test:** "If we gave team 2 more weeks, could they hit original target?" - **If YES:** Drifting Goals (capability exists, will doesn't) - **If NO:** Different archetype (resource constraint exists) ### Intervention Strategy **Level 6 (Information - Highest leverage for this archetype):** - Make drift visible: Historical trend chart, original vs. current standard - Customer impact metrics tied to lowered standards - Public commitment to original standard **Level 3 (Goals):** - Re-establish non-negotiable minimum standards - Remove authority to lower standards without explicit approval - Tie consequences to meeting original target **Level 5 (Rules):** - Automatic escalation when standards not met - Blameless post-mortems for "what would this look like at 95%?" **What NOT to do:** - ❌ Accept "constraints" without evidence (often post-hoc justification) - ❌ Add resources (no resource gap exists) - ❌ Negotiate standards based on convenience **What to DO:** - ✅ Make gap painfully visible - ✅ Celebrate meeting original standard, don't accept "close enough" - ✅ Re-commit publicly to original goal ## 8. Limits to Growth ### Structure ``` Growth Action --+--> Success/Growth ↓ Growth Continues ↓ Hits Limiting Constraint ↓ Growth Slows Despite Effort ↓ More Effort → Still Can't Grow ↓ [BALANCING LOOP - Constraint Dominates] ``` **Characteristic:** Growth works until it doesn't. Constraint kicks in, effort becomes futile. ### Software Engineering Examples **Traffic Growth Hits Infrastructure** - Growth: User acquisition working, doubling every 6 months - Constraint: Infrastructure can't scale fast enough - Limit: At 180K users, app crashes under load - Result: Growth stops, users churn, opportunity lost **Team Growth Hits Communication Overhead** - Growth: Hiring velocity high, team growing fast - Constraint: Communication overhead grows exponentially (n² problem) - Limit: Coordination cost exceeds productivity gain - Result: Bigger team, slower delivery **Feature Growth Hits Cognitive Load** - Growth: Shipping features rapidly - Constraint: User cognitive overload, can't find anything - Limit: More features make product HARDER to use - Result: User satisfaction drops despite more features ### Diagnostic Questions - Was growth working well, then suddenly stopped? - Are you applying more effort but seeing diminishing returns? - Is there an identifiable constraint that wasn't a problem before? - Does "trying harder" feel increasingly futile? **If YES:** Likely Limits to Growth ### Intervention Strategy **Level 10 (Structure - Highest leverage for this archetype):** - Remove or redesign the constraint - Examples: Rearchitect for scale, restructure team, simplify product **Level 3 (Goals):** - Change growth target to different dimension where constraint doesn't apply - Example: Growth in user engagement instead of user count **Level 11 (Buffers):** - Anticipate constraint, build capacity BEFORE hitting limit **What NOT to do:** - ❌ Apply more growth effort (won't work, constraint dominates) - ❌ Ignore constraint hoping it resolves itself - ❌ Treat constraint as temporary obstacle **What to DO:** - ✅ Identify the limiting constraint explicitly - ✅ Remove constraint OR pivot to different growth strategy - ✅ Invest in constraint removal before restarting growth ## 9. Growth and Underinvestment ### Structure ``` Growth --+--> Demand Increases ↓ Need for Capacity Investment ↓ Underinvest (short-term thinking) ↓ Quality/Performance Degrades ↓ Growth Slows ↓ "See? Didn't need that investment" ↓ [REINFORCING LOOP - Self-Fulfilling Prophecy] ``` **Key difference from Limits to Growth:** Constraint is CREATED by underinvestment, not inherent. ### Software Engineering Examples **Infrastructure Underinvestment** - Growth: Traffic increasing - Need: Scale infrastructure proactively - Underinvest: "Wait until we need it" - Result: Performance degrades → users leave → "see, didn't need more servers" - Self-fulfilling: Underinvestment killed growth **Technical Debt Underinvestment** - Growth: Feature demand high - Need: Pay down tech debt to maintain velocity - Underinvest: "Features first, debt later" - Result: Velocity drops → fewer features shipped → "see, we can ship with this debt" - Self-fulfilling: Debt accumulation slowed growth **Team Capability Underinvestment** - Growth: Business expanding - Need: Train team on new technologies - Underinvest: "No time for training, ship features" - Result: Quality drops → customers churn → "see, training wouldn't have helped" - Self-fulfilling: Lack of training killed growth ### Diagnostic Questions - Is there growth potential being unrealized? - Was there a decision to delay investment? - Did performance degrade, causing growth to slow? - Is the slowdown being used to justify the underinvestment? **Critical tell:** "We didn't need X after all" - but slowdown was CAUSED by not having X ### Intervention Strategy **Level 3 (Goals):** - Measure long-term capacity, not just short-term delivery - Goal: "Sustainable growth" not "maximize short-term growth" **Level 6 (Information):** - Model growth scenarios with/without investment - Make opportunity cost of underinvestment visible **Level 5 (Rules):** - Mandatory investment allocation (% of resources to capacity/capability) - Investment cannot be deferred without explicit growth target reduction **What NOT to do:** - ❌ Defer investment "until we're sure we need it" - ❌ Use growth slowdown to justify underinvestment - ❌ Optimize for short-term metrics at expense of capacity **What to DO:** - ✅ Invest AHEAD of demand (leading indicator) - ✅ Track capacity utilization, invest before hitting 80% - ✅ Make investment non-negotiable part of growth strategy ## 10. Eroding Goals (Pressure-Driven) ### Structure ``` Performance Gap (can't meet target) ↓ Pressure to Improve ↓ Can't Improve (resource constrained) ↓ Lower Standards to "Be Realistic" ↓ Pressure Temporarily Reduced ↓ Performance Drops Further (no standards to meet) ↓ Lower Standards Again ↓ [REINFORCING LOOP - Death Spiral] ``` **Key difference from Drifting Goals (#7):** Driven by necessity, not complacency. Team CANNOT meet target with current resources. ### Software Engineering Examples **Uptime SLA Erosion** - Target: 95% uptime - Reality: Team achieves 92-93%, burning out - Pressure: Management demands 95% - Can't achieve: Insufficient resources/tooling - Lower standards: "92% is realistic given constraints" - Result: Team delivers 89%, standards lowered again → death spiral **Velocity Pressure** - Target: 50 story points/sprint - Reality: Team delivers 35, working overtime - Pressure: "Try harder" - Can't achieve: Structural bottlenecks - Lower expectations: "35 is the new normal" - Result: Team delivers 28, morale collapses **Security Compliance** - Target: Pass all security audits - Reality: Team fixes 70% of issues - Pressure: Must pass audit - Can't achieve: Not enough security expertise - Lower standards: Accept "known risks" - Result: More issues next audit, lower bar again ### Diagnostic Questions **Critical test:** "If we gave team 2 more weeks, could they hit original target?" - **If NO:** Eroding Goals (structural constraint) - **If YES:** Drifting Goals (capability exists) **Other signs:** - Is the team burning out trying to meet targets? - Are resources insufficient for stated goals? - Is lowering standards framed as "being realistic" given constraints? - Is performance declining DESPITE effort increase? ### Intervention Strategy **Level 5 (Rules - Force Honest Choice):** - "Goals must match resources OR resources must match goals - pick one" - Cannot demand outcomes without providing means - Sustainable pace is non-negotiable **Level 11 (Buffers):** - Add slack/capacity to stop the death spiral - Provide recovery time for burned-out team **Level 2 (Paradigm Shift):** - From: "Try harder" → "Performance is emergent from system capacity" - From: "Pressure produces results" → "Burnout produces collapse" **What NOT to do:** - ❌ Just lower standards (doesn't address root cause) - ❌ Add pressure (accelerates death spiral) - ❌ Accept "try harder" as strategy **What to DO:** - ✅ Force explicit choice: Add resources OR lower goals (and own it) - ✅ Make current gap between goals and resources visible - ✅ Break the cycle with capacity addition or scope reduction ## Distinguishing Similar Archetypes ### Drifting Goals (#7) vs. Eroding Goals (#10) **Both:** Standards lower over time **Key difference:** WHY standards are lowered | Dimension | Drifting Goals | Eroding Goals | |-----------|----------------|---------------| | **Driver** | Complacency | Resource pressure | | **Team capability** | CAN achieve, chooses not to | CANNOT with current resources | | **Diagnostic test** | "2 more weeks?" → YES | "2 more weeks?" → NO | | **Pressure level** | Low, comfortable | High, burning out | | **Justification** | "Close enough" | "Realistic given constraints" | | **Intervention** | Make gap visible, recommit to standards | Add resources OR lower goals officially | ### Fixes that Fail (#1) vs. Shifting the Burden (#2) **Both:** Symptomatic solution, problem returns **Key difference:** Competing pathways | Dimension | Fixes that Fail | Shifting the Burden | |-----------|-----------------|---------------------| | **Structure** | One pathway with side effects | Two pathways (quick vs fundamental) | | **What happens** | Fix creates side effect that worsens problem | Fix prevents pursuit of real solution | | **Dependency** | Not necessarily | Creates addiction to quick fix | | **Example** | Adding alerts creates alert fatigue | QA team prevents quality culture | ### Escalation (#3) vs. Accidental Adversaries (#6) **Both:** Two parties harming each other **Key difference:** Intent | Dimension | Escalation | Accidental Adversaries | |-----------|-----------|------------------------| | **Intent** | Deliberate response to threat | Solving own problem, unaware of harm | | **Awareness** | Both know they're in conflict | Neither realizes they're hurting other | | **Example** | Tech debt vs feature pressure (both aware) | Rate limits → multi-accounts (unaware impact) | ### Limits to Growth (#8) vs. Growth and Underinvestment (#9) **Both:** Growth stops **Key difference:** Source of constraint | Dimension | Limits to Growth | Growth and Underinvestment | |-----------|------------------|----------------------------| | **Constraint** | Inherent limit (user cognitive load) | Created by underinvestment (infrastructure) | | **Timing** | Hits suddenly | Degradation visible in advance | | **Prevention** | Hard (inherent to system) | Easy (invest proactively) | ## Archetype Combinations **Systems often exhibit multiple archetypes simultaneously.** Recognize the pattern: ### Example: Feature Factory Disaster **Primary: Shifting the Burden** - Quick fix: QA team catches bugs - Fundamental: Dev teams build quality in - Burden shifted: Devs never learn quality **Secondary: Escalation** - Management: Pressure to ship faster - Engineering: Cut more corners - Both escalate: More pressure ↔ worse quality **Tertiary: Tragedy of the Commons** - Commons: Codebase quality - Individual optimization: Each team ships fast - Commons degraded: Everyone slowed **Intervention strategy for combinations:** 1. **Identify primary archetype** (drives the system) 2. **Address secondary archetypes** that reinforce primary 3. **Use highest-leverage intervention** that addresses multiple archetypes Example: Level 2 (Paradigm shift) to "quality is built in, not inspected in" addresses all three. ## Quick Recognition Guide **Start here when analyzing a problem:** 1. **Map the feedback loops** - Reinforcing or balancing? 2. **Identify the parties/stocks** - Who/what is involved? 3. **Check the signature patterns:** - Problem returns after fix? → Fixes that Fail (#1) - Symptom relief + fundamental solution ignored? → Shifting Burden (#2) - Two parties making it worse? → Escalation (#3) or Adversaries (#6) - Winner gets more resources? → Success to Successful (#4) - Shared resource degrading? → Tragedy of Commons (#5) - Standards lowering from complacency? → Drifting Goals (#7) - Standards lowering from pressure? → Eroding Goals (#10) - Growth stopped suddenly? → Limits to Growth (#8) - Growth stopped from underinvestment? → Growth/Underinvestment (#9) 4. **Use diagnostic questions** from each archetype section 5. **Check for archetype combinations** (multiple patterns may apply) ## Integration with Leverage Points **Each archetype has characteristic high-leverage interventions:** | Archetype | Highest-Leverage Intervention Level | |-----------|--------------------------------------| | Fixes that Fail | #3 (Goals) - Focus on root cause not symptom | | Shifting the Burden | #5 (Rules) - Make quick fix expensive/difficult | | Escalation | #3 (Goals) - Create shared goal | | Success to Successful | #5 (Rules) - Regulate resource allocation | | Tragedy of Commons | #6 (Information) + #5 (Rules) - Feedback + regulation | | Accidental Adversaries | #6 (Information) - Make impact visible | | Drifting Goals | #6 (Information) - Make drift visible | | Limits to Growth | #10 (Structure) - Remove constraint | | Growth/Underinvestment | #3 (Goals) - Measure long-term capacity | | Eroding Goals | #5 (Rules) - Force resource/goal alignment | **Pattern:** Most archetypes respond to Levels 3-6 (Goals, Rules, Information, Feedback) ## Red Flags - Rationalizations for Skipping Archetype Analysis If you catch yourself saying ANY of these, STOP and identify the archetype first: | Rationalization | Reality | Response | |-----------------|---------|----------| | "No time for archetype analysis in crisis" | 10 minutes of pattern matching saves weeks of wrong fixes | Crisis is EXACTLY when archetypes matter most - prevents accelerating the problem | | "My situation is unique, doesn't fit neat categories" | Uniqueness is in details, not structure - archetypes describe feedback loops | Test archetype predictions - if they match, it's the same structure | | "This fits multiple archetypes, any intervention works" | Multiple archetypes require identifying PRIMARY one first | Address dominant archetype first, then secondary reinforcing patterns | | "Archetypes are too academic/theoretical for real engineering" | Every archetype has software examples from production systems | This is pattern recognition, not theory - pragmatic shortcut to solutions | | "I already know the solution, archetype is overhead" | If solution is obvious, archetype confirms it in 2 minutes | Unknown solutions become obvious once archetype identified | | "We need action, not analysis" | Wrong action makes crisis worse (see: Fixes that Fail, Escalation) | Archetype analysis IS action - it prevents implementing failed patterns | **The pattern:** All rationalizations push you toward repeating known failure modes. The archetypes catalog exists because these patterns have been solved before. **The meta-trap:** "We're unique" is itself predicted by several archetypes (Shifting the Burden creates belief that quick fix is necessary, Drifting Goals creates post-hoc justification for lowered standards). ## The Bottom Line **Don't reinvent solutions to archetypal problems.** The same patterns recur across systems. Recognize the archetype, apply the known intervention strategy, save time. **The skill:** Pattern matching speed. Experienced systems thinkers recognize archetypes in minutes, know immediately where to intervene. **The discipline:** Don't jump to solutions before identifying the archetype. Taking 15 minutes to recognize the pattern saves hours implementing the wrong fix.