Where to Hit the System
Not all interventions are equal. Donella Meadows identified 12 Leverage Points — places to intervene in a system — ranked from least to most effective. Understanding this hierarchy prevents you from wasting effort on low-impact changes while ignoring transformative ones.
Low Leverage (Where most engineers spend their time):
- 12. Constants, parameters, numbers: Changing the buffer size of a queue from 1000 to 2000. Adjusting the autoscaler threshold from 80% to 75%. Increasing the timeout from 30s to 60s.
- Why it's low leverage: These changes rarely fix systemic issues. They buy time. The system's structure remains unchanged, so the same problem will recur at a different scale. Engineers love tweaking numbers because it feels productive and is low-risk, but it is the equivalent of rearranging deck chairs.
Medium Leverage (Structural changes):
- 7-9. Feedback loops: Adding, removing, or strengthening feedback loops.
- Example: Implementing a WIP Limit (Work In Progress) in Kanban. If the team's "In Progress" column is limited to 3 items, no one can start new work until something is finished. This is a new balancing loop that structurally prevents work-in-progress from accumulating. It changes behavior without requiring willpower or management oversight.
- Example: Adding an error budget policy to your SLO. When the error budget is exhausted, feature work automatically stops and reliability work begins. This is a balancing loop that connects reliability (stock) to development velocity (flow).
High Leverage (The Holy Grail):
- 1-3. Goals, paradigms, and the power to transcend paradigms: Changing the purpose of the system or the mental model that governs it.
- Example: Moving from "We sell software licenses" (Goal: maximize shipments per quarter) to "We sell uptime" (Goal: maximize reliability). This single change in the system's goal automatically realigns every stock, flow, incentive, and feedback loop below it. Sales teams stop pushing rushed releases. Engineering teams get rewarded for stability. Support teams become profit centers instead of cost centers.
- Example: Shifting from "Infrastructure is a ticket-based service" (paradigm: Ops is a service desk) to "Infrastructure is a self-service platform" (paradigm: Ops builds products for internal developers). This paradigm shift changes hiring profiles, success metrics, team structures, and technology choices — all from one conceptual change.
The Counterintuitive Truth:
People intuitively push hardest at the lowest leverage points (tweaking numbers) because they are easy to change. The highest leverage points (goals and paradigms) are the hardest to change but produce the most dramatic results. A senior engineer's value often comes from recognizing when the team is optimizing parameters in a system whose goal is wrong.
When asked "How would you improve the reliability of this system?", structure your answer using leverage points. Start with the highest leverage: "First, I'd ensure the organization's goals align — does leadership actually prioritize reliability over feature velocity? If not, no technical solution will stick." Then move to medium leverage: "I'd implement SLO-based error budgets as a feedback loop." Only then discuss low leverage: "And yes, we'd also tune timeouts and retry policies." This demonstrates systems thinking and separates you from candidates who jump straight to technical fixes.
Key Point: Meadows herself noted that people often push leverage points in the wrong direction. A common example: a company adds more process (a balancing loop) to prevent mistakes, but the process slows everything down so much that people find workarounds, creating new failure modes. The leverage point was correct (feedback loops), but the direction was wrong (adding friction instead of adding visibility). Always ask: "Am I adding a loop that helps the system self-correct, or am I adding a loop that the system will route around?"