thinking-leverage-points

What this skill does

# Leverage Points

## Overview

Donella Meadows' "Places to Intervene in a System" ranks intervention points by their power to change behavior. Most effort goes into low-leverage moves (parameters, buffers) when higher-leverage points (rules, goals, structure) change behavior with less force. This is the canonical home of the 12-level hierarchy—other skills (`thinking-systems`, `thinking-feedback-loops`) reference it instead of duplicating it.

**Core Principle:** Higher in the hierarchy = more leverage, but more resistance. Find the highest leverage point you can actually move.

## When to Use

- Choosing where to focus engineering effort on a system you can already see
- Incremental tweaks (timeouts, buffer sizes, more instances) keep not solving the problem
- Deciding between a quick parameter change and a structural fix

```
Want to change system behavior?
  → Stuck tuning parameters with no lasting effect? → MOVE UP THE HIERARCHY
  → Found the lever but the change won't stick?     → look for a balancing loop resisting it
```

## When NOT to Use

- You haven't yet located the cause or mapped the system → use `thinking-systems` first; you can't rank interventions on a system you don't understand.
- A single low-level parameter genuinely is the fix (e.g., a wrong timeout value) → just change it; don't manufacture a paradigm shift.
- The decision is a one-off with no system behind it → this hierarchy adds nothing.

## Trigger Card

When tuning parameters keeps not sticking and you need to pick where to intervene:

1. **Identify the system goal** — what is the system trying to do? This is the highest-leverage point.
2. **Scan the hierarchy top-down** — from goals/rules/power down to parameters. Don't start at the bottom.
3. **Intervene at the highest feasible point** — pick the highest-leverage point you can actually change, not the easiest.

If a single low-level parameter genuinely is the fix (wrong timeout value), just change it. If there's no system behind the decision, skip — this hierarchy adds nothing.

## The 12 Leverage Points (Low to High)

### Level 12: Constants and Parameters (LOWEST LEVERAGE)

**What:** Numbers—budgets, rates, thresholds, timeouts

**Examples:**
- Adjusting cache TTL
- Changing retry counts
- Modifying timeout values
- Tweaking rate limits

**Why low leverage:** Parameters rarely change behavior fundamentally. The system absorbs parameter changes and continues its pattern.

```
Intervention: Increase server timeout from 30s to 60s
Result: Slow requests succeed, but root cause remains
Leverage: Very low—masks symptom, doesn't fix system
```

### Level 11: Buffer Sizes

**What:** Stabilizing stocks—queues, caches, inventories

**Examples:**
- Queue depth limits
- Connection pool sizes
- Memory allocations
- Batch sizes

**Why low leverage:** Buffers absorb fluctuations but don't change system dynamics. Bigger buffer = slower response to change.

```
Intervention: Increase message queue size
Result: Handles traffic spikes, but processing lag grows
Leverage: Low—buys time but doesn't address throughput
```

### Level 10: Stock-and-Flow Structures

**What:** Physical architecture—how things are connected

**Examples:**
- Database schema
- Service topology
- Network architecture
- Team structure

**Why medium leverage:** Hard to change once built; design matters but is often locked in.

```
Intervention: Add read replica to reduce DB load
Result: Significant improvement in read performance
Leverage: Medium—structural change, but within existing paradigm
```

### Level 9: Delays

**What:** Time lags in feedback loops

**Examples:**
- Deployment pipeline duration
- Feedback cycle time
- Onboarding time
- Release frequency

**Why medium leverage:** Shortening delays makes systems more responsive and stable. Many oscillation problems are actually delay problems.

```
Intervention: Reduce deployment time from 2 hours to 10 minutes
Result: Faster feedback, fewer bugs reaching production
Leverage: Medium-high—changes system responsiveness fundamentally
```

### Level 8: Balancing Feedback Loops

**What:** Negative feedback that counteracts change

**Examples:**
- Auto-scaling rules
- Circuit breakers
- Quality gates
- Alerting thresholds

**Why medium-high leverage:** Strengthening balancing loops increases stability; weakening them enables change.

```
Intervention: Implement circuit breaker with automatic recovery
Result: Failures isolated, cascade prevention
Leverage: Medium-high—changes failure dynamics
```

### Level 7: Reinforcing Feedback Loops

**What:** Positive feedback that amplifies change

**Examples:**
- Growth loops (viral, network effects)
- Technical debt spirals
- Talent attraction/attrition cycles
- Performance improvement loops

**Why high leverage:** Reinforcing loops drive exponential growth or collapse. Controlling gain = controlling trajectory.

```
Intervention: Create "fix broken windows" culture that reinforces quality
Result: Quality begets quality, technical debt decreases
Leverage: High—self-sustaining improvement
```

### Level 6: Information Flows

**What:** What signal is surfaced, and where

**Examples:**
- Surfacing a previously-hidden metric (queue depth, error budget, p99)
- Logging the value that was silently defaulting
- Making a failure mode observable instead of swallowed

**Why high leverage:** A component can only respond to what it can see. Adding a feedback signal where one was missing changes behavior without changing any logic.

```
Intervention: Emit and alert on cache hit-rate that was previously invisible
Result: Regression caught immediately instead of after an outage
Leverage: High—behavior change through visibility
```

### Level 5: System Rules

**What:** Constraints the system enforces—what's allowed, required, or rejected

**Examples:**
- A required CI gate / merge check
- A schema or contract that rejects invalid input at the boundary
- A deployment policy (canary, required rollback path)
- A rate limit or quota

**Why high leverage:** Rules define what's even possible. Change the rule and a whole class of behavior changes or becomes impossible.

```
Intervention: Make the type checker / schema validation a hard CI gate
Result: An entire class of bug can no longer reach production
Leverage: High—changes what's acceptable
```

### Level 4: Self-Organization

**What:** Ability of the system to change its own structure

**Examples:**
- Plugin/extension points instead of hardcoded behavior
- Services that can register/discover each other dynamically
- Auto-scaling and self-healing instead of fixed topology
- Schema/config that the system can evolve safely

**Why very high leverage:** Systems that can adapt their own structure survive change; rigid systems eventually break.

```
Intervention: Replace a hardcoded dispatch table with a plugin registry
Result: New behavior added without touching the core; the system evolves
Leverage: Very high—enables adaptation
```

### Level 3: System Goals

**What:** What the system is actually optimizing for

**Examples:**
- The objective a scheduler/optimizer maximizes
- The SLO the system is built to hold
- The success metric a pipeline is tuned against

**Why very high leverage:** Everything downstream serves the goal. Optimizing for the wrong target reliably produces the wrong behavior, no matter how good the parts are.

```
Intervention: Change a cache eviction goal from "max hit rate" to "bound tail latency"
Result: Different eviction policy, different downstream behavior entirely
Leverage: Very high—redirects all effort
```

### Level 2: Paradigm (Mindset)

**What:** The shared assumptions from which goals and architecture arise

**Examples:**
- "Cache everything" vs "Cache only what's measured hot"
- "Microservices always" vs "Right tool for context"
- "Avoid failure" vs "Design for graceful degradation"

**Why transformational:** Paradigms are upstream of goals, rules, and structure. Shift the paradigm, transform the system.

```
Inter