thinking-feedback-loops

What this skill does

# Feedback Loop Analysis

## Overview

Feedback loop analysis (Donella Meadows, "Thinking in Systems") explains how a dynamic system behaves over time. Loops either amplify change (reinforcing) or stabilize toward a goal (balancing); delays between cause and effect produce oscillation. When a system grows uncontrollably, collapses, oscillates, or refuses to change, the loop structure is the cause.

**Core Principle:** System behavior emerges from feedback structure. To change behavior, change the loops.

## Trigger Card

When a system shows dynamic behavior (runaway growth, oscillation, resistance to change):

1. **Classify the behavior:** growing/collapsing → look for a reinforcing loop; oscillating → look for a balancing loop with delay; stuck → look for a dominant balancing loop.
2. **Trace the loop:** what variable feeds back into itself? Map causal connections with direction (+/-).
3. **Find the leverage:** shorten a delay, change a loop's gain, or add a balancing loop to a runaway reinforcing one.

If there's no dynamic behavior (static, one-time cause), skip — just fix it. For overall system mapping, use `thinking-systems`. For choosing where to intervene in an already-mapped loop, use `thinking-leverage-points`.

## When to Use

- A system shows runaway growth or collapse (suspect a dominant reinforcing loop)
- It oscillates around a target instead of settling (suspect delays in a balancing loop)
- It is stuck/resistant to change (suspect a dominant balancing loop)
- An "obvious" fix backfired and you need to know why

```
System behavior is puzzling or problematic?
  → Is it growing/shrinking unexpectedly?   → Look for REINFORCING LOOPS
  → Is it oscillating around a target?      → Look for DELAYS in BALANCING LOOPS
  → Is it stuck/resistant to change?        → Look for dominant BALANCING LOOPS
```

## When NOT to Use

- **You need to map the overall system structure** (components, stocks, flows, cross-service causes) — use `thinking-systems` instead. Feedback loops zooms in on the specific dynamic loops driving behavior; systems maps the full territory first.
- **You're looking for where to intervene** in an already-mapped system — use `thinking-leverage-points` (Meadows' 12-level hierarchy). Feedback loops tells you *which loop is dominant*; leverage-points tells you *where in that loop to act*.
- The symptom has a single static cause with no loop (a fixed bug, a one-time bad config) → just fix it.
- Behavior isn't changing over time—there's nothing dynamic to model.

## Core Concepts

### 1. Reinforcing Loops (Positive Feedback)

Reinforcing loops amplify change in the same direction—growth or decline. They create exponential behavior: the more you have, the more you get (or lose).

**Structure:** A → increases B → increases A (or: A → decreases B → decreases A)

```
┌─────────────────────────────────────────────────────────┐
│              REINFORCING LOOP (R)                       │
│                                                         │
│         ┌──────────┐         ┌──────────┐              │
│         │  Users   │───(+)──▶│  Content │              │
│         └──────────┘         └────┬─────┘              │
│              ▲                    │                     │
│              │                   (+)                    │
│              │                    │                     │
│              └────────────────────┘                     │
│                                                         │
│   More users → More content → More users (Growth)      │
│   OR: Fewer users → Less content → Fewer users (Death) │
└─────────────────────────────────────────────────────────┘
```

**Characteristics:**

- Exponential growth or collapse
- Self-fulfilling prophecies
- "Rich get richer" dynamics
- Virtuous cycles (when beneficial)
- Vicious cycles (when harmful)

**Software Examples:**

```
Retry Storm Loop:
Service slow → Clients retry → More load → Service slower → More retries
(Vicious cycle toward outage)

Technical Debt Loop:
Shortcuts → Bugs → Firefighting → Less time → More shortcuts
(Vicious cycle toward collapse)

Cache Stampede Loop:
Cache miss → Backend load → Slower fills → More misses → More load
(Reinforcing under expiry)
```

### 2. Balancing Loops (Negative Feedback)

Balancing loops counteract change, pushing the system toward a goal or equilibrium. They create goal-seeking behavior.

**Structure:** Gap between actual and goal → corrective action → reduces gap

```
┌─────────────────────────────────────────────────────────┐
│              BALANCING LOOP (B)                         │
│                                                         │
│   ┌──────────┐                    ┌──────────┐         │
│   │   Goal   │                    │  Actual  │         │
│   │  State   │                    │  State   │         │
│   └────┬─────┘                    └────┬─────┘         │
│        │                               │                │
│        └──────────┬────────────────────┘                │
│                   ▼                                     │
│             ┌──────────┐                               │
│             │   Gap    │                               │
│             └────┬─────┘                               │
│                  │                                      │
│                 (-)                                     │
│                  ▼                                      │
│           ┌────────────┐                               │
│           │ Corrective │                               │
│           │   Action   │────────▶ Closes gap           │
│           └────────────┘                               │
└─────────────────────────────────────────────────────────┘
```

**Characteristics:**

- Goal-seeking behavior
- Resistance to change
- Stability (when working well)
- Oscillation (when delays exist)

**Software Examples:**

```
Auto-scaling Loop:
Load increases → Gap from target → Scale up → Load per instance decreases
(Goal: maintain target response time)

Backpressure Loop:
Queue depth rises → Producers throttled → Arrival rate drops → Queue drains
(Goal-seeking to bounded queue)

Circuit Breaker Loop:
Error rate exceeds threshold → Breaker opens → Load sheds → Service recovers
(Goal: maintain availability)
```

### 3. Delays

Delays are the time between cause and effect. They are the primary source of oscillation and instability in systems.

```
┌─────────────────────────────────────────────────────────┐
│                   DELAY EFFECTS                         │
│                                                         │
│   Action ───────[DELAY]─────────▶ Effect               │
│                                                         │
│   Short delay: System responds smoothly                 │
│   Long delay: Overshoot and oscillation                │
│                                                         │
│   Examples:                                             │
│   • Code deploy → [Cache TTL] → Users see change       │
│   • New hire → [Ramp-up time] → Productivity impact    │
│   • Feature ship → [Adoption] → Metric movement        │
│   • Training → [Skill development] → Performance gain  │
└─────────────────────────────────────────────────────────┘
```

**Why Delays Cause Oscillation:**

```
Without delay:
  Gap detected → Correction → Gap closes → Done

With delay:
  Gap detected → Correction → [DELAY] → Gap persists →
  More correction → [DELAY] → Original correction arrives →
  Overshoot → Gap in opposite direction → Oscillation
```

**Classic Example: Shower Temperature**

```
Too cold → Turn hot → [Delay: water travels through pipes] →
Still cold → Turn hotter → Hot water arrives → Too hot! →
Turn cold → [Delay] → Still hot → Turn colder →
Cold water arrives → Too cold! → Oscillation continues
```

## Common System Patterns

### Pattern 1: Exponential Growth

**Structure:** Single dominant reinforcing loop

```
┌─────────┐      ┌─────────┐
│ Revenue │─(+)─▶│ Inve