Book Overflow · Published 2025-12-08

Will Larson Reflects on Staff Engineer

privateReview: unreviewedConfidence: high
staff engineerarchitecturemigrationsstrategyleadershipstaff-engineerinterface-decouplingreward-hackingpermission-scopingtechnical-leadershiprollout-sequencingorganizational-design
Open on YouTube ↗

Summary

Overview

  • Speaker: Will Larson
  • Channel: Book Overflow
  • Main topic: Staff engineering role, engineering strategy, and organizational dynamics
  • Purpose: Provide software engineers and leaders with deep insights into staff engineering roles, career navigation, and organizational strategy. Carter Morgan and Nathan Toups interview Will Larson, author of 'Staff Engineer' and 'Crafting Engineering Strategy,' reflecting on the realities of the staff engineering role, organizational structures, anti-patterns, mentorship vs sponsorship, and migration management.

Topic Map

Introduction and Background

  • Explanation: Introduction of Will Larson and discussion of when 'Staff Engineer' was written.
  • Key claims:
    • The book 'Staff Engineer' was written around 2020 and published in early 2021.
  • Examples:
  • Terminology:
    • Staff Engineer
  • Why it matters: Sets context for how the industry viewed staff engineering roles during the zero-interest-rate era.

The Nature of Staff Engineering Roles

  • Explanation: Discussion on how staff engineering roles emerge in rapidly growing companies and the common mismatch in expectations.
  • Key claims:
    • Industries rarely just give you what you want, but you can create the thing you want.
    • Many companies introduce staff engineering roles without anyone who has worked in a true staff engineering role before.
  • Examples:
    • Small companies with 20 engineers and 4 staff engineer titles where work is fundamentally senior engineer work.
  • Terminology:
    • Staff Engineer
    • CTO
    • Senior Engineer
  • Why it matters: Helps engineers understand that title inflation and role definitions often diverge from actual responsibilities.

Productivity, Preening, and Snacking

  • Explanation: Exploring pseudoproductivity, preening (high-visibility, low-impact work), and snacking (easy, low-value work).
  • Key claims:
    • Preening is doing high-visibility, low-impact work that gets you promoted but is bad for the organization.
    • Snacking is starting new things because they are easy, while finishing difficult migrations is hard.
  • Examples:
    • Starting a new database is easy; getting everyone off the old database is hard.
  • Terminology:
    • Pseudoproductivity
    • Preening
    • Snacking
    • Migrations
  • Why it matters: Distinguishes between actual organizational impact and busywork that feels productive.

Mentorship vs. Sponsorship

  • Explanation: Evaluating the differences between mentorship and sponsorship in engineering careers.
  • Key claims:
    • Mentorship focuses on guidance, while sponsorship involves a manager or leader actively fighting for your career advancement.
    • In many large tech companies, you may not even interview with the person who ultimately manages you.
  • Examples:
    • Will Larson having 7 managers in 3 years at Silicon Valley companies.
  • Terminology:
    • Mentorship
    • Sponsorship
    • Management
  • Why it matters: Highlights how career progression relies heavily on finding the right advocates and sponsors.

Migration Strategy and Architecture

  • Explanation: Best practices for managing complex software migrations and avoiding architectural pitfalls.
  • Key claims:
    • Start by migrating something easy before tackling something really hard.
    • If a migration is going to fail, you want it to fail early to preserve optics and momentum.
  • Examples:
    • Uber's monolith deconstruction project moving from Python/Flask to Python, Go, and Node.
  • Terminology:
    • Decomposition
    • Monolith
    • Microservices
    • Continuous Integration
  • Why it matters: Provides tactical advice for executing large-scale technical changes without destroying engineering morale.

Key Points

Authority without Friction

  • Explanation: As you become more senior, you gain authority, but valid ways of using that authority narrow to avoid friction.
  • Evidence: CTOs have infinite authority in theory, but extremely limited ways to act without getting fired.
  • Practical implication: Senior engineers must balance their authority with organizational alignment and influence.

The Importance of Asking Questions

  • Explanation: The number one underutilized tactic in a new job is simply asking questions instead of assuming you know everything.
  • Evidence: New engineers often fail to ask existing team members whether a proposed change is a good idea.
  • Practical implication: Asking questions early prevents redundant mistakes and builds alignment.

