The Staff Engineer's Path

The Staff Engineer’s Path — Tanya Reilly (Structured Summary)

Three pillars of the staff+ role, used as the book’s structure: big-picture thinking, execution, leveling up others.

Introduction: Two Paths / The Pillars of Staff Engineering

• Two career tracks: management and “technical”/IC track. Staff+ = the technical-leadership levels above senior.
• “Staff+” (Will Larson’s term) covers staff, senior staff, principal, distinguished, etc. Senior is the “anchor”/tenure level; staff+ is a further, different kind of growth (impact/scope), not “more senior senior.”

PART I — THE BIG PICTURE

Chapter 1: What Would You Say You Do Here?

What is a staff engineer

• Titles matter even in “flat” cultures: they vest authority, signal competency, and counter implicit bias (e.g., women/POC assumed more junior). Title also anchors your next job offer.
• Senior = “tenure” level (can stay there whole career). Staff+ = “technical leadership” levels, roughly equivalent in seniority to manager/director counterparts.

Why organizations need staff+ engineers

• Big-picture thinking: avoids “local maximum” decisions (best for one team, worse for the org). Needs someone with time/context to see across teams; can’t just be the manager or CTO because management is already a full-time job and management authority can overshadow technical judgment.
• Cross-team project leadership: real projects don’t map cleanly onto team boundaries (unlike the idealized “Inverse Conway Maneuver”); someone needs to own the whole outcome, maintain engineering standards, and unblock things that fall in the cracks. Different from a TPM: TPMs own delivery, staff engineers own design/quality.
• Good influence: software has real consequences (safety, business); junior engineers learn norms from the most respected engineers, not policy documents; someone must model high standards. This leadership work must be a formal part of the job, not an add-on to full-time coding.

Axioms of the role

• You’re not a manager, but you are a leader — leadership without direct reports, exercised via design review, technical direction, teaching, reputation. Introverts can lead; jerks cannot.
• You’re in a “technical” role — needs real technical judgment and credibility, but doesn’t necessarily mean heavy day-to-day coding.
• You aim to be autonomous — you help create your own high-impact backlog; you own your time; autonomy requires speaking up if asked to do something harmful.
• You set technical direction — ensuring decisions get made, made well, and documented (not necessarily made by you personally).
• You communicate often and well — most of the job is transferring understanding between brains.

Understanding your role’s shape

• Reporting chain: reporting “high” (director/VP) = broad perspective, less 1:1 attention, learn from watching senior leaders; reporting “low” (line manager) = more focused attention/advocacy, but less influence/context, possible experience mismatch with manager. Use skip-levels to compensate either way.
• Scope: too broad → lack of impact/no narrative, becoming a bottleneck, decision fatigue, missing relationships/mentorship gaps. Too narrow → wasted expertise, opportunity cost, overshadowing juniors, overengineering out of boredom.
• Shape of the role:
  • Depth-first vs. breadth-first work style.
  • Yonatan Zunger’s “four disciplines”: core technical skills, product management, project management, people management — every project needs all four; know which you enjoy/avoid.
  • “Hyperspecialist”/“true IC” path — rare, still needs communication skills, influence wanes without it.
  • How much you want/need to code.
  • Tolerance for delayed gratification (long strategy/culture work has slow feedback vs. coding’s fast feedback).
  • Tech lead manager (TLM) hybrid role — difficult, or “pendulum” between IC and management over time.
  • Will Larson’s “Staff Archetypes”: Tech Lead (partners with managers on execution), Architect (technical direction/quality for an area), Solver (deep dives on one hard problem at a time), Right Hand (extra leadership bandwidth for an org).
• Primary focus: choose work that is genuinely important (“what’s important?”) and that actually needs a senior person (“what needs you?”) — avoid duplicating work junior/mid engineers could do; avoid crowding out others.

Aligning on scope/shape/focus

• Write out your own understanding of your role/goals and share it with your manager to surface mismatched expectations early — better before performance-review time than during it.
• Ultimately “your job” = whatever makes the organization successful, even work with no title match (glue work, physical emergencies, whatever’s needed).

Chapter 2: Three Maps

Three complementary mental maps, all initially obscured (“fog of war”) and uncovered through deliberate attention:

1. Locator Map — “You are here” (perspective)

