curiositech/systems-thinking

Systems Thinking

Diagnose why systems cause their own behavior and identify structural interventions that produce sustainable change.

Decision Points

Pattern Recognition Table

| If you see this behavior... | Then check for... | Try this intervention tree | |----------------------------|------------------|---------------------------| | Oscillation (boom-bust cycles) | Excessive delays in corrective feedback | Reduce delays OR dampen response rates | | Exponential growth hitting limits | Balancing loop activating | Expand limits OR reduce growth rate early | | Multiple failed fixes | Policy resistance trap | Find shared overarching goal | | Performance declining over time | Drift to low performance | Hold absolute standards vs. relative | | Resource degradation | Tragedy of commons | Create direct user feedback |

Intervention Leverage Decision Tree

Problem identified → Map stock-flow structure first
│
├─ High leverage available?
│  ├─ Can change paradigm/worldview? → Transform mental models
│  ├─ Can shift system goals? → Redefine success metrics  
│  ├─ Can add/strengthen feedback loops? → Create information flow
│  └─ Can change rules? → Restructure incentives
│
├─ Medium leverage only?
│  ├─ Can improve information flow? → Connect decision-makers to consequences
│  └─ Can adjust parameters? → Change numbers/rates (lowest leverage)
│
└─ No structural leverage?
   └─ Wrong problem OR linear system → Use different approach

Trap Escape Decision Matrix

Trap Type → First Check → If Yes → If No
Policy Resistance → Others resisting your solution? → Find shared goal → Push harder (escalates)
Tragedy of Commons → Shared resource degrading? → Create ownership/feedback → Regulate only
Addiction → Intervention creating dependency? → Strengthen original capacity first → Continue intervention
Escalation → Competition intensifying? → Unilateral restraint OR negotiation → Try to win (unsustainable)

Failure Modes

Event Fixation

Detection: You're analyzing who did what when, looking for someone to blame
Symptom: "If only we fire X/hire Y/change Z, the problem will be solved"
Fix: Draw behavior over time graphs; map the structure generating events

Parameter Tweaking

Detection: 90% of discussion focuses on adjusting numbers (budgets, rates, standards)
Symptom: "We need to increase/decrease the target by X%"
Fix: Ask "What structure is producing these numbers?" Map information flows and feedback loops

Linear Causality Trap

Detection: Expecting proportional responses; surprised by sudden behavioral shifts
Symptom: "We did X, so Y should happen proportionally"
Fix: Map circular causality; identify reinforcing loops that create exponential effects

Control Obsession

Detection: Demanding predictable outcomes; treating uncertainty as failure
Symptom: "We need better forecasting/control systems"
Fix: Design adaptive feedback policies instead of rigid controls

Symptom Relief Addiction

Detection: Quick fixes that need repeating; original problem capacity atrophying
Symptom: "The intervention is working, we just need to do more of it"
Fix: Strengthen the system's original capacity; plan intervention withdrawal

Worked Examples

Example 1: Organizational Overtime Crisis

Situation: Software team chronically missing deadlines despite working 60+ hour weeks

Novice approach: Hire more developers, mandate better time estimation Systems analysis:

• Stock: Work backlog accumulating faster than completion rate
• Inflows: New features, bug reports, scope changes
• Outflows: Completed work (declining due to exhaustion/turnover)
• Feedback loop: Overtime → fatigue → more bugs → more rework → more overtime

Intervention chosen: Slow intake rate (say no to new requests) + improve quality to reduce rework Outcome: Backlog initially grew (counterintuitive) but outflow rate increased as bugs decreased Unintended consequence: Sales team frustrated by delayed features, required stakeholder alignment

Example 2: Environmental Resource Depletion

Situation: Fishing community experiencing declining catch despite harder work

Stock-flow mapping:

• Stock: Fish population (declining)
• Inflows: Fish reproduction (slow, 2-year delay)
• Outflows: Fishing harvest (increasing with effort)
• Structure: Classic tragedy of commons - individual rationality, collective irrationality

Decision point navigation:

1. Oscillation pattern? → Check delays: Yes, 2-year reproduction lag
2. Shared resource? → Yes, tragedy of commons trap
3. High leverage intervention? → Create direct feedback between individual action and consequences

Intervention chosen: Assign fishing territories (privatization) + seasonal quotas based on stock levels Outcome: Short-term income drop, long-term sustainability
Unintended consequence: Some fishers excluded from system, required compensation mechanism

Example 3: Technology Performance Degradation

Situation: Database system slowing down despite hardware upgrades

Systems lens applied:

• Behavior over time: Response time increasing exponentially under load
• Stock: Query complexity accumulating in system
• Structure: Performance fixes create more complex queries → slower performance → more "optimization"

Leverage points tested:

1. Parameter level: More RAM/CPU → Temporary improvement only
2. Information flow: Real-time performance visibility to developers → Better query design
3. Rules change: Query complexity limits → Structural improvement

Result: Information flow change had highest leverage - developers changed behavior when they saw real impact

Quality Gates

• [ ] Behavior over time graphs generated for key variables (not just snapshots)
• [ ] All major stocks identified and quantified with actual numbers where possible
• [ ] All inflows and outflows mapped with approximate rates
• [ ] At least 2 feedback loops identified (1 reinforcing, 1 balancing minimum)
• [ ] Delays between actions and consequences measured/estimated
• [ ] System archetype/trap pattern recognized and named
• [ ] At least 2 different leverage points tested (not just parameter changes)
• [ ] Unintended consequences anticipated and mitigation planned
• [ ] Success metrics aligned with actual system purpose (not just activity measures)
• [ ] Intervention includes feedback mechanism for course correction

NOT-FOR Boundaries

Don't use systems thinking for:

• Linear technical problems: Use root cause analysis instead
• One-time events: Use project management for discrete deliverables
• Emergency response: Use crisis management protocols for immediate threats
• Simple optimization: Use operations research for well-defined mathematical optimization
• Individual behavior change: Use psychology/coaching for personal development

Delegate to other skills:

• Data analysis: For statistical correlation without feedback loops
• Strategic planning: For competitive positioning and market analysis
• Process improvement: For workflow optimization without complex interdependencies
• Negotiation: For resolving conflicts between known parties with clear interests

Systems thinking boundaries:

• Requires circular causality and feedback loops
• Needs time delays between cause and effect
• Involves multiple stakeholders with competing goals
• Exhibits unintended consequences from well-intentioned actions
• Shows persistent problems despite repeated interventions