Where to Push: System Intervention Points That Work
- What intervention points actually are
- Why most teams push at the wrong points
- The five-step approach to picking intervention points
- How to apply this to a real workplace problem
Most attempts to change systems fail because they push at the wrong place. Donella Meadows wrote a famous essay in 1999 ranking twelve places to intervene in a system, from least to most effective. The pattern is consistent across organizations, products, and policy: the obvious places have low leverage, and the high-leverage places are usually invisible.
If you’ve ever felt like you’re working twice as hard to get half the result, you’re likely pushing against a low-leverage point. In the workplace, we see this when a team tries to "fix" productivity by increasing a budget or hiring more people, only to find that the fundamental delays and cultural bottlenecks remain exactly where they were.
The Leverage Paradox
An intervention point is a place where you can change something to influence a system's behavior. Meadows ranked them in inverse order of obviousness. The most obvious intervention points—parameters like budgets or quotas—have the least leverage. The least obvious intervention points—paradigms and mindsets—have the most leverage.
Most attempts to change systems target the bottom of the list and inevitably disappoint. We call this the Leverage Paradox: the easier it is to see a variable, the less power it has to actually change the outcome.
To help apply this to your own work, we’ve simplified Meadows’ original twelve points into five categories that specifically impact modern organizations and product development.
1. Constants and Parameters (Low Leverage)
This is where 90% of management effort goes. It includes things like budget allocations, headcount numbers, KPI targets, and salary bands.
While these numbers are necessary to track, changing them rarely changes the system. If you have a team that is fundamentally misaligned, giving them a 10% larger budget won’t align them; it will just allow them to be misaligned more expensively. If your product has a high churn rate, increasing your marketing spend (a parameter) might bring in more users, but they will still flow out through the same holes in the bucket.
The Omie View: Don't ignore the numbers, but don't expect them to save you. If you’re tweaking a target for the third time this quarter, you’re likely avoiding a deeper problem.
2. Buffers and Stocks (Medium-Low Leverage)
Buffers are the accumulated quantities that provide stability to a system. In a warehouse, it’s inventory. In a software project, it’s the "slack" or "cooldown" time between sprints. In a bank account, it’s reserve cash.
Systems with very small buffers are efficient but fragile. They break at the first sign of trouble. Systems with large buffers are stable but sluggish. Intervening here means adjusting how much "cushion" you have.
Adding a buffer—like an extra week for QA—can stop a cycle of "fix-the-fix" bugs. However, it’s still low leverage because it doesn't solve the cause of the bugs; it just manages the symptoms of the pressure.
3. Feedback Loop Strength (Medium-High Leverage)
This is where things start to get interesting. A feedback loop is the mechanism by which a system monitors its own behavior and adjusts.
There are two ways to intervene here:
- Strengthen a positive feedback loop (e.g., making it easier for a successful product to gain even more momentum).
- Shorten a negative feedback loop (e.g., getting customer feedback on a design in two hours instead of two weeks).
High-leverage change often comes from simply making information visible to the people who can act on it. If a developer sees the performance impact of their code in real-time on a dashboard, they will naturally write more performant code. If they only see a report once a month, they won't.
4. Rules and Goals (High Leverage)
Now we are nearing the heart of the system. The rules of the system define its constraints and its incentives. This includes compensation structures, "who is allowed to say no," and what the company actually rewards.
If the rule is "we never miss a shipping date," the system will sacrifice quality, sleep, and long-term stability to meet that goal. No amount of "parameter-tweaking" (adding more people) will change the fact that quality is being traded for time.
To change the behavior, you must change the rule. If you change the goal from "Ship on June 1st" to "Ship when we achieve a 90% NPS," the entire behavior of the team will shift overnight. They will stop cutting corners and start listening to users.
5. Paradigms (Highest Leverage)
Paradigms are the deepest beliefs and mental models from which the rules, goals, and feedback loops arise. They are the unspoken assumptions about "how the world works."
A paradigm shift is the most powerful intervention because it changes everything downstream. Consider these two different paradigms in software:
- Paradigm A: "Our developers are a cost center that needs to be managed for maximum output."
- Paradigm B: "Our developers are creative problem-solvers who drive our competitive advantage."
If you hold Paradigm A, you will create rules about micromanagement, parameters about utilization rates, and feedback loops focused on "lines written." If you hold Paradigm B, you will create rules about autonomy, parameters about "outcomes achieved," and feedback loops focused on "user delight."
A Practical Example: The Quality Crisis
Imagine your product's quality is slipping. Here is how you might intervene at different levels:
- Parameter (Low Leverage): You hire two more QA engineers. (The system stays the same; it just catches more bugs later).
- Buffer (Medium-Low): You add a "stabilization week" to the end of every month. (The system is less stressed, but the bug-creation rate is unchanged).
- Feedback (Medium-High): You implement automated testing that notifies developers of a break within 60 seconds. (The system starts to self-correct).
- Rules (High): You implement a rule that "No new features can be started if there are more than 5 open bugs." (The system is forced to prioritize quality over features).
- Paradigm (Highest): You shift the team's identity from "Feature Builders" to "System Stewards." (The team begins to take pride in the elegance and stability of the code, making all the previous rules almost unnecessary).
Conclusion: Where are you pushing?
Changing a system is hard work, but it’s much harder when you’re pushing against the points of least resistance. The next time you face a recurring problem—whether it’s a project that keeps slipping or a team that won't collaborate—ask yourself where you are intervening.
Are you just arguing about the budget (Parameter)? Or are you willing to look at the underlying goals and the mindsets that created the problem in the first place (Paradigm)?
True leverage usually feels uncomfortable because it requires questioning the "way things are." But it is the only way to create change that actually lasts.
Wondering where the leverage points are in your own product or organization? Our Omie Scan is designed to look past the parameters and identify the structural rules and paradigms that are holding you back. Let’s find where to push together.