Skip to main content

Leverage: Where an IC's Time Multiplies

What This Concept Is​

Leverage is the ratio between the effort you spend and the work that happens as a result. Grove's High Output Management frames a manager's output as output = leverage * effort, summed over activities. The same math applies to a Staff+ IC.

Three families of high-leverage work:

  • Force multipliers. Tools, templates, paved paths, shared libraries, automation - one hour of yours saves dozens of hours per week for everyone else.
  • Decisions that unblock many. An ADR, a design approval, a killed project, a clarified requirement - one written artifact converts ambient uncertainty into execution for multiple teams.
  • Growing other people. Mentorship and sponsorship - one engineer upgraded to the next level returns that investment for every project they touch afterwards.

Low-leverage work is not bad work. It is work where your hour returns roughly your hour. Most senior engineering hours drift into low-leverage work by default, because the urgent always chases out the important.

Why It Matters Here​

Staff+ engineers are expensive. Their hourly cost is only justified if a meaningful fraction of their hours is spent on high-leverage moves. Otherwise the organization is paying Staff+ rates for senior-IC output - which is a hiring failure disguised as a scheduling problem.

The practical form of this is: if an audit of your last month would show you reviewed 300 PRs, attended 120 meetings, and wrote zero strategy artifacts, the role is misfiring even if every individual hour was well-spent.

Concrete Example​

Two Staff engineers on the same team, both working 45 hours per week:

  • A pairs with the on-call engineer for every incident, writes every runbook themselves, reviews every PR in the monorepo, answers every question in #help-eng. Output: the team functions; A is indispensable; nothing scales beyond A.
  • B writes a post-incident template, pairs once with each on-call engineer to teach the template, delegates PR reviews by domain, turns #help-eng questions into wiki entries after the second repeat, spends 6 hours a week writing a platform RFC. Output: the team writes its own runbooks, PR reviews are fast, and the RFC moves a cross-team decision.

A is higher-effort. B is higher-leverage. Over a year, B's work compounds; A's does not.

Common Confusion / Misconception​

"High-leverage means lazy." No. High-leverage moves are often harder than the low-leverage ones they replace - writing the template is harder than answering the question, writing the RFC is harder than arguing in Slack.

"Leverage is just automation." Automation is the cleanest example but not the only one. A single one-hour conversation that kills a doomed project has extreme leverage. A one-page decision doc that stops a rebuild discussion can save a quarter of team effort.

"Heroism is high-leverage because it fixes the hard stuff." Heroism is the opposite. It centralizes knowledge in one person, hides the system problem that caused the fire, and makes the next fire more likely. It feels high-leverage; it is usually anti-leverage.

"Leverage is measured by how much I am needed." Backwards. Leverage is measured by how much the system works without you being needed. The engineer who can take a two-week vacation without the team degrading has higher leverage than the engineer nobody can do without. "Indispensable" is a failure mode dressed up as a compliment.

Grove's Framing, Applied to an IC​

Andrew Grove's High Output Management frames a manager's output as Output = sum over activities of (Leverage × Effort). Grove's three ways to raise leverage generalize almost unchanged to a Staff+ IC:

  • Affect many people with one activity. A shared library, a paved-road template, a decision doc that ten teams use.
  • Affect activity over a long period. A runbook, an ADR, an onboarding doc. The cost is paid once; the benefit runs for years.
  • Provide a key piece of knowledge or insight that unblocks a high-effort activity. The Slack answer that stops a six-engineer team from spending a week on the wrong design.

Grove's corollary: negative leverage exists. A one-hour meeting that confuses ten engineers for a week is high-magnitude negative leverage. The senior IC who cancels a recurring meeting because its value is below zero is doing leverage work, not shirking.

Where Leverage Hides​

High-leverage moves are usually boring to describe, which is why they get under-counted in performance reviews. A partial list of work that almost always has 5x+ leverage for a Staff+ IC:

  • Writing down tacit knowledge. The thing "only you know" has zero leverage until it exists on a wiki.
  • Killing a project. Removing a commitment is frequently higher-leverage than shipping a new one.
  • Clarifying a bad requirement. One hour of sharpening a goal can save a team a month of building the wrong thing.
  • Introducing one paved path. A shared template, library, or deployment pattern that ten teams adopt.
  • Sponsoring a hire. Bringing in the right senior engineer is a multi-year leverage move.

