Everyone talks about finding “high-leverage” work. Build tools that automate tasks. Write code that gets reused. Create processes that scale. These are all great things that can help you land more impact with your finite time. But if we think more deeply about what leverage actually means, I would argue these activities are actually low-leverage activities.
In physics, leverage is about trading force for distance:
Without lever: 100 lbs force × 1 foot = 100 ft-lbs of work
With lever: 10 lbs force × 10 feet = 100 ft-lbs of work
The crowbar doesn’t create energy out of nothing; instead, it redistributes the effort. In doing so, it unlocks new possibilities. With leverage I can lift a car using no power other than my own; without leverage I could not lift a car at all. This unlocking of new possibilities, though, is a corner case of the broader concept of leverage.
As we accelerate our car onto the freeway, we shift into higher gears with lower leverage in order to drive more efficiently. When we pull something heavy or accelerate up a hill we shift into lower gears, with higher leverage. Leverage allows us to do more work that is “easier”. But more work that is easier is not always the best choice – just imagine driving down the freeway in first gear. Leverage is a tradeoff, not a universal goal.
In knowledge work, there are similar tradeoffs. On a given day, we can do more “easier” work or less “hard” work. Many times low-leverage work is what allows us to get more impactful work done. Low leverage work require deep thinking and sustained focus. This work generally answers harder questions, is harder to replicate, and unlocks more value.
| Type of work | Characteristics |
|---|---|
| High-leverage work | Work is easy but takes more time |
| Low-leverage work | Work is hard but takes less time |
Doing low leverage work does not mean avoiding automation and scaling oneself. To the contrary, in my view, these activities are low leverage. Automating means doing something relatively novel and difficult (e.g., building a new tool) to handle something easy and repeatable (e.g., monitoring metric movements). Similarly scaling oneself through others means doing something difficult (e.g., delegating work) instead of doing something easy (e.g., simpler executable tasks that more junior ICs can handle).
The natural hazard when focusing on low-leverage work is running into problems that are too difficult – problems where you make no progress at all. In these cases, it makes sense to down-shift, lever up and decompose the problem into easier components to solve.
My suggestion for you: try to do more low-leverage work today. Tackle the difficult problem that lets you get more work done in less time. If it gets too hard, then lever up just enough to get the job done.