Design for Extensibility

  • Explanation: Good interfaces allow you to change things under the hood cheaply and quickly.
  • Evidence: Complex systems like GraphQL require decoupling interfaces from underlying implementations.
  • Practical implication: Invest in clean interface design to make future refactoring feasible.

Frameworks, Models & Processes

Preening vs. Snacking Framework

  • How it works: Categorizes counter-productive engineering behaviors into preening (visibility without impact) and snacking (easy wins over hard migrations).
  • Components:
    • Preening
    • Snacking
    • High-visibility low-impact work
  • When to use: Evaluating personal productivity and organizational value delivery.

Examples & Case Studies

Uber moving its giant Python/Flask monolith into a mix of Python, Go, and Node across thousands of engineers.

  • Illustrates: The immense challenge of large-scale technical migrations at hyper-growth scale.
  • Lesson: Decomposing monolithic systems requires careful sequencing and extensive architectural planning.

Actionable Takeaways

  • Immediate:
    • Ask more questions when starting a new engineering role.
    • Focus on finishing difficult migrations rather than starting new, easy projects.
  • Strategic:
    • Design software architectures for extensibility and decoupled interfaces.
    • Build sponsorship relationships with leaders who can advocate for your career.
  • Questions to investigate:
    • How do you evaluate whether a technical migration is actually worth the organizational cost?
    • What is the right balance between autonomy and architectural alignment in staff engineering?

Claims Worth Verifying

  • Most engineers entering staff roles have never worked in a true staff engineering role before. (industry observation)

Notable Quotes

"Industries rarely just give you what you want, but you can create the thing you want."

Compressed Summary

  • Staff engineering roles require navigating organizational complexity and leadership alignment.
  • Avoid preening and snacking in favor of completing difficult migrations.
  • Good architecture prioritizes decoupled interfaces and extensibility.
  • Keywords: staff engineer, architecture, migrations, strategy, leadership
  • Core insight: Staff engineering success requires balancing technical excellence with organizational influence and navigating complex migrations without falling into pseudoproductivity.

Core insights

6
Mental Modelmedium noveltymoderate evidence

Pseudoproductivity splits into two distinct failure modes with different reward structures: 'preening' — high-visibility, low-impact work that advances the individual but harms the organization — and 'snacking' — repeatedly starting easy new things instead of finishing hard, unglamorous migrations. These are not the same failure and require different countermeasures: preening needs impact-weighted evaluation; snacking needs completion incentives and sequencing discipline.

Why it matters

Agentic and platform work has an analogous reward-hacking surface: a system (or engineer) can generate high-visibility artifacts — demos, new subsystems, new tooling — while the hard, load-bearing work of finishing migrations, deprecating paths, and closing loops goes undone. Separating visibility-driven from ease-driven behavior determines whether you fix incentives or fix sequencing.

Generalization

Any system optimizing a proxy metric (visible output, new artifacts shipped) while carrying a long-tail of unfinished transitions will drift toward preening and snacking; measure completion of hard transitions, not initiation of easy ones.

Preening is doing high-visibility, low-impact work that gets you promoted but is bad for the organization.
Open source video
Snacking is starting new things because they are easy, while finishing difficult migrations is hard.
Open source video
Starting a new database is easy; getting everyone off the old database is hard.
Open source video
Practicemedium noveltymoderate evidence

Migration execution order is itself a risk-management mechanism: migrate something easy first, and deliberately structure the effort so that a doomed migration fails early. Failing early is framed as preserving optics and momentum rather than merely saving cost — the social/organizational capital of the project is treated as a finite resource to be protected.

Why it matters

Large platform, model, or infrastructure transitions (agent runtime swaps, context/memory backends, tool-protocol changes) fail on adoption, not on the first technical step. Sequencing an easy win first and engineering an early-failure signal turns migration into an incremental rollout with a kill decision point rather than a sunk-cost march.

Generalization

For any long-horizon system transition, front-load a low-risk pilot and an explicit early-failure criterion so that abandonment is cheap and defensible; treat momentum and credibility as depletable resources to budget.

Start by migrating something easy before tackling something really hard.
Open source video
If a migration is going to fail, you want it to fail early to preserve optics and momentum.
Open source video
Tradeoffhigh noveltymoderate evidence

