Why many engineers work very hard — yet create very little leverage

There is a common misconception in our industry:

Writing more code equals creating more value.

In practice, the opposite is often true.

Many engineers work extremely hard:

  • shipping many features
  • fixing many bugs
  • handling many tickets
  • staying busy all the time

But after one or two years:

  • the system is not more stable
  • the team is not faster
  • and they themselves are not any less busy

The problem is not a lack of skill.
The problem is that they are doing work with very little leverage.

What does “leverage” mean in software engineering?

Leverage is not:

  • a new framework
  • a new tool
  • a “fancy” design pattern

In software engineering, leverage means:

A small change
that creates a large and lasting impact over time.

The opposite is also true:

  • a lot of effort
  • small impact
  • short-lived results
    → this is low-leverage work.

Two engineers, the same 8 hours — very different outcomes

Engineer A

  • Fixes bugs case by case
  • Adds more if/else
  • Closes the ticket and moves on

The system:

  • remains fragile
  • the same bugs return in different forms

Engineer B

  • Notices the bugs come from unclear boundaries
  • Consolidates logic into one place
  • Writes tests for behavior, not individual cases

They may write fewer lines of code.
But:

  • bugs decrease
  • the code becomes easier to reason about
  • others are less afraid to change it

👉 B creates leverage. A does not.

Leverage is not about “doing more” — it’s about working in the right place

Some examples of high-leverage work in practice:

1. Clarifying ownership boundaries

A single change:

  • clearly defines which service owns an end-to-end flow
  • removes “this is not our responsibility” areas

Results:

  • faster debugging
  • shorter incidents
  • less tension within the team

👉 Very little code. Very high leverage.

2. Simplifying flows instead of optimizing steps

You can:

  • optimize a query from 120ms to 80ms (low leverage)
  • or remove an unnecessary step entirely (high leverage)

Many performance problems:

  • are not caused by algorithms
  • but by redundant or overly complex flows

3. Deleting code instead of writing more

Deleting:

  • unused abstractions
  • layers that only forward calls
  • configuration nobody understands

This is high leverage because it:

  • reduces cognitive load
  • reduces the bug surface
  • lowers maintenance cost

👉 But it requires technical courage, which is why it’s rare.

4. Writing tests in the right places

High test coverage alone is not leverage.

Leverage comes from:

  • testing critical behavior
  • testing what must never break
  • testing at boundaries

One well-placed test can:

  • prevent ten future bugs
  • save dozens of hours of debugging

Things that look “very technical” but have low leverage

1. Early micro-optimizations

  • caching too early
  • async-ifying too early
  • tuning without data

A lot of work.
Low leverage, because:

  • the problem may not exist yet
  • or it exists somewhere else

2. Abstraction for the sake of “cleanliness”

As discussed in the previous article:

  • the wrong abstraction creates negative leverage
  • because it slows everything down

3. Complex tooling before the team is ready

Sophisticated CI/CD.
Full observability.

But:

  • no one truly understands it
  • no one wants to maintain it

Leverage: zero.

A powerful question to evaluate leverage

In my team, when we consider doing something, we often ask:

“Will this still provide value in 6–12 months?”

If the answer is:

  • “It just helps us finish this sprint”
    → low leverage

If the answer is:

  • “It makes future changes cheaper”
    → high leverage

Leverage changes as your role changes

Junior engineers

Leverage comes from:

  • writing correct code
  • not breaking the system

Senior engineers

Leverage comes from:

  • reducing complexity
  • protecting critical logic
  • helping others write better code

Leads / Architects

Leverage comes from:

  • placing boundaries correctly
  • clarifying ownership
  • reducing the number of hard decisions teams face every day

The higher you go, the less leverage is tied to lines of code.

Conclusion

If you are always busy but the system is not getting better,
you are likely doing low-leverage work.

Leverage does not come from:

  • working faster
  • working more
  • making things more complex

It comes from:

Doing things that make future work cheaper.

A principle I always keep in mind:

If a change does not reduce future cost,
it is rarely leverage.

Personal note

This article is not encouraging people to “do less.”

It is simply a reminder:

In software engineering,
value does not come from effort —
it comes from leverage.

💬 Bình luận