In the last lesson I said the staff failure mode is “being busy on work that didn’t matter.” This lesson is the antidote. Two related skills prevent it: operating at the right altitude (and moving between altitudes on purpose), and choosing work by its actual leverage rather than by what feels urgent or looks impressive. Both sound obvious and both are genuinely hard, because the pull toward comfortable, low-altitude, low-leverage work is constant, and it feels productive the whole time you’re wasting your potential on it.
Altitude: the Level You Operate At
Think of your work as happening at different altitudes, like a plane. At the ground you’re reviewing a PR or pairing with someone stuck. Higher up, you’re designing a system. Higher still, deciding what several teams should build over the next year. At the top, you’re thinking about where the business is going.
Two things make altitude a skill rather than just a description:
First, a staff engineer’s center of gravity is higher. A senior engineer lives mostly at the bottom two altitudes: project/design and code. A staff engineer needs to operate comfortably at the top three, system architecture, org strategy, and at least an awareness of company direction, because that’s where the problems worth their time live. If you’re still spending 90% of your time on code and reviews, you may be doing excellent senior work, but you’re not yet doing the staff job.
Second, and more subtle, the skill is moving between altitudes deliberately. The best staff engineers aren’t stuck at any level:
- Stuck too high = the “ivory tower” problem. You pronounce on architecture from 40,000 feet but haven’t touched the code in two years, so your advice is subtly wrong and people stop listening (we’ll return to this in Lesson 12).
- Stuck too low = you’re a very senior engineer who never zooms out, so you optimise one team’s code while the org builds three incompatible systems around you.
The move that marks a staff engineer is dropping down on purpose when it matters, and then coming back up. You spend most of your time at architecture/strategy altitude, but when a critical project is in trouble you parachute down to the code to unblock it (the Solver move), fix the thing, and climb back up. Or you drop into a junior’s PR because that’s where you can teach the most this week. Deliberate altitude changes, not getting trapped at one level.
A practical cue: notice the time horizon of what you’re working on. If everything on your plate resolves within this week, you’ve probably sunk too low. If nothing you’re doing touches the next few weeks concretely, you may be floating too high and losing touch. Healthy staff work has a mix, with the weight on the longer horizons.
Choosing Work: Importance × Reach × Durability
Operating high is necessary but not sufficient; you also have to choose the right work at that altitude. A simple lens:
Before taking on a piece of work, ask three questions:
- Importance: does solving this actually matter to the business or to users? A revenue-blocking bug scores high; a slightly nicer internal dashboard scores low, however fun it is.
- Reach: how many people, teams or systems does it affect? Fixing the deploy pipeline reaches everyone; polishing one team’s helper script reaches a handful.
- Durability: how long does the impact last? An architecture decision shapes years of work; a one-off manual data fix helps for a day.
The best staff projects are high on all three: important, wide-reaching, and durable. A new standard for how services handle authentication, say, is important (security), wide-reaching (every service), and durable (years). Multiply the three and you get something like “total impact”.
The trap this lens exposes is urgent, visible, low-leverage work. Firefighting the same production issue every week feels important and is certainly visible, but if you never fix the root cause, it scores low on durability, you’re reaching for the same low fruit forever. The staff move is to spend a week killing the root cause so the fire stops recurring, even though that week is less visible than heroically firefighting on a Saturday. Visible busywork is the enemy of durable impact.
Leverage: Where an Hour Goes Furthest
Underneath altitude and the impact lens is one idea: leverage. The same hour of your time can produce wildly different total impact depending on where you spend it.
The numbers in that diagram are illustrative, not measured, I made them up to show the shape. But the order of magnitude is real and worth internalising:
- Writing the code yourself produces one engineer-hour of output. That’s the baseline, and it’s what feels most like “real work”.
- Unblocking one person saves them a day and teaches them something, several times the leverage, and it compounds.
- A design doc that steers three teams away from a bad approach can save an entire wrong quarter of work. Dozens of times the leverage of writing code for that hour.
- Fixing the shared library or the “paved road” everyone uses makes every team faster, for years.
- Killing a doomed project early frees a whole team to do something that matters, possibly the highest-leverage thing you can do, and one almost nobody celebrates.
The uncomfortable implication: your biggest impact is rarely your own code. The hour you spend heads-down implementing is, by this measure, usually your lowest-leverage hour, even though it’s the most satisfying and the most legibly “work”. This doesn’t mean never code (you must stay hands-on, Lesson 12); it means be honest that coding is low-leverage time, and spend enough of your week on the high-leverage work that only you, at your altitude and with your context, can do.
Putting It Together: a Weekly Gut-Check
A practical habit: every week or two, look at where your time actually went and ask:
- Altitude: was I mostly in the weeds, or mostly at architecture/strategy, with deliberate drops down? If I was all ground-level, why?
- Leverage: what was the highest-leverage thing I did? Did I do enough of that kind of work, or did it get crowded out by comfortable low-leverage tasks?
- The three factors: of the things I’m about to pick up, which score high on importance × reach × durability, and which just feel urgent?
- The honest one: if I’d done nothing this week, what would actually have broken? (If the answer is “nothing much,” you may be busy, not impactful.)
This isn’t about never doing small things, small things matter and keep you grounded. It’s about making sure the weight of your time is on work that counts, because the default drift is always toward the comfortable and the low-leverage.
Pitfalls to Avoid
- Living at ground level. Doing excellent senior work (code, reviews) but never operating at architecture/strategy altitude.
- Floating in the ivory tower. Pronouncing from 40,000 feet without touching reality; your advice drifts wrong.
- Getting stuck at one altitude. The skill is moving up and down deliberately, not camping at any level.
- Chasing urgent and visible over important and durable. Firefighting the same issue beats fixing it, in visibility but not impact.
- Overvaluing your own code. It’s usually your lowest-leverage hour; spend enough time on the work only you can do.
- Not doing the gut-check. Without it, the default drift is always toward comfortable, low-leverage busywork.
Quick Recap
- Altitude is the level you operate at; a staff engineer works the top three (architecture, strategy, company) and drops down deliberately.
- Stuck too high = out of touch; stuck too low = not doing the job. The skill is moving between levels on purpose.
- Choose work by importance × reach × durability; the best staff projects score high on all three.
- Leverage: the same hour differs by orders of magnitude (illustratively 1x code vs 40x a steering doc vs 200x killing a bad project). Your biggest impact is rarely your own code.
- Do a weekly gut-check: where did my time go, what was highest-leverage, and would anything have broken if I’d done nothing?
Next lesson: the highest-altitude work of all, setting technical strategy and vision, and why most “strategy” is really just a wish list.