The Leverage Ladder
Climb on up!
The promotion to a leadership role comes with a strange curse. You’ll feel less productive while having more impact. Gone are the days when you could merge a PR or ship a feature to get that dopamine rush. Instead, you’ve got a six-month feedback loop, unclear attribution and work that doesn’t “feel” like progress. It’s deeply uncomfortable. Your leverage levers got a lot longer!
But, you aren’t alone! This isn’t a bug in your career progression, it’s a feature! As you move from building systems, to building systems that build systems, you need new yardsticks to measure your work.
The Leverage Hierarchy
Donella Meadows has a fantastic article, Places to Intervene in a System, which you should go and read now.
As a summary, Donella identifies the following twelve levers you can pull in a system. They start from least impactful to most impactful.
12. Constants, parameters, numbers.
11. Sizes of buffers and stabilizing stocks.
10. Structure of stocks and flows.
9. Lengths of delays.
8. Strength of negative feedback loops
7. Gain of positive feedback loops
6. Structure of information flows
5. Rules of the system
4. Power to add, change, or self-organize system structure
3. Goals of the system
2. Mindset or paradigm
1. Power to transcend paradigms
Let’s map these to your actual work as an engineering leader, starting from the bottom to the top.
Tactical Interventions (Level 12 - 9)
Constants, parameters, numbers. You can change a system by tweaking a value. For example, you might increase the desired level of code coverage, or you might increase the timeouts of your tests. These don’t have a huge amount of impact on a system; they might tune the behaviour, but ultimately the system works in the same way and teams can still play the same game in the same way.
When work needs to get more predictable or deal with failure, you might introduce some buffers / stabilizers. For example, if the system isn’t allowing tech debt to be resolved, you might decide N% of capacity be devoted to addressing debt. If your tests are slow, perhaps you’ll add a few extra CPUs to address the issue. At this level of the hierarchy you are changing how the jolts are absorbed, but you aren’t changing how decisions are made.
The structure of stocks and flows is about how work, code and people move around the system. You could change the release flow, for example moving from long-lived release branches to progressive delivery. This changes constraints and capabilities, but not yet the goals or the mindset.
The length of delays is a key lever for software teams, dictating how fast feedback comes in. You might move from quarterly deployment to daily so customer feedback lands in minutes not months. Or, you might simply prioritize faster PR feedback. You’re not changing what people optimize for, only how fast reality slaps them in the face.
Meadows’ insight here is that these are the most visible features, but the lowest leverage.
System Tuning (Level 8-6)
At the system tuning level, you move from tweaking the system to shaping it.
Negative feedback loops create controls that keep things within safe bounds. That might be an error budget policy with real teeth (”If SLOs are breached, stop the line!”), or quality gates in your CI process. These loops detect when X drifts and automatically pull it back. The leverage here is in tuning how hard they pull, but remember, they’re defensive; great at keeping you safe, terrible at letting you evolve.
Positive feedback loops amplify whatever they touch, for better or worse. Developer experience improvements create a virtuous cycle: easier tooling saves time, that time improves tooling further, which saves more time. Technical debt works the same way in reverse. The key is identifying what’s growing exponentially in your organization, then deliberately funding the loops you want and starving the ones you don’t.
Information flows change what’s visible and therefore what people naturally optimize for. When teams see real cloud costs (rather than a mysterious central bill), deployment decisions change immediately. You haven’t changed roles, pay, or mandates, but decisions shift because the right information is flowing to the right people. This is higher leverage because you’re not forcing behaviour or correcting it; you’re enabling better decisions by making the invisible visible.
Designs and Rules (Level 5-4)
Once you get to the rules of the system you are changing the game itself. For example, you might introduce guardrail rules (”no production access without audit” or “security review required for all auth issues”) which force behaviour change. These rules harden or reshape behaviour more than nudging metrics (but may squeeze other parts of your culture).
Going deeper you may extend this to delegating the power to add, change or self-organize system structure. Some of the elements from the Spotify model (such as guilds and squads) pull this lever with heavy levels of local autonomy. Once the system can change its own wiring in response to reality, you get tremendous leverage (though perhaps giving up control).
Foundational Levers (Level 3 - 1)
The goals of the system change what the system is trying to optimize for. Change the goals and everything reorients. For example, moving from project delivery to product value we shift from fixed scope/deadlines to continuous discovery, smaller bets and killing bad ideas early. If the goal is changed (and clearly communicated) then everything else follows.
The mindset or paradigm is the story about what engineering is. It sits under the goals and silently constrains them. For example, if your organization believes IT is a cost centre then there’s a mindset underneath of “keep it cheap and follow orders”. If instead that’s shifted towards “engineering is a strategic advantage” then that shapes the business model and investment logic changes.
And finally, the power to transcend paradigms is being able to see and switch paradigms rather than defend one. This is about treating methods as tools, not dogma. It’s about regularly reflecting on what’s working for the organization, and holding multiple frames of perspective at once (”move fast” yet “be safe”). At this level, the org isn’t trapped inside one model, it can instead deliberately pick, blend or discard models as needed. For instance, recognizing when to shift from “move fast and break things” to move deliberately and build trust” based on the maturity of your product (without treating it as religious doctrine).
Reality checks
All Levels Matter
Just because you’ve got a fancy job title, doesn’t mean you should solely focus on the highest levels of leverage. It’s not about abandoning the lower levels, it’s about adding higher levels to your toolkit. Sometimes the highest leverage move IS to fix the bug yourself, and the more you disconnect from the lower levels the more likely you are to be an ivory tower manager.
Systems Push Back
When you try to change a system, it’ll resist. That’s why change management exists, and change is hard. Before you attempt to pull a lever, have a plan for how it’ll stick.
Context Dependency
Anything you read is bound by the author’s context. I’ve not worked in “big tech” (Google, Meta and so on), I imagine they have vastly different leverage opportunities. Equally, it’s been a long time since I was in a start-up.
So take everything I’ve written with a healthy pinch of salt.
Practical Applications
Choosing your intervention point
Understanding the leverage ladder is one thing, knowing the lever to pull is another entirely. Here are some heuristics.
Start with the problem pattern. One-off issues warrant tactical fixes, JFDI! Recurring problems need higher leverage. If teams keep missing deadlines, adding buffer helps once. But persistent issues signal you’re treating symptoms. Look at information flows (e.g. are estimates visible?) Or rules (are we rewarding speed over quality)?
Check your authority. Can you actually pull that lever? Changing paradigms requires organizational buy-in a mid-level manager lacks. But you can change information flows on your team. Work within your scope, advocate upward beyond it.
Balance urgency with leverage. Need a quarterly win? Tactical interventions deliver faster. Just be explicit: “We’re adjusting this parameter for Q4, but I’m changing deployment rules for next year.” Don’t confuse short-term tactics with long-term strategy.
Trust “this shouldn’t be so hard.” If you’re repeatedly convincing people to do the obviously right thing, you’re fighting the system’s design. Climb up and make the better path the path of least resistance.
Diagnose Your Current Leverage Level
Where are you spending your time?
When I did the Cambridge CTO course, Professor Loch illustrated this. He asked the cohort what their company does. The answer would usually come back as a short, sharp elevator pitch. When asked individually, what do you do the answer would be a long-winded description of all the things. The point being that we often do low-value tasks that we really shouldn’t. The clearer you can be on the work you do, the more impactful you will be (applies to teams too!).
So here’s a quick exercise to do that. Export all the meetings you had in the last month (or dump your personal TODO list!) and classify them.
Start with work that hasn’t improved the system; this is tactical work. This is the system working on you! Now look at the strategic work and try and classify it as either Tactical Interventions / System Tuning / Designs and Rules / Foundational Levers.
When you do that, where’d you spend the time? Is it aligned with what you expected? Is it aligned with your organization’s needs?
If I look over my last few months in my current role, I’ve spent a lot of time on System Tuning, working to build dashboards that make information visible. However, I haven’t spent much time on designs / rules and in retrospect that’s a mistake!
If your work is all at a lower level, don’t be surprised if you don’t make the impact you hoped. Your job is to find time to spend at the higher rungs.
Deliberately Climb a level
Whatever task you are doing, imagine climbing one level higher.
If you worked on a quick win, what change could you make to the system so that the system makes the change itself?
If you worked to tune the system, what rules of the game could change so that tuning happens?
If you worked on the rules of the game, what bets would change the rules?
As an example, you might be considering a tactical intervention to increase reliability of CI systems which is dominated by an ever-growing suite of unreliable integration tests. If you take the system tuning perspective, you might instead try to identify the amplifying feedback loop that is resulting in those integration tests being written in the first place.
Build survival mechanisms
It’s going to take time to see the impact of your changes. And whilst you’re waiting for wins, it can be difficult to maintain motivation.
Find leading indicators and most importantly regularly take stock of your changes every few months. Seek stories first, rather than waiting for quantitative impact.
Build a peer network! Communities like CTO Craft or Rands Leadership Slack and the Cambridge Judge CTO Programme have been invaluable to me.
Make Implicit Strategy Explicit
I’ve been reading Crafting Engineering Strategy, and one of the points it makes really early on is that you always have a strategy, the question is whether it’s implicit or something explicit.
Part of writing strategies is to make the system visible and to create future levers to change. In my opinion, making it explicit and deliberate is a damn sight better than leaving it implicit.
Protect Your Sanity
You’ve traded instant delivery for slower, compounding impact.
Find short-term wins within long-term work: Ship the strategy doc, get the ADR template merged
Maintain your technical skills! Allocate some time for hands-on work. Even better if you can use it to explore some potential future (I’ve been having a blast playing with AI).
Seek feedback differently. Not “did you read my doc”, but “how did this change the work you do?”.
The Long Game of Systems Change
As Will Larson puts it: the org should benefit from you without depending on you. That’s the leverage ladder: the higher you climb, the more the system runs well without you constantly yanking the same levers.
If it runs well without you, you’re doing the job.