• Purpose: see your place/scope relative to the wider organization; counteract the natural bias to overweight your local group’s concerns.
• Risks of losing perspective: prioritizing badly (local maximum feels important), losing empathy for other teams’ work, tuning out background problems (“boiling frog”), forgetting the ultimate purpose of the work (and its ethics).
• Techniques for seeing bigger:
  • Take an outsider’s view — deliberately look at your own team as a stranger would; “respect what came before” (Amazon principal tenet) — humility, not license to be dismissive.
  • Escape the echo chamber — build relationships with staff+ peers in other groups/orgs and beyond engineering (product, support, admin); treat other staff engineers as your “virtual team.”
  • Know what’s actually important — company priorities shift over time; know the implicit “objectives that are always true” (survive, pay people, maintain reputation) alongside stated goals.
  • Know what customers care about — measure success from the user’s point of view, not just internal SLOs (“nines don’t matter when users aren’t happy”).
  • Check whether the problem’s been solved before — look for prior art inside and outside the org before inventing something new.
  • Maintain industry-wide perspective via conferences, newsletters, communities.

2. Topographical Map — navigating the terrain

• Purpose: understand organizational culture and structure well enough to move efficiently through it.
• Symptoms of not having this map: good ideas don’t get traction, hidden showstoppers appear late, everything takes longer than expected.
• Culture dimensions (sliders, not right/wrong): secret vs. open information flow; oral vs. written decision culture; top-down vs. bottom-up initiative; fast vs. deliberate change; back-channel vs. front-door communication; allocated (busy) vs. available (slack) teams; liquid vs. crystallized hierarchy/promotion structure.
• Westrum typology of organizational cultures: Pathological (power-oriented, low cooperation), Bureaucratic (rule-oriented, modest cooperation), Generative (mission-oriented, high cooperation/information flow) — generative correlates with better delivery performance (DORA research).
• Points of interest/hazards: chasms (gaps between team cultures, e.g., infra vs. product), fortresses (well-intentioned gatekeepers protecting quality — need sponsorship/tokens to pass), disputed territory (unclear ownership causing power struggles), uncrossable deserts (historically unwinnable fights), paved roads/shortcuts/long ways around (official vs. actually-used paths).
• Decision-making: find “the room where it happens” (formal venue for decisions in your scope); to join, argue org-level impact (not personal career benefit) and reduce the cost of your presence; accept some rooms aren’t for you (comp/perf decisions if you’re IC-track).
• The “shadow org chart” (Fitzpatrick & Collins-Sussman) — informal influence network of “connectors” and “old-timers,” distinct from the formal chart; identify who the real influencers are before pushing for change.
• Keep the map fresh via: announcement channels, “walking the floor”/gemba, lurking (skimming calendars, channel lists, agendas), reading design docs, checking in with leadership, informal conversations across functions (support, admin, etc.).
• If terrain is genuinely broken: be a bridge — connect groups with information gaps, make informal introductions, summarize cross-team status nobody else is sending.

3. Treasure Map — the destination

• Purpose: know where you’re collectively going and why, not just the next milestone.
• Costs of only thinking short-term: hard to keep everyone aligned, big multi-step problems never get finished, accumulate cruft (over- or under-engineering to hedge), competing grassroots initiatives, engineers stop building ownership/growth muscles.
• Use a “technology tree” mental model (Civilization-style): current work is often an intermediate step toward a bigger real goal — keep tracing “why” until you reach the actual objective.
• Sharing the map: story should be comprehensible, relatable (show how it benefits them, not just you), and comfortable (within the org’s current Overton window); tell where you came from as well as where you’re going.
• If no shared treasure map exists (multiple/no destinations), that’s a trigger for the next chapter: creating one.

Your personal journey — foreshadows Chapter 9’s “trail map”: have a narrative of what you’re trying to achieve over time, not just task-by-task.

Chapter 3: Creating the Big Picture

Vision vs. strategy

• Technical vision: describes the desired future state once problems are solved — a “north star”; can be written at any scope; doesn’t need to specify implementation.
• Technical strategy: a plan of action to get there. Rumelt’s “kernel of a strategy”: diagnosis (simplified honest picture of what’s going on), guiding policy (short, clear direction for bypassing obstacles), coherent actions (concrete commitments — implying explicit non-commitments elsewhere).
• Only create these documents if genuinely needed — a simpler goals section or design doc may suffice; adapt scope/format to what the org actually needs.

The Approach (before writing)

• Expect the answer to be “boring”/synthesis, not a flash of genius — most of the work is alignment, not invention.
• If someone’s already working on it: share the lead, follow their lead, or step away — avoid competing “ape games”/politicking.
• Get an executive sponsor (staff+ engineers can’t self-sponsor) — align with their goals, have a tight elevator pitch, and keep checking that sponsorship hasn’t quietly lapsed.
• Choose a small core group (2–4 people) with real time commitment, plus a wider circle of allies/interviewees; be explicit about lead vs. first-among-equals roles.
• Set scope realistically — align with your actual sphere of influence and fixed constraints; avoid “magical thinking” about things outside your control.
• Sanity-check achievability: talk to people who’ve tried similar efforts before investing heavily; if not achievable, options are: proceed blindly, recruit missing skills, shrink scope, accept no strategy is coming (and it’s fine), or accept no strategy is coming (and it’s not fine — reconsider your fit).
• “Make it official” checklist before starting: is it needed, is the answer likely boring, no competing effort (or joined it), org support exists, agreement on the deliverable, problem is solvable by you, and honest about all of the above.

