Skip to main content

Working at the Right Altitude

What This Concept Is​

Altitude is the level of abstraction your work is operating at today. Three altitudes matter for a Staff+ engineer:

  • Code altitude. Lines, functions, PRs, one service. The question is "does this work and is it correct?"
  • Systems altitude. Service boundaries, interfaces, data flows, one or two teams. The question is "does this fit, scale, and survive the known failure modes?"
  • Strategy altitude. Many teams, quarters or years, investment choices, organizational constraints. The question is "what should we be doing, and what should we stop doing?"

A Staff+ engineer spends time at all three altitudes but not in equal amounts and not interchangeably.

Why It Matters Here​

The single most common Staff+ failure mode is being stuck at the wrong altitude:

  • stuck at code when the team needs strategy (you become the bottleneck on PR review)
  • stuck at strategy when the team needs code (nothing ships and your opinions start sounding disconnected from reality)
  • bouncing altitude per meeting, which is exhausting and produces shallow work at every level

Altitude is different from importance. A three-line bug fix can be the highest-value code-altitude work you do all quarter if it unblocks the org. A six-month "platform strategy" can be the lowest-value strategy-altitude work you do all year if it is divorced from capacity.

Concrete Example​

Pick one problem: "Our deploy pipeline is flaky and a release takes 90 minutes."

  • At code altitude you open the pipeline, find the two flakiest tests, stabilize them, shave 20 minutes.
  • At systems altitude you ask why the pipeline runs a 40-minute integration suite on every commit. You propose splitting fast unit tests from slow integration tests, parallelizing, adding caching. Shave 60 minutes.
  • At strategy altitude you ask whether the whole organization's release topology (one monorepo, one pipeline, one environment) matches the team structure. You propose a multi-pipeline model and negotiate the investment with platform leadership.

All three are legitimate. All three have different timelines, different stakeholders, and different artifacts. A Staff+ engineer who only ever operates at one of these three has a narrower job than the role requires.

Common Confusion / Misconception​

"Higher altitude is better." No. Higher altitude is different, not superior. An Architect who never drops to code altitude produces ungrounded strategy. A Tech Lead who never raises to strategy altitude gets blindsided by decisions made above them.

"Altitude is the same as seniority." No. A mid-level engineer investigating a production incident is doing code-altitude work at that moment; the Staff+ engineer paired with them may be at systems altitude in the same conversation. Altitude describes the work, not the person.

"The role decides the altitude." Only partly. Role sets the center of gravity. Day-to-day, you still choose which altitude each meeting, doc, and PR should live at - and you are responsible for calling it out when the group is at the wrong one.

"Going higher takes less effort because the details fall away." The opposite. Strategy altitude is harder because the feedback loop is longer: you will not know if the investment call was right for two to four quarters. At code altitude the test runs in seconds; at systems altitude the design review tells you in a week; at strategy altitude you get punished or rewarded next year. Higher altitude is harder because the feedback is delayed.

A Short Script: Naming Altitude in a Meeting​

One of the highest-leverage moves a Staff+ engineer makes is to notice, out loud, that a room is at the wrong altitude.

PM: "We've been arguing about this retry policy for 20 minutes."

You: "I think we're mixing altitudes. The retry-policy choice is a code-altitude decision the on-call engineer can make in 30 minutes. The real question in this room is a systems-altitude one: should this service be doing synchronous retries at all, or should it be event-driven? Can we split the conversation? I'll take the code-altitude piece offline; let's spend the remaining 10 minutes on the systems-altitude framing."

The room usually relaxes. People were arguing because they were at different altitudes without realizing it, not because they disagreed.

Altitude Switching Costs​

Altitude changes are not free. Each switch has a setup cost: loading the relevant context, remembering the stakeholders, re-reading the relevant doc. A day with six altitude switches produces less than a day with two.

  • Batch altitude where possible. Do all systems-altitude reviews in one block. Do strategy work in one uninterrupted morning.
  • Protect one altitude per day if you can. Mondays can be strategy; Tuesdays can be systems; Fridays can be code.
  • If every day is every altitude, the calendar is the problem, not you.

A useful rule: each altitude transition costs roughly 20-30 minutes of productivity you will never recover. Budget transitions the way you budget meetings.

