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

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:

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

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

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:

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