Notice how none of these produce a merge commit. Perf-review systems that only count merges will under-value a Staff+ IC doing the job correctly; it is part of the role to make this work visible.

A corollary: the leverage audit is also a visibility audit. If you cannot name the high-leverage moves you made this quarter in a sentence each, your manager cannot either, and your next review will reflect it.

Another corollary: calendar is budget. You cannot add a high-leverage move without removing a lower-leverage one. Saying yes to an RFC is saying no to three PR reviews that week.

Budget leverage the same way you budget engineering capacity.

How To Use It​

At the end of each week, do a leverage audit:

  1. List every work block of 30+ minutes. Calendar plus Slack plus PRs.
  2. For each, write the leverage ratio: 1x (one hour out for one hour in), 3x (template, teaching), 10x (decision that unblocks many), 0.1x (defensive work that will recur next week).
  3. Sum the 10x blocks. If the total is under 10% of your week, the role is drifting to senior-IC shape.
  4. Kill or delegate one 1x recurring block. A meeting, a review, a "only I can do this" task that is only true because you never trained anyone else.

Leverage Visibility​

A high-leverage move that nobody sees is functionally indistinguishable from no move at all, at performance review. The fix is not self-promotion; it is making the artifact. Rules that work:

  • Write the RFC. The writing is the visibility. A conversation that killed a doomed project is invisible. A short memo titled "Why we are not rebuilding X" is cited for a year.
  • Name the force multiplier. If you introduced a paved-road template, label it: "This deploy script is the v1 of the paved-road template - adoption tracker at [link]." The label converts private utility into named infrastructure.
  • Make the bench visible. "C led the API-gateway project this quarter" is a sentence you can put in your own self-review without it sounding like bragging; it is evidence that you sponsor, which is itself high leverage.
  • Separate the meeting from the artifact. The meeting is ephemeral; the artifact accrues. If the only record of your 10x week is in Slack scroll, nobody will find it in six weeks.

Staff+ engineers who do strong leverage work but cannot point at artifacts consistently underperform at promo time compared to peers doing weaker but more visible work. The fix is not to do less leverage work; it is to stop making leverage invisible.

Check Yourself​

  1. Name one recurring meeting on your calendar. What is its leverage? Could you replace it with a written artifact?
  2. Name one tool or template you could build this month that would save the rest of the team four hours per week each.
  3. When was the last time you killed a project? That decision's leverage is probably larger than anything you shipped last quarter.

Mini Drill or Application​

Pick your last five working days. For each, identify:

  • the single highest-leverage 30 minutes you spent (what was it, who did it affect, how much time did it save)
  • the single lowest-leverage hour you spent (what was it, why did it recur, what could replace it)
  • one candidate 10x move you did not make but could have

Write the list in one page. Do not let yourself write only positive answers; the missed 10x moves are the point.

Extension: pick one 10x candidate from your list and commit to making the move in the next 14 days. Put it on the calendar. Leverage moves that are not scheduled do not happen.

Transfer / Where This Shows Up Later​

Leverage is the mechanism behind every other concept in this module:

  • Strategy (Concepts 4-6). A Rumelt-structured strategy is a leverage move: one document ranks many later decisions. A now/next/later roadmap is a leverage move against the default (a wish list). A paved-road strategy chooses platform investment as the organization's largest sustained leverage bet.
  • Written-first and influence (Concepts 7-9). The RFC is a leverage artifact. Stakeholder mapping is a leverage move against the default "run around and argue." Disagree-and-commit memos preserve leverage across decisions you lose.
  • Communication (Concepts 10-12). Audience-aware explanation raises the leverage of each artifact by matching it to the reader. An exec summary is the highest-leverage paragraph a Staff+ IC writes - a single sentence can unlock a multi-quarter investment.
  • Growth (Concepts 13-15). Sponsorship is human-scale leverage: one sponsored engineer compounds for years. A personal strategy is meta-leverage - you apply the same audit to your own calendar to avoid becoming a low-leverage senior IC.
  • Across Semester 8. M1's interview-loop investment is organizational leverage. M2's service-decomposition choices determine leverage for the next two years of feature teams. M3/M4 reliability and scale decisions are long-window leverage bets. S10 M5 returns to leverage as the question "where did your career's hours actually multiply?"

Read This Only If Stuck​