The Writing

• Iterative writing loop (not linear): initial ideas → writing → interviews → thinking time → decisions → alignment, revisited many times; timebox it to avoid endless dragging.
• Initial framing questions: what documents/constraints already exist (inherit from broader scope), what needs to change, what’s already great (don’t lose it), what’s actually important, “what will Future You wish Present You had done” (“sending a cookie into the future”).
• Writing approaches for groups: single leader drafts first (consistent voice, but biased/needs explicit “weakly held” framing) vs. aggregate multiple independent first drafts (unbiased, but risk of ownership/ego fights over whose draft wins — need a clear aggregator).
• Interviewing: cast a wide net beyond your usual circle; ask open questions; always ask “what else should I have asked?”
• Thinking time: differs by person (write, talk, sleep on it, prototype); watch for describing the problem in terms of a pre-chosen solution — keep asking “yes, but why?” until it traces back to the real goal.
• Decision-making:
  • Use “even over” statements to make trade-offs explicit.
  • Seek “rough consensus” (IETF model) rather than full agreement — “can anyone not live with this?” not “does everyone love this?”
  • Not deciding is itself a (usually bad) decision — the status quo; if postponing, decide to postpone and set a deadline/trigger.
  • Document trade-offs and reasoning (“show your work”) so decisions aren’t relitigated.
• Staying aligned: keep sponsor updated at major checkpoints; be realistic (Overton window) about how far you can push; practice “nemawashi” — build consensus quietly before the “vote” so no one is surprised; alignment is bidirectional — be ready to change your plan based on feedback.
• Crafting the story: make it comprehensible (short, coherent), relatable (show benefit to each audience), comfortable (meets people where they are); use bumper-sticker slogans/personas/concrete scenarios; prepare people for the “difficult middle” of the journey, not just the destination.
• Final draft: make it skimmable (images, bullets, white space, personas, concrete scenarios), avoid jargon, prepare a short elevator-pitch version alongside the full doc.

The Launch

• “Official” = endorsed by the relevant top-of-chain authority (email, name on doc, all-hands mention); host it prominently; close open comments; ensure resourcing (headcount/budget) actually follows the plan.
• Keep it fresh — revisit periodically or when context changes; don’t be afraid to iterate publicly if the direction turns out wrong.

PART II — EXECUTION

Chapter 4: Finite Time

• Core constraint: 168 hours/week, always; everything taken on has an opportunity cost.
• Put non-meeting work directly into your calendar as concrete blocks (not vague “focus time”) to make trade-offs visible and to see how much you’re actually deferring recurring tasks (a signal the task may not matter).
• Build a “time graph” for a longer horizon (month/quarter) showing fixed overhead vs. available capacity.
• Know your personal volatility tolerance — leave buffer for unplanned spikes (crises, opportunities) rather than running at 100% capacity.
• Reject the idea of a single global priority queue — importance to the org isn’t the only factor; personal fit matters too.

Five personal resources to track (a “dashboard”)

• Energy: type of work costs differently per person (meetings vs. reading vs. writing); affected by life outside work; watch for “snacking” (low-effort/low-impact busywork when tired) vs. genuine rest; assess whether an “unwinnable fight” is worth the energy.
• Quality of life: enjoyment of the work and colleagues; alignment with personal values; money’s effect on life circumstances.
• Credibility: whether others believe you’re capable; built by solving hard problems, staying technically grounded, being calm/clear; lost through absolutism, chaos, disconnection from “the trenches.”
• Social capital: whether others want to help you; a mutual “bank account” built through reciprocity and delivered results; spend deliberately, don’t squander it on causes you don’t truly care about, be careful lending/borrowing others’ capital (sponsorship risk).
• Skills: constantly decaying as the industry moves; built via deliberate study, working with highly skilled people, or learning-by-doing on relevant projects.
• Weighing a project = a multidimensional “bin-packing” problem across all five resources plus organizational importance — no single formula; some projects are worth taking despite being bad on one axis for other reasons.

Where projects come from (different shapes/costs)

