High-leverage work

High-leverage work rarely arrives labeled "promotion project." It hides in pain. Leverage is impact per unit of time. Fixing a one-off bug that saves you an hour has low leverage. Fixing the root cause that stops the bug class for the whole team has high leverage.

Edmond Lau's framing in The Effective Engineer is blunt: optimize for leverage, not for looking busy.

Four places to look

On-call and production themes. If the same alert pages three times a month, the high-leverage move is not answering the page faster — it is removing the class of failure. A junior closes the ticket. An SDE2 writes the fix, the test, and the runbook update. An SDE3 asks whether the whole subsystem needs a different design.

Metrics that are stuck or wrong. Conversion drop after signup, p99 latency creeping up, error rate on one endpoint, support volume for one flow. Pick a metric the business already cares about. Work that moves a shared dashboard is easier to explain in a promo packet than "I refactored module X."

Roadmap gaps. Product roadmaps skip glue: migrations, auth edge cases, developer experience, cost, and reliability. Those gaps are career gold if they unblock many features. Ask your PM and manager: "What are we not building because the platform can't support it?"

Team friction. Slow CI, flaky tests, opaque deploy, tribal knowledge. Automating away a daily tax for eight engineers is often more valuable than another feature of similar code size.

Walking through the arithmetic

Your team spends about 30 minutes per engineer per day waiting on a flaky integration suite.

8 people × 0.5 h × 5 days = 20 engineer-hours / week

A two-week project that cuts flakes by 80%
  returns ≈ 16 h / week, forever

At ~$100 / engineer-hour fully loaded (order of magnitude)
  ≈ $1,600 / week of recovered capacity

That is the leverage story you put in the write-up, not "I improved the test suite." Morale is extra, not the headline.

Common mistakes

• Chasing a refactor with no user or metric outcome. Hard to defend in calibration.
• Picking work nobody already measures. Prefer a dashboard that exists.
• Answering the same page faster forever. That is low-leverage heroics.
• Starting five "high leverage" ideas. Leverage only counts when you finish.

Check yourself

1. The same disk alert pages 4–6 times a week. What is the high-leverage move? Retune the rule and remove the false-positive class, not just acknowledge faster.

2. Why is "I refactored module X" a weak promo line? It names activity. Name the metric, the hours recovered, or the incidents that stopped.

Key takeaways

• Leverage is impact per hour, not busyness.
• Look in on-call themes, stuck metrics, roadmap gaps, and team friction.
• Prefer work that moves a dashboard people already watch.
• Write the arithmetic into the proposal so others can see the return.

Further learning

Edmond Lau's Talks at Google session is the clearest public talk on leverage.

The Effective Engineer (Edmond Lau)Time is your most limited and critical resource. Learn powerful mindsets, strategies, and tools on how to spend it on what matters most.The Effective Engineer

Next, take the work on without fragmenting in volunteering for scope.