Authority and available action are inversely related at senior levels: authority grows, but the set of uses of that authority that don't create organizational friction shrinks. The CTO case is the extreme — theoretically unlimited authority, practically near-zero moves that don't risk termination.

Why it matters

This inverts the naive model where more capability equals more optionality. Applied to agent systems, granting a component broader permissions (tools, filesystem, network, spend) does not proportionally broaden safe action; it narrows the set of actions that don't trip blast-radius, audit, or trust constraints. Capability grants and legitimate action space must be designed jointly, not conflated.

Generalization

As a principal's blast radius grows, the set of permissible actions shrinks; permission design is about the intersection of capability and non-friction, not the union.

As you become more senior, you gain authority, but valid ways of using that authority narrow to avoid friction.
Open source video
CTOs have infinite authority in theory, but extremely limited ways to act without getting fired.
Open source video
Architecturemedium noveltymoderate evidence

Interface/implementation decoupling is the mechanism that makes cheap refactoring possible: good interfaces let you change what's underneath quickly and without counterparties noticing. GraphQL is cited as a system that requires explicitly decoupling the interface from the underlying implementation.

Why it matters

In agent and tooling stacks the interface is often the schema handed to the model (tool signatures, response envelopes, memory APIs). If that interface is entangled with the current implementation, every backend change — new model, new retriever, new vector store — forces re-prompting, re-evaluation, and re-training of callers. Decoupled interfaces make backend substitution a local change.

Generalization

Wherever a model or external caller consumes a contract, budget design effort to make the contract implementation-agnostic; the value of the abstraction is measured by how cheaply the implementation behind it can be replaced.

Good interfaces allow you to change things under the hood cheaply and quickly.
Open source video
Complex systems like GraphQL require decoupling interfaces from underlying implementations.
Open source video
Empirical Resultmedium noveltymoderate evidence

Roles and titles are frequently instantiated before anyone has held the role, producing definitions that diverge from actual work (e.g. small orgs with many staff titles doing senior-engineer work). The role is created by demand and imitation rather than by precedent.

Why it matters

Emerging agent/platform roles (agent-reliability engineer, context engineer, harness owner) are likely to be defined before practitioners exist, so job descriptions, evaluation criteria, and org boundaries will be wrong by default. Designing the workflow and interfaces first — then naming the role — avoids baking a wrong abstraction into staffing and ownership.

Generalization

When a new function is introduced without precedent, expect definition drift; anchor the new role to concrete workflows and interfaces rather than to the title's inherited connotations.

Many companies introduce staff engineering roles without anyone who has worked in a true staff engineering role before.
Open source video
Small companies with 20 engineers and 4 staff engineer titles where work is fundamentally senior engineer work.
Open source video
Practicelow noveltyweak evidence

The single most underutilized onboarding tactic is asking questions rather than assuming prior knowledge; new engineers commonly fail to ask existing team members whether a proposed change is a good idea.

Why it matters

Directly transferable to agent design: a system entering an environment with existing state, history, and constraints should query that state (registries, owners, prior decisions) before acting, rather than assuming a change is safe. This is a cheap, high-yield mechanism against redundant or contradictory action.

Generalization

In unfamiliar environments, cheap epistemic actions (asking/querying) should precede expensive mutating actions; the failure mode is acting on assumed knowledge the environment already holds.

The number one underutilized tactic in a new job is simply asking questions instead of assuming you know everything.
Open source video
New engineers often fail to ask existing team members whether a proposed change is a good idea.
Open source video

Deep dives

5

Detecting preening vs snacking in automated agent pipelines

Research question

If an agent system is rewarded for visible artifacts (new tools, new subsystems, demos) rather than completed transitions (deprecations, path consolidation), does it systematically drift toward preening and snacking, and can the two failure modes be separated by evaluation signal alone?

Why

Preening and snacking have different remedies — impact-weighted evaluation versus completion incentives and sequencing discipline — so conflating them produces a fix for the wrong failure. Agent and platform work shares the same reward-hacking surface: visibility is cheap to generate, completion of hard transitions is expensive and unglamorous.

Preening is doing high-visibility, low-impact work that gets you promoted but is bad for the organization.
Open source video
Snacking is starting new things because they are easy, while finishing difficult migrations is hard.
Open source video
Starting a new database is easy; getting everyone off the old database is hard.
Open source video
Source video