• Invited to join (momentum built-in, but maybe not growth); asking to join (don’t wait to be invited); your own idea (more selling required, more ownership); crisis/“fire alarm” (satisfying but abrupt context switch, hard to build growth narrative if overused); claiming an unowned problem/side quest (momentum builder, but distracts from bigger work); grassroots working groups (can be high-impact or a total time sink — needs buy-in, time commitment, exit criteria, decision process); unowned “someone needs to” work (sometimes worth over-indexing on as the senior person, to shield juniors); “meddling” (unsolicited involvement — avoid “lobbing a water balloon” and disengaging before consequences land).
• Before committing, clarify shape: will it ramp up later, what’s the true time cost (including prep/follow-up), what are the exit criteria, are you joining short- or long-term.

Evaluation questions per resource

• Energy: how many things can you actively care about at once (a rough personal limit); does this type of work energize or drain you; are you using it to procrastinate on something harder (“snacking” quadrant of low-effort/low-impact); is this particular fight worth the energy.
• Quality of life: do you enjoy the actual day-to-day tasks involved (technical/PM/project/people mix); does it align with your values.
• Credibility: does it exercise real technical skill (avoid “ivory tower” perception); does it demonstrate leadership.
• Social capital: does it match what your org/manager expects of your level; will peers respect it; are you spending capital you’ve built without replenishing it.
• Skills: will it teach something you want to learn; will your collaborators raise your game.

If a project is the wrong fit

• Options: do it anyway (only sustainable short-term, and only with a clear exit plan — flag it to your manager if chronic); compensate (add a side project for what’s missing, or “torch the back burner” on lower-priority obligations to make room); let someone else lead (aggressive delegation — a “B” result from someone stretching is a great outcome); resize/reshape the engagement (join partially, for a limited time, as an advisor); or just say no (a skill to practice deliberately — “no” protects future you).
• Defending your time is a core, learnable senior-level skill — demand on it will only increase.

Chapter 5: Leading Big Projects

Starting a project

• Overwhelm at the start is normal and even useful (“discomfort is learning”); ambiguity/difficulty is why it needs a staff+ lead.
• Coping techniques: keep a personal “anchor” document (external brain: uncertainties, leads, to-dos); align early and explicitly with your project sponsor on goals/success criteria/your role; choose who receives your uncertainty (a peer/mentor sounding board, never your junior reports); give yourself a small early win; lean into your natural strengths (code, relationships, docs) as an entry point.

Building context (mapping again, at project scale)

• Goals — the underlying “why,” not just the task; question the project if it won’t actually achieve the goal.
• Customer needs — identify real users (even internal ones) and their actual needs, not assumptions; budget real time for this even without a dedicated PM.
• Success metrics — must be genuinely measurable and agreed with sponsor/stakeholders up front; existence of code ≠ success.
• Sponsors/stakeholders/customers — know who wants this and who’s paying.
• Fixed constraints — deadlines, budget, dependent teams, difficult people; describe reality plainly rather than resenting it.
• Risks — predict what could derail the timeline; mitigate via prototyping, incremental releases, learning from prior similar efforts.
• History — understand why past attempts succeeded/failed and any legacy components/users you must respect (“respect what came before”).
• Team — map the other leaders involved (subleads, PM/EM/TPM counterparts) and build strong working relationships to avoid power struggles.

Giving the project structure

• Define roles explicitly early, e.g. via a responsibility table or RACI matrix (Responsible/Accountable/Consulted/Informed) — prevents both paralysis (no decider) and endless relitigating.
• As lead, you implicitly own any role nobody else is filling.
• Recruit intentionally — look for complementary skills/attitudes (optimism, conflict resolution, communication), not just technical fit.
• Agree on scope using the “fast/cheap/good — pick two” trade-off; break work into milestones/workstreams/phases that each deliver something demonstrable (“beta tests”), enabling course correction.
• Estimate time by experience, not guesswork — small tasks estimate better; involve dependent teams’ planning cycles early; update estimates as you deliver slices.
• Agree on logistics: meeting cadence, informal communication channels, status-sharing format, documentation home, development practices (languages, review standards, testing, deploy process).
• Hold a kickoff meeting for shared momentum even if everything’s already written down.

Driving the project

• Exploring: resist implementation details before the goal/approach is genuinely agreed; align on vocabulary and mental models across teams before designing; build a crisp “elevator pitch” describing what’s in and out of scope; stay open to existing solutions rather than a preconceived one.
• Clarifying complexity for others: build shared mental models via analogies connected to what people already know; build a “ubiquitous language” (Eric Evans) so key terms mean the same thing to everyone; use pictures/diagrams/graphs to reduce cognitive load.
• Designing / RFCs: written designs are cheap iteration; use a template. Minimum sections: Context (title/author/dates/status), Goals (the problem, not the implementation), Design (enough detail for readers to evaluate feasibility — use active voice, name the actor for every verb, avoid ambiguous “this/that”), Security/privacy/compliance, Alternatives considered/prior art (forces engaging with the real problem, not just a favored solution). Optional but valuable: Background, Trade-offs, Risks, Dependencies, Operations.
  • “Wrong is better than vague” — commit to a specific, falsifiable design rather than hedging.
