Initial commit

skills/using-systems-thinking/recognizing-system-patterns.md

@@ -0,0 +1,226 @@
+
+# Recognizing System Patterns
+
+## Overview
+
+**Systems thinking reveals invisible structures causing visible behaviors.** Most problems arise from system structure (feedback loops, delays, stocks/flows) rather than external forces or individual actions. Interventions failing despite good intentions signal systemic causes.
+
+## When to Use
+
+```dot
+digraph when {
+    problem [label="Problem to solve" shape=box];
+    recurring [label="Same issue\nkeeps returning?" shape=diamond];
+    fix_failed [label="Fix worked\nthen stopped?" shape=diamond];
+    unintended [label="Solutions create\nnew problems?" shape=diamond];
+    complex [label="Many interconnected\nfactors?" shape=diamond];
+
+    apply [label="Apply systems thinking" shape=box style=filled fillcolor=lightgreen];
+    local [label="Likely local/isolated issue" shape=box];
+
+    problem -> recurring;
+    recurring -> fix_failed [label="yes"];
+    recurring -> local [label="no"];
+    fix_failed -> unintended [label="yes"];
+    fix_failed -> local [label="no"];
+    unintended -> complex [label="yes"];
+    unintended -> local [label="no"];
+    complex -> apply [label="yes"];
+    complex -> local [label="no"];
+}
+```
+
+**Use when you see:**
+- "It helped for a while, then got worse" (reinforcing loop)
+- "We keep fighting the same problem" (symptom treatment)
+- "The obvious solution made it worse" (unintended consequences)
+- "Everything affects everything" (interconnected system)
+- "No single cause" (emergent behavior)
+
+**Don't use for:**
+- Simple cause-and-effect problems
+- Isolated technical bugs
+- Problems with clear external causes
+
+## System Archetypes (Pattern Matching)
+
+Recognizing common structures saves analysis time:
+
+| Archetype | Symptom | Structure | Example |
+|-----------|---------|-----------|---------|
+| **Fixes that Fail** | Solution works temporarily, problem returns | Reinforcing loop eventually dominates | Database indexes help, then data growth overwhelms them |
+| **Shifting the Burden** | Symptom relief prevents real solution | Quick fix reduces pressure to solve root cause | Quality team fixes bugs so devs never improve |
+| **Accidental Adversaries** | Well-intentioned actions hurt each other | Each side's solution worsens other's problem | API rate limits → users create multiple accounts → stricter limits |
+| **Escalation** | Both sides increase efforts, making it worse | Reinforcing competition loop | Tech debt → pressure to go faster → more debt |
+| **Tragedy of the Commons** | Individual optimization degrades shared resource | Many users, one depleting resource | Every team adds database queries, DB slows for all |
+
+**When you recognize an archetype:** Jump directly to known leverage points for that pattern.
+
+## Quick Reference: Analysis Checklist
+
+When facing a complex problem:
+
+- [ ] **Map causal structure** - What causes what? Draw the loops
+- [ ] **Identify stocks and flows** - What accumulates? What's the rate of change?
+- [ ] **Find feedback loops** - Reinforcing (amplifying)? Balancing (stabilizing)?
+- [ ] **Spot delays** - How long between cause and effect?
+- [ ] **Check for archetypes** - Does this match a common pattern?
+- [ ] **Trace 2nd/3rd order effects** - Then what happens? And then?
+- [ ] **Find leverage points** - Where does small effort create large change?
+
+## Causal Loop Diagrams
+
+**Simple notation for showing structure:**
+
+```
+[A] --+--> [B]     "A increases B" (same direction)
+[A] ----> [B]
+
+[A] ---o> [C]      "A decreases C" (opposite direction)
+
+[B] --+--> [D] --+--> [B]    Reinforcing loop (R)
+                             (more B → more D → more B)
+
+[E] --+--> [F] ---o> [E]     Balancing loop (B)
+                             (more E → more F → less E)
+```
+
+**Example: Code Quality Decline**
+
+```
+Technical Debt --+--> Time to Add Features ---o> Feature Velocity
+       ^                                              |
+       |                                              |
+       +------------o---------------------------------+
+                  (Pressure to Ship Faster)
+
+              R: ESCALATION LOOP
+```
+
+This shows: Low velocity → pressure → cut corners → more debt → slower velocity → more pressure (reinforcing)
+
+**Leverage point:** Break the loop by making debt VISIBLE and protecting time for reduction (see Meadows' "Information flows" leverage point).
+
+## Stocks, Flows, and Delays
+
+**Stocks** = What accumulates (technical debt, data size, user trust)
+**Flows** = Rate of change (bug creation rate, data growth rate, churn rate)
+**Delays** = Time between action and result
+
+**Why this matters:**
+- Stocks can't change instantly (you can't fix all tech debt today)
+- Flows determine stock direction (reduce bug creation rate > fix existing bugs)
+- Delays hide consequences (hire now, onboarding overhead hits in 3 months)
+
+**Example: Performance Problem**
+
+```
+Stock: Total Data in Database
+Inflow: Records Added per Day (growing)
+Outflow: Records Archived per Day (zero)
+Result: Database size grows unbounded → performance degrades
+
+Leverage: Implement outflow (archival strategy)
+```
+
+## Leverage Points (Meadows' Hierarchy)
+
+**Where to intervene** (most to least effective):
+
+1. **Change system goals** - What is the system trying to do?
+2. **Change paradigms** - How do we think about this?
+3. **Add/change information flows** - Who knows what, when?
+4. **Change rules** - Incentives, constraints, feedback
+5. **Change structure** - Physical/organizational relationships
+6. **Adjust flows** - Rates of change
+7. **Adjust parameters** - Numbers in the system (least effective)
+
+**Most people start at #7 (parameters) - least effective!**
+
+**Example Application:**
+
+Problem: API making too many requests
+
+| Level | Intervention | Effectiveness |
+|-------|--------------|---------------|
+| Parameter | Set rate limit to 100/hour | Low - treats symptom |
+| Flow | Add caching to reduce request rate | Medium |
+| Structure | Add webhooks so clients don't need to poll | High |
+| Information | Show users their call patterns/costs | High |
+| Rules | Charge per API call above threshold | High |
+| Paradigm | Rethink: "API is request-response" → "API is event-driven" | Highest |
+
+## Predicting Unintended Consequences
+
+**Ask three levels deep:**
+
+1. **First order**: What happens immediately?
+2. **Second order**: Then how do people change behavior?
+3. **Third order**: Then what else changes?
+
+**Example: Strict Code Review Requirements**
+
+| Order | Effect |
+|-------|--------|
+| 1st | Code quality improves, fewer bugs |
+| 2nd | Developers split PRs smaller to get faster reviews |
+| 3rd | PRs become too small to understand context, review quality drops |
+
+**Technique: Pre-mortem**
+"It's 6 months from now. Our solution failed spectacularly. Why?"
+
+## Red Flags - When to STOP and Apply Systems Thinking
+
+If you catch yourself saying or thinking ANY of these, STOP immediately and map the system:
+
+| Rationalization | Reality | What to Do |
+|-----------------|---------|------------|
+| "Too simple for systems thinking" | Simple-seeming problems often have systemic roots | Spend 5 minutes checking for archetypes |
+| "I already know the answer" | Expertise creates blind spots to structure | Map one causal loop to verify |
+| "No time for analysis" | Fast wrong action wastes more time than analysis | 10-minute system check prevents hours of rework |
+| "Boss wants solution X" | Authority doesn't override system structure | Show data: "X addresses symptom, Y addresses cause" |
+| "The obvious solution" | Obvious solutions often treat parameters not structure | Check leverage point level before implementing |
+| "This worked before" | Systems change; yesterday's solution may worsen today's problem | Verify: What's different now? |
+| "We just need to ship something" | Shipping wrong fix loses more time/trust than delay | Propose: "15 min diagnosis, then ship correct fix" |
+
+**When under time pressure, systems thinking becomes MORE critical, not less.**
+
+Quick wrong action compounds problems. Spending 10 minutes mapping the system often reveals 30-minute fixes that would have been overlooked in favor of 2-week wrong solutions.
+
+## Common Mistakes
+
+### ❌ Treating Symptoms Instead of Structure
+
+**Symptom:** "Database is slow"
+**Symptom treatment:** Add indexes, more RAM, faster hardware
+**Structural fix:** Why is data growing unbounded? Add archival, change query patterns
+
+### ❌ Optimizing Parts, Not System
+
+**Example:** Each team optimizes their service latency, but system latency increases due to more service-to-service calls
+
+### ❌ Missing Delays
+
+**Example:** Hiring looks great month 1 (more hands), terrible months 2-4 (onboarding burden), good month 6+ (productivity)
+
+### ❌ Fighting Feedback Loops
+
+**Example:** More pressure to go fast → lower quality → slower velocity → more pressure (reinforcing). You can't win by "trying harder" - must break the loop
+
+### ❌ Solving Problems at Wrong Level
+
+**Example:** Adjusting rate limit numbers (parameter) instead of adding webhooks (structure change)
+
+## Real-World Impact
+
+**Performance debugging:** Recognizing "unbounded growth" pattern (stock with inflow, no outflow) immediately points to archival strategies instead of hardware scaling.
+
+**Team dynamics:** Seeing "Shifting the Burden" archetype (quality team) reveals why feature quality never improves - the quick fix prevents real solution.
+
+**Architecture decisions:** Using leverage point hierarchy shows why "add caching" (flow adjustment) is less effective than "add webhooks" (structure change).
+
+## Related Patterns
+
+- **Iceberg Model**: Events (what happened) → Patterns (trends) → Structure (system dynamics) → Mental Models (beliefs/assumptions)
+- **Feedback dominance**: Systems shift which loop dominates over time
+- **Emergence**: System behavior not predictable from individual parts