A second useful rule: the higher the altitude, the longer the minimum useful block. Code altitude tolerates 30-minute slivers. Systems altitude usually needs 90+ minutes. Strategy altitude needs half a day or the output is shallow.

A third useful rule: the later in the day you try to do strategy-altitude work, the worse it gets. Strategy altitude is the altitude most affected by fatigue because its feedback loop is delayed - you can produce bad strategy and not notice until next quarter. Schedule it in your first working block of the day and guard the slot.

How To Use It​

Run the altitude check before joining a meeting or writing a doc:

  1. What altitude is this question asking about? Is it a correctness question, a fit question, or an investment question?
  2. What altitude is my draft answering at? Are they matched?
  3. If mismatched, which one moves? Usually the draft, sometimes the question.

Altitude Failure Patterns​

Three recurring anti-patterns show up in Staff+ altitude work:

  • Altitude hoarding. A senior IC refuses to drop to code altitude ("that's an IC job") and refuses to rise to strategy altitude ("that's a manager's job"). They live permanently at systems altitude, reviewing every design, and the organization under-uses them. Fix: renegotiate the role or add one half-day of each missing altitude per week.
  • Altitude-washing. A code-altitude decision is re-framed as "strategic" to make it feel important. Symptom: a three-page document about which Kubernetes ingress controller to adopt. Fix: rewrite it as the 10-line ADR it actually is.
  • Altitude churn. Every meeting is a different altitude and the engineer burns context-switch overhead for the whole day. Output drops 40% without any visible slacking. Fix: redesign the calendar, not the engineer.

Naming the pattern is most of the fix. Altitude is a short vocabulary that makes an otherwise invisible problem visible.

Check Yourself​

  1. Name a recent meeting where someone was at the wrong altitude. Which one were they at? Which one should they have been at?
  2. Pick your current top three work items. What altitude is each operating at?
  3. What fraction of your week should be at strategy altitude given your role? What fraction actually is?

Mini Drill or Application​

Pick one recurring problem your team has had for more than a month. Write three paragraphs, one at each altitude:

  • Code altitude (150 words): what would you change in the next week of engineering work?
  • Systems altitude (200 words): what would you redesign in the next quarter?
  • Strategy altitude (250 words): what organizational or investment choice would make the first two unnecessary?

Notice which paragraph was hardest to write. That is the altitude your current habits most avoid.

Extension: swap with a peer. Have them critique your strategy-altitude paragraph for anything that could be cut-and-pasted to another company. If large chunks survive the swap, the paragraph was at the wrong altitude - generic advice dressed up as strategy.

Transfer / Where This Shows Up Later​

Altitude is the hidden variable behind most decisions in the rest of this module:

  • Leverage (Concept 3). Leverage moves cluster at specific altitudes - force multipliers at systems, strategy memos at strategy, teaching moments at code. A leverage audit that ignores altitude double-counts low-value hours.
  • Strategy artifacts (Concepts 4-6). Rumelt's kernel is a strategy-altitude artifact; a roadmap is a systems-altitude translation; a coherent action item is a code-altitude commitment. Mixing altitudes inside one document is the single most common cause of "vague strategy" complaints.
  • Written-first and stakeholder work (Concepts 7-9). An RFC is a systems-altitude artifact; an exec memo is a strategy-altitude artifact; a PR review is a code-altitude artifact. Disagree-and-commit only works if the disagreement is registered at the same altitude as the decision.
  • Communication (Concepts 10-12). Audience-aware explanation is largely "translate across altitudes." The exec summary compresses systems and code details into a strategy-altitude sentence. An architectural story restores systems altitude to a flattened inventory.
  • Feedback and personal strategy (Concepts 13-15). Feedback itself has an altitude: "your PR had a bug" is code altitude; "your RFCs assume a centralized platform that we've decided to move away from" is strategy altitude. The latter is higher-stakes and easier to mis-deliver at lower altitudes.
  • Semester 8 and beyond. Altitude governs M1 (interview question scope), M2 (service boundaries as systems-altitude choices), M3 (reliability tradeoffs at strategy altitude), M4 (scale-out decisions as one-way strategy doors). Semester 10 M5 on career navigation is itself a strategy-altitude personal exercise.

Read This Only If Stuck​