• Common technical-design pitfalls to watch for: assuming the problem is brand-new; underestimating “this looks easy” domains; building only for the present (not future scale/growth) or only for a speculative distant future (overengineering); assuming every user will behave/comply; deferring the truly hard part; solving a small problem in a way that entrenches the bigger one; calling a rewrite something smaller than it is; neglecting operability (monitoring, on-call, debuggability); bikeshedding (spending disproportionate time on trivial, easily-grasped decisions — Parkinson’s Law of Triviality).
• Coding: leads often review more than they write; contributing code deepens understanding and keeps you honest about your own design’s cost, but avoid using coding as a “snack” to dodge harder leadership work; avoid becoming a bottleneck — write in ways that empower others (e.g. set a reusable pattern once, then let the team extend it); pair rather than always doing it yourself, to transfer skill and ownership; hold high personal standards since your work sets the implicit team standard; avoid being a single point of failure in reviews.
• Communicating: build psychological safety for cross-team questions; when sharing status, lead with impact/user-visible facts, not raw detail; be honest — don’t run a “watermelon project” (green outside, red inside); make the “so that we can…” implication explicit.
• Navigating obstacles: assume something will go wrong; as the driver you’re accountable for rerouting/escalating, not just reporting “we’re blocked”; ask for help — struggling silently is the real failure.

Chapter 6: Why Have We Stopped?

Recurring toolkit for any type of blockage: (1) understand and explain, (2) make the work easier, (3) get organizational support, (4) make alternative plans. You can apply this to your own project or to unblock someone else’s (small effort, big leverage) — but still guard your own time/priorities when helping.

Blocked (temporary stalls)

• Blocked by another team — root causes are usually misunderstanding, misadventure (life/staffing problems), or misalignment of relative priority; navigate via direct synchronous conversation, shrinking the ask, offering to help unblock their blocker, escalating respectfully if truly higher priority, or replanning around the gap.
• Blocked by an undecided decision — the decision is often genuinely hard for the other side too; clarify what info they need, reframe the question with examples/pictures, mediate between conflicting stakeholders, or proceed on a documented best-guess with a plan to revisit.
• Blocked by a single approval/button click — the “quick” task competes with many others’ asks; make requests as small/easy/self-contained as possible, be gracious, escalate only as last resort (costs goodwill), or accept the wait.
• Blocked by a single person not delivering — the stated excuse is rarely the real cause (intimidation, overload, unclear ask, competing priorities); dig gently, clarify why the work matters, break work into smaller steps, pair to get them unstuck, escalate to their manager only as a last resort (a real people-management issue).
• Blocked by unassigned/unowned work — a “plate tectonics” gap nobody owns; write a clear “rollup” synthesizing scattered facts into an explicit conclusion; advocate for organizational sponsorship/ownership; treat repeated “next quarter” staffing promises as a signal the work isn’t truly prioritized.
• Blocked by mass adoption (a migration needing many teams) — reduce work required from adopters, automate everything possible, make the new way the default/easiest path, show visible progress metrics, escalate priority organizationally, and as a last resort add friction to the old path or force remaining holdouts to own it themselves.

Lost (no clear path, even without external blockers)

• Don’t know where you’re all going — big ambiguous group efforts get stuck in analysis paralysis; fix by clarifying decision-making roles/authority, choosing (or delegating) a strategy process, picking any concrete problem to start on, or reorienting around a single stakeholder/vertical slice.
• Don’t know how to get there — the problem is just hard; articulate it precisely, question your assumptions (are you fixed on one solution?), give it time (sleep/vacation), carve out real deep-focus time, look for prior art inside/outside the industry, ask others, try a different problem angle, start smaller, ask for help.
• Don’t know where you stand — org/leadership changes create uncertainty about whether your project still matters; clarify organizational support directly, formalize your role/authority (RACI, role doc), ask explicitly for visible backing, and refuel team energy (new milestones, kickoff-style reset) if morale is low.

Arrived somewhere — but not really done