Capability grants versus legitimate action space under blast radius

Research question

Can usable action space for a principal (human or agent component) be measured as a shrinking function of blast radius, such that permission sets are the intersection of granted capability and non-friction action rather than the union?

Why

The naive model equates more capability with more optionality; the seniority observation inverts it. For agent stacks this means broadening tools, filesystem, network or spend access does not proportionally broaden safe action — it narrows the set of actions that do not trip audit, blast-radius or trust constraints. Permission design must therefore be joint with capability design.

As you become more senior, you gain authority, but valid ways of using that authority narrow to avoid friction.
Open source video
CTOs have infinite authority in theory, but extremely limited ways to act without getting fired.
Open source video
Source video

Migration sequencing, early-failure criteria, and momentum as a budgeted resource

Research question

Does easy-first sequencing with a pre-registered kill criterion improve long-horizon transition success, or does it bias the pilot toward unrepresentative success and delay discovery of hard blockers?

Why

The summary asserts the value of failing early to preserve optics and momentum but never specifies how a valid kill criterion is constructed. Agent runtime swaps, memory backend changes and tool-protocol migrations fail on adoption, not on the first technical step, so sequencing and kill thresholds are first-class design constraints rather than tactics.

Start by migrating something easy before tackling something really hard.
Open source video
If a migration is going to fail, you want it to fail early to preserve optics and momentum.
Open source video
Source video

Implementation-agnostic contracts as the precondition for cheap backend substitution

Research question

How much design effort in making a model-facing contract (tool schema, response envelope, memory API) implementation-agnostic is recovered by lower re-prompting and re-evaluation cost when the underlying model, retriever or store is replaced?

Why

In agent stacks the interface is often the schema handed to the model, so entanglement with the current implementation forces re-prompting, re-evaluation and caller retraining on every backend change. Decoupling makes backend substitution a local change, but the value of the abstraction is only realized if implementation swap cost is actually measured.

Good interfaces allow you to change things under the hood cheaply and quickly.
Open source video
Complex systems like GraphQL require decoupling interfaces from underlying implementations.
Open source video
Source video

Querying existing environment state before mutating it

Research question

In unfamiliar environments, does forcing a cheap epistemic step — querying registries, owners and prior decisions — before any expensive mutating action reduce redundant or contradictory agent actions?

Why

This is the lowest-novelty but highest-yield transfer in the pass-1 set: the failure mode is acting on assumed knowledge the environment already holds, and the mechanism is cheap and directly implementable as a pre-action gate.

The number one underutilized tactic in a new job is simply asking questions instead of assuming you know everything.
Open source video
New engineers often fail to ask existing team members whether a proposed change is a good idea.
Open source video
Source video

Article ideas

3

Preening and Snacking Are Not the Same Bug: Why Proxy Metrics Need Completion Weighting

Preening and snacking are distinct reward-hacking failures with distinct fixes — preening requires impact-weighted evaluation because the artifact is visible but valueless, while snacking requires sequencing discipline and completion incentives because the work is easy but never finished. Treating both as generic pseudoproductivity guarantees the wrong countermeasure.

Angle

Use the database migration example as the concrete case: starting a new database is easy and looks like progress, getting everyone off the old one is hard and looks like nothing. Then extend to agent platforms where new tooling ships weekly and deprecated paths never close.

Source video

Your Most Senior Component Should Have the Smallest Permission Set

Capability grants do not scale linearly with safe action space: as blast radius grows, the set of non-friction actions shrinks, so permission design is an intersection of capability and legitimacy, not a union of capabilities with judgment reliance. Applying the CTO observation to tool-granting in agent systems changes how access, escalation paths and audit surfaces are specified.

Angle

Contrast union-style permission design (grant broad access, rely on judgment) with intersection-style design scoped per principal, and tie the narrowing directly to the blast-radius and trust surface of each component.

Source video

Failing Early Is a Budget Decision: Momentum as a Finite Resource in Long Migrations

Easy-first sequencing is not a morale tactic, it is risk management: it converts a migration into a staged rollout with an explicit kill decision point, spending and preserving momentum and credibility as budgeted resources instead of discovering the failure after sunk cost. The cost is that an easy pilot may be unrepresentative of the real difficulty.