• “Code complete” isn’t the same as usable — “nobody wants to use software, they want to catch a Pokémon”; counter with an agreed definition of done, dogfooding your own work, and celebrating landings (real usage) not launches (internal completion).
• Built but undiscovered (“Beware of the Leopard” problem) — internal tools die from lack of marketing; actively “sell” the solution (repeated communication, discoverability, testimonials, road shows), don’t just document once and stop.
• Built on a shaky foundation — shipped-fast solutions accumulate technical debt that never gets revisited; counter by modeling a quality culture, framing cleanup as a user story, and negotiating dedicated engineer-led cleanup time.

Deliberately ending a project

• “This is a better place to stop” — declare success and move on once further investment isn’t worth it (watch for the local-maximum trap of over-polishing).
• “Not the right journey” — recognize the sunk-cost fallacy; cutting losses on a genuinely doomed direction is a success, not a failure, if done honestly with a retrospective.
• Canceled by outside forces — acknowledge the team’s feelings, deliver the news yourself (not via gossip/all-hands), protect people’s career narratives/promotion cases, clean up remnants, retrospective if useful.
• True completion — verify metrics/usability/foundation actually hold before celebrating; mark the occasion, retrospective on what went right too, highlight desired cultural behaviors that showed up.

PART III — LEVELING UP

Chapter 7: You’re a Role Model Now (Sorry)

• Passive influence: whatever you actually do (not stated values) becomes the implicit standard others emulate — promotions, reviews rewarded, and behaviors tolerated define real culture.
• Being a role model doesn’t require being loud/extroverted — quiet, consistent competence and collaboration count; it’s a learnable, buildable skill, not an identity.

Be competent

• Know things: technical skill comes from sustained deliberate practice/experience, not innate talent; avoid rushing out of hands-on technical work too early in your career (management or staff+ role) — you may cheat yourself of prime skill-building years.
• Build domain knowledge quickly when moving into a new area — use broad pattern-matching from past experience as “hooks,” study core literature, learn the players/jargon, then get hands-on.
• Stay up to date — keep your instincts current even if you’re not writing much code; avoid learning only “how your company works” rather than the underlying tech.
• Model visible learning — explain your reasoning/sources so it’s safe for others to admit gaps too.
• Be self-aware: know and state confidently what you do know (without needing to be “best in the industry”); openly admit what you don’t know (ask for “ELI5”s); understand that your own perspective/context isn’t universal — this is what lets you translate across audiences.
• Have high standards: actively seek constructive criticism (request reviews, don’t resent them); own mistakes fully (admit, fix, protect innocent colleagues from misplaced blame, consider a retrospective) rather than deflecting; be reliable — the highest compliment is “I don’t need to be there because X will handle it,” and reliability includes seeing things through to completion.

Be responsible

• Take ownership: own the whole problem including the messy unglamorous parts; avoid “Cover Your Ass Engineering” (CYAE — hiding behind narrow specs); “radiate intent” (signal what you’re about to do) rather than either asking permission or acting in secret — it keeps you accountable while allowing intervention.
• Make decisions and own being wrong; ask the “obvious” questions nobody else will risk asking; avoid “delegating through neglect” — recognize invisible “glue work” (coordination, onboarding, unblocking) and don’t let it silently fall on junior people who need technical growth time instead.
• Take charge: explicitly claim coordination during emergencies (Incident Command System model) — silent coordination doesn’t work; ask “dumb” clarifying questions on others’ behalf during confusion; drive meetings (agendas, notes — note-taking is high-status glue work, not administrative drudgery); speak up publicly when something disrespectful/harmful is said (support the target publicly; it doesn’t have to be perfectly worded, just said) and separately flag patterns to the person’s manager.
• Create calm: defuse rather than amplify problems; stay curious and blame-free when investigating mistakes (what info was missing, where did mental models diverge); be consistent/predictable so colleagues know what to expect from you, which requires managing your own sustainability (rest, boundaries).

Remember the goal

• Remember there’s a business: standards (speed vs. stability) must adapt to context (hackathon vs. life-critical system, outage vs. normal operations); be aware there’s a finite budget/headcount and that spending it is a real trade-off (Dan McKinley’s “innovation tokens”); know when “good enough” is actually done.
• Remember there’s a user: build for real, observed users and requirements, not “perfectly spherical” imagined ones; share mockups/APIs early; avoid CYAE — meeting the spec doesn’t matter if the user’s need isn’t met.
• Remember there’s a team: don’t become a single point of failure by grabbing every hard problem; measure your impact by what wouldn’t have happened without you, including what you enabled others to do.

Look ahead