Angle

Argue the design tradeoff honestly — front-loaded low-risk pilots and pre-registered failure thresholds versus their bias toward misleading success — and specify that kill criteria must be defined in advance to be defensible.

Source video

Project ideas

4

Proxy-Metric Drift Harness

beyond-evals

An agent scaffold optimizing a visibility-weighted signal (artifacts produced, new tool surfaces added) will, at equal budget, score higher on visible-output metrics but lower on long-tailed completion metrics (deprecation of prior paths, closed loops) than a scaffold optimizing a completion-weighted signal.

Proof of concept

Run two scaffolds on the same task environment with a seeded set of legacy paths to retire and new subsystems available to build; the visibility scaffold is rewarded per new artifact, the completion scaffold per legacy path fully decommissioned. Compare artifact counts against decommission counts over identical step budgets.

Measurement

Delta in completed decommissions versus artifacts produced per unit budget, plus the ratio of initiated transitions to fully closed transitions for each scaffold.

Source video

Blast-Radius Permission Intersector

gatehouse

Permission sets computed as the intersection of granted capability and non-disruptive action set per principal produce strictly fewer audit-tripping or escalating actions than union-style broad grants, without reducing task success on the same workload.

Proof of concept

Implement a policy layer that, for each tool grant, records nominal capability and the set of actions observed not to produce friction at a given blast radius; run a fixed agent workload under union grants and under intersection grants.

Measurement

Count of friction events (audit flags, rollbacks, escalations) and task success rate under each grant mode at matched capability breadth.

Source video

Kill-Criterion Pilot Injector

movement-lab

Transitions with a pre-registered early-failure threshold and an easy-first pilot are abandoned earlier and at lower cost when doomed, but their pilot success rate overestimates full-migration success unless the pilot's difficulty distribution is matched to the full target set.

Proof of concept

Run staged migrations with and without pre-registered kill criteria; record difficulty distribution of the pilot targets versus the full target set, and measure time-to-abandon on deliberately infeasible migrations.

Measurement

Time and organizational capital spent before abandonment on doomed transitions, plus the gap between pilot success rate and full-migration success rate.

Source video

Contract-Decoupling Substitution Bench

new

Backend substitution cost (re-prompting, re-evaluation, caller changes) is a measurable function of interface/implementation entanglement, so contracts defined independently of the backend yield materially lower substitution cost than contracts accreted from the current backend.

Proof of concept

Take one agent tool/context contract in two variants — implementation-agnostic and backend-coupled — and swap the underlying model, retriever and memory store behind each, counting all downstream caller and prompt changes required.

Measurement

Number of caller and prompt edits plus re-evaluation cycles required per backend swap, per contract variant.

Source video

Architectural implications

3

Interfaces are treated as the stable layer while implementations are treated as replaceable, with GraphQL cited as a case that requires decoupling them.

Before

Model-facing contracts and tool signatures accreted from the current backend, so changing the backend forces changes to callers and prompts.

After

Contract defined independent of backend, so retriever, model, or storage swaps are localized behind the interface.

Consequence

Refactoring and backend migration become cheap and schedulable; the cost shifts to upfront interface design and versioning discipline.

Source video

Migration is sequenced as easy-first with an explicit early-failure point, using momentum and optics as resources to protect.

Before

Migration treated as a single big-bang technical project scoped by technical difficulty alone.

After

Migration treated as a staged rollout with a pilot, a kill criterion, and planned early exit on failure.

Consequence

Adoption risk and organizational credibility are managed as first-class design constraints rather than discovered empirically after sunk cost.

Source video

Seniority increases authority while shrinking the legitimate action set to avoid friction.

Before

Permissions designed as a capability union — grant broad access and rely on judgment.

After

Permissions designed as the intersection of capability and non-disruptive action, bounded explicitly per principal.

Consequence

Autonomy is scoped by blast radius and trust surface rather than by nominal capability, changing how tool access and escalation paths are specified.

Source video

Tradeoffs and failure modes

4

Visibility-optimized work (preening)

Benefit

High-visibility, low-impact work advances the individual's career quickly.

Cost or risk

It is bad for the organization and is invisible to individual-level reward signals, so it persists undetected.

Preening is doing high-visibility, low-impact work that gets you promoted but is bad for the organization.
Open source video
Source video

Starting new work vs finishing migrations (snacking)

Benefit

Starting a new system is easy, immediately gratifying, and looks like progress.

Cost or risk

The hard, high-value completion work — migrating everyone off the old system — is deferred indefinitely.

Snacking is starting new things because they are easy, while finishing difficult migrations is hard.
Open source video
Source video

Seniority and authority

Benefit

Senior roles carry broad nominal authority.

Cost or risk

Valid uses of that authority narrow sharply to avoid friction, so authority overstates usable freedom of action.

CTOs have infinite authority in theory, but extremely limited ways to act without getting fired.
Open source video
Source video

Migration failure timing

Benefit

Failing early preserves optics and project momentum.

Cost or risk

Easy-first sequencing delays the discovery of hard blockers, so the pilot's success may be unrepresentative of the migration's real difficulty.

If a migration is going to fail, you want it to fail early to preserve optics and momentum.
Open source video
Source video

Open questions

4

How do you evaluate whether a technical migration is actually worth the organizational cost?

Why unresolved

The summary names this explicitly as an open question and provides no evaluation method, only sequencing tactics.

Research direction

Build a cost model coupling adoption effort, momentum/credibility spend, and failure-timing under easy-first versus hard-first sequencing; test whether easy-first pilots predict full-migration outcome.

Source video

What is the right balance between autonomy and architectural alignment in staff engineering?

Why unresolved

Stated as an unresolved question; the only concrete guidance is that authority narrows with seniority.

Research direction

Formalize permission scoping as the intersection of granted capability and non-friction action set for a given blast radius, then compare against union-style permission grants.

Source video

How would you detect preening-style behavior in an automated system whose output is easily made visible but not easily verified for impact?

Why unresolved

The preening/snacking framework is descriptive; the summary gives no measurement or detection mechanism.

Research direction

Design impact-weighted rather than visibility-weighted evaluation signals, and test whether agents optimizing visible artifacts underperform on long-tailed completion metrics.

Source video

Can early-failure criteria be defined in advance for long-horizon system transitions without biasing the pilot toward success?

Why unresolved

The summary asserts the value of failing early but does not specify how a valid kill criterion is constructed.

Research direction

Study pilot designs that pre-register failure thresholds and measure whether the pilot's difficulty distribution matches the full migration's.

Source video

Key claims

7
causalVerification needed

Preening — high-visibility, low-impact work — benefits the individual's advancement while harming the organization.

Evidence

Preening is doing high-visibility, low-impact work that gets you promoted but is bad for the organization.

Question

Do promotion and impact metrics systematically diverge such that visibility-weighted evaluation rewards low-impact work?

Source video
causalVerification needed

Starting new systems is easy while completing migrations off old systems is hard, biasing behavior toward initiation.

Evidence

Starting a new database is easy; getting everyone off the old database is hard.

Question

What fraction of initiated migrations reach full decommission of the prior system, and how does initiation rate correlate with completion rate?

Source video
opinionVerification needed

A migration should begin with an easy target before tackling a hard one.

Evidence

Start by migrating something easy before tackling something really hard.

Question

Does easy-first sequencing improve overall migration success compared with hardest-first sequencing?

Source video
causalVerification needed

Early failure in a migration preserves optics and momentum, so failure should be forced early.

Evidence

If a migration is going to fail, you want it to fail early to preserve optics and momentum.

Question

Does early abandonment measurably preserve organizational willingness to fund subsequent transitions?

Source video
causalVerification needed

As seniority increases, authority grows but the set of valid actions narrows to avoid friction.

Evidence

As you become more senior, you gain authority, but valid ways of using that authority narrow to avoid friction.

Question

Is usable action space measurable as a shrinking function of blast radius across seniority levels?

Source video
causalVerification not requested

Decoupled interfaces allow implementation changes to be made cheaply and quickly.

Evidence

Good interfaces allow you to change things under the hood cheaply and quickly.

Source video
factualVerification needed

Most engineers entering staff roles have never worked in a true staff engineering role before.

Evidence

Many companies introduce staff engineering roles without anyone who has worked in a true staff engineering role before.

Question

What proportion of staff engineers were first-time staff engineers at the time of appointment, across company size bands?

Source video

Connections

5