• Anticipate what Future You/the team will wish you’d done: telegraph upcoming changes (e.g., announce future deprecations early even before ready) so others can plan; tidy up your working environment for whoever comes next; continually invest in tooling/velocity (build speed = shorter every future outage); create institutional/written memory (decision records, system histories, comments with real context) since staff turnover is inevitable.
• Expect failure: assume unpredictable failures will happen (even from unrelated systems); build tested error paths, practiced incident response conventions, chaos/game-day drills, and verified backups.
• Optimize for maintenance, not creation: software is “programming integrated over time” — spend real effort making systems understandable (short docs, tracing/observability, one big picture diagram) and simple (a first solution is “just the first” — invest in a simpler second pass; contain unavoidable complexity in one well-chosen place rather than scattering it); design components to be easy to decommission later (clean interfaces, visibility into remaining clients).
• Create future leaders: give juniors room to do the hard/interesting work themselves rather than doing it all yourself. Ultimate metric of success (John Allspaw): whether other people want to work with you.

Chapter 8: Good Influence at Scale

Why scale your influence: better colleagues make your own work easier; the industry keeps changing and adoption of new practices needs teaching; and it’s simply the right thing to do — standards you instill propagate for generations of engineers.

Three tiers of influence (individual → group → catalyst) across four mechanisms (advice, teaching, guardrails, opportunity) — a matrix of options, not a checklist; don’t neglect small-scale (individual) influence in favor of chasing “catalyst”-level programs.

Advice

• Distinguish solicited vs. unsolicited advice; ask permission before giving unsolicited advice unless there’s a safety/critical-information reason; in mentoring conversations, first check whether the person wants advice or just wants to vent/think aloud.
• Individual: mentoring (share your own experience, but be aware your specific tactics may not transfer across identity/context/seniority gaps); answering questions generously (don’t withhold adjacent useful info); giving both praise and honest critical feedback on drafts/talks; peer/performance reviews — write for both the recipient’s growth and the calibration audience, and watch for biased language patterns (e.g., “abrasive” vs. “assertive”).
• Group: scale advice via writing (docs, FAQs, blog posts), and via talks/presentations — look for a “microphone and an audience” moment to deliver a message.
• Catalyst: build structures so people advise each other without you — encourage written documentation culture, or set up recurring tech talks/mentorship programs (note: heavier admin overhead than expected).

Teaching (deeper than advice — for internalized understanding, not just information transfer)

• Individual: define a clear goal for what the learner should be able to do afterward; use hands-on/active learning; use the shadowing → pairing → reverse-shadowing spectrum depending on skill transfer needs.
• Code/design review as teaching: understand what stage/purpose the review serves; explain “why” not just “what”; give concrete examples of a better alternative; explicitly flag severity (blocking vs. nitpick vs. preference); review in passes (high-level first); explicitly say “yes”/approve when you mean it, especially so juniors aren’t left waiting on ambiguous silence.
• Coaching (distinct from mentoring): teaches people to solve problems themselves rather than sharing your own experience. Core skills: asking open questions, active listening (reflecting back), making space (tolerating silence) — resist jumping in with your own answer.
• Group: build reusable teaching materials (classes, codelabs) with the same clear-outcome, hands-on principles — high upfront cost, amortized over repeated use.
• Catalyst: teach other people to teach (hand off ownership of the class/curriculum); fold materials into official onboarding so influence continues without you.

Guardrails (let people move autonomously and safely)

• Individual: rigorous code/design/change review — check whether the work should exist at all, whether it actually solves the problem, how it fails, whether it’s maintainable/observable, whether it sets a bad precedent, and whether the right people are informed. Never rubber-stamp.
• Being a “project guardrail” for a colleague stretching into a harder project — ask pointed but supportive questions, and be explicit about how/when they should ask you for help.
• Group: written processes/checklists for recurring risky situations (launches, incidents, tech adoption) — keep them lightweight or people will route around them; written decisions once-and-for-all (style guides, “paved road”/tech-radar lists, policies, technical vision/strategy) reduce repeated debate; make the right way easy via automation (“robots and reminders”: automated reminders, linters, discoverable search results, templates, config checkers/presubmits).
• Catalyst: true culture change — the most durable but hardest guardrail; requires solving a real problem (not aspirational), choosing your battles, offering real support/tooling, and finding allies (including via the shadow org chart).

Opportunity

• Individual: delegation — hand off real, messy ownership (not pre-solved “gift-wrapped” tasks) matched to a stretch-but-achievable level; redirect follow-up questions to the new owner rather than staying the de facto point of contact.
• Sponsorship (Rosalind Chow’s “ABCDs”): Amplifying (publicizing good work), Boosting (recommending/endorsing), Connecting (introducing to networks), Defending (countering unfair criticism) — watch for in-group/“mirrortocracy” bias in who you sponsor.
• Connecting people to opportunities just by knowing information exists (a role opening, a CFP, a training program).
• Group: share the spotlight deliberately — hand off the floor in meetings, bring juniors into review/decision conversations, let others’ work (not just yours) be visible; avoid the opposite failure mode of delegating so much that your own contribution becomes invisible to your management chain.
• Catalyst: build durable structures for opportunity/sponsorship (inclusive interviewing, open internal job boards) so growth continues without your direct involvement — ultimately “growing the people who will grow the next people.”
• Reframe: being promoted past you (or people entering your level with less polish than you now have) isn’t lowered standards — they only need to be as good as you were when you were first promoted.

Chapter 9: What’s Next?

The trail map (4th map): your own career

• Don’t just follow well-marked local trails (obvious next promotions/roles) — deliberately choose destinations, even unconventional ones, based on your own priorities.

Clarify what’s important to you (illustrative, non-exhaustive list): financial security, supporting family, schedule flexibility, deep learning/mastery, visibility/industry recognition, doing exciting work, self-challenge, wealth building, working independently, making a broader difference, enabling an outside vocation. Priorities shift over a career and there’s no universally “right” list.

Invest deliberately in

• Skills — treat gaps as “not yet leveled up,” not permanent limitations; be honest that not everything is worth the time investment; watch for imposter syndrome (extremely common even at staff+ level) and choose to build skills that align with what genuinely energizes you (sustainable long-term learning).
• Network — most opportunities come through relationships, not postings; a strong network means access to advice, expertise, and unlisted opportunities; networking is a learnable mechanical skill, not an innate trait.
• Visibility — let people see your work (internally and, optionally, externally via talks/writing/open source) so they think of you for opportunities; treat any visibility opportunity you accept seriously (don’t waste it).
• Deliberate role/project choice — you get typecast by what you spend time on; choose roles for the specific experience/skills/reputation they’ll build toward your goals, not just convenience.

Evaluate your current role

• Cate Huston’s five job-health metrics to track over time (not just a single bad week): are you learning; are the skills transferable (vs. only coping with local dysfunction); how do you feel recommending friends join; how’s your confidence trending; how’s your stress/health. Employers “rent” your market-value “brand” — a bad job can quietly erode future employability.
• Explicitly compare your role against your priority list — no role is optimal on every axis; identify what’s genuinely missing versus what’s a reasonable trade-off.

Reasons to stay put vs. reasons to move

• Stay: feedback loops from seeing your own decisions play out, deep domain expertise, built relationships/trust, learned organizational context, life/schedule fit.
• Move: risk of learning only “how this org works” rather than transferable skills, limited remaining experiences/mentors at one place, sometimes easier to gain scope/level or salary by moving, mismatch between your goals and what your org needs.

Paths onward (a non-exhaustive menu)

• Stay and keep doing the same thing (fine if it’s still meeting your needs — but keep skills minimally current).
• Work toward promotion — clarify what specifically you want from it (money, prestige, scope, respect) since the title itself may not deliver everything you’re hoping for; understand your org’s actual promotion mechanics.
• Work fewer hours (reduced schedule) — be deliberate about which responsibilities shrink, and align expectations explicitly with your manager/team.
• Change teams internally — retain relationships/context/credibility while getting a fresh problem; brings valuable cross-team perspective to the new team.
• Build a new specialty/adjacent skill, potentially crossing into another track (e.g., product).
• Explore via rotations/short-term embeds before committing.
• Move into management — Charity Majors’s “engineer/manager pendulum” (don’t try to grow both skill sets at once; commit a genuine ~2-year tour if trying management, since switching too often is disruptive to reports); taking your first reports may mean starting as a line manager even after operating at higher IC scope.
• Find or invent a bespoke niche role shaped around your specific strengths (only viable with real trust/standing, and the org’s genuine need); watch out for a role that’s flattering/prestigious but not actually enjoyable.
• Change employers for the same role (best done deliberately, not as a reactive “rebound” from a bad situation); ask precisely what “staff+” means at the new org since titles vary widely.
• Change employers to go up a level — easier when your domain expertise already transfers.
• Change employers to go down a level deliberately — can rebuild technical grounding, offer better fit, without being a failure.
• Start your own company, or go independent (consulting/contracting) — both benefit from a pre-built network and a financial cushion; independence trades security for control/variety and requires being your own generalist support structure.
• Change careers entirely, applying technical experience to a different field.
• Whenever you do move: expect to reset and rebuild all three organizational maps (locator, topographical, treasure) from scratch, and adapt your leadership style to the new org’s actual needs rather than replaying your last job’s playbook.

Closing message

• Software has real, sometimes life-critical consequences; take the responsibility seriously without losing the fun of the craft; senior engineers set the tone for the whole industry’s future — “build good software, build a good software career, build a good software industry.”