Part 9 · 11 chapters · ~50 min

Leading the work: staff engineering in practice

A change of job rather than an increase in difficulty, and the most common failure is doing the senior job harder. The output stops being working software and becomes decisions, clarity and other people’s output, which means the hard part stops being technical complexity and becomes ambiguity and disagreement. These are learnable behaviours rather than innate capability, which is worth saying plainly.

What changes between senior and staff

the question

“I am a strong senior engineer. What is actually different about the next level?”

	Senior	Staff
Scope	A system or a team	Several teams, or a domain
Time horizon	This quarter	This year and next
Primary output	Working software	Decisions, clarity, and other people’s output
Hard part	Technical complexity	Ambiguity and disagreement
Success looks like	It shipped and it works	The right thing was built, by others
Failure looks like	A bug	Six months on the wrong thing
Measured by	Delivery	Leverage

worked numbers

the reframing that matters:

  senior: "I can solve this"
  staff:  "I can make sure the right thing gets solved,
            usually by someone else"

it is a change of job, not an increase in difficulty.
the most common failure is doing the senior job harder.

what this means for someone doubting themselves

The senior skills do not stop mattering; they become the floor rather than the differentiator. If a principal engineer occasionally tells you the work is not good enough, that is the ordinary experience of operating near the edge of your scope, and it is what growth feels like from inside. The gap between senior and staff is mostly a set of learnable behaviours, several of which are in the next ten chapters, rather than an innate capability you either have or do not.

Technical strategy, written down

what a technical strategy actually is

A diagnosis. What is actually true about our situation, stated plainly, including the uncomfortable parts.
A guiding policy. The approach we are taking, and therefore what we are not doing.
Coherent actions. Specific work that follows from the policy, that would not happen otherwise.

worked numbers

not a strategy:
  "we will improve reliability and velocity and quality"
  → no diagnosis, no tradeoff, nothing excluded

a strategy:
  "our lead time has doubled because six teams share one
  deployment pipeline and one database. for the next two
  quarters we are prioritising team independence over
  infrastructure efficiency, accepting higher cost, by
  splitting the pipeline and extracting two schemas."

a strategy that excludes nothing is a wish.

why writing it down is the whole trick

An unwritten strategy is a set of individually reasonable decisions that add up to nothing. Writing it forces the tradeoff to be explicit, lets people act on it without asking, and makes it possible to notice when it is wrong. Two pages, reviewed quarterly, is more influence than a year of good opinions in meetings.

The design document that gets read

the structure that works

Context and problem, one paragraph. If a reader stops here they should understand why this exists.
Goals and explicit non-goals. The non-goals prevent most of the unhelpful review comments.
The proposal, with a diagram.
Alternatives considered, and why not. This is the section that earns trust: it proves the proposal is a choice rather than the first idea.
Tradeoffs accepted, stated as costs rather than hidden.
Open questions, which invites the review you actually want.
Rollout and rollback.

what makes it get read

Short. Two to four pages. A twenty-page document gets skimmed by three people and approved by nobody.
A decision requested, explicitly. "I need agreement on the shard key by Friday" gets a response; "thoughts welcome" does not.
Sent to named people with a deadline, not posted to a channel.
Written before the work, not as documentation after. A design document written after implementation is a status report.

the underrated benefit

Writing it is how you find out whether you understand the problem. A surprising fraction of design documents are abandoned halfway through because the act of writing revealed the proposal did not work. That is the document succeeding, not failing, and it is far cheaper than discovering it in month three.

Reviewing designs and code as leverage

worked numbers

the leverage arithmetic:

  writing code:      your output = 1× your time
  reviewing well:   improves N engineers' output, and teaches
  reviewing designs: changes what gets built before it is built

a design review that prevents three weeks of wrong work
is worth more than three weeks of your own right work.

how to review so people want your review

Separate blocking from non-blocking, explicitly. "Blocking: this breaks read-your-own-writes. Non-blocking: I would name this differently." Without the label, everything reads as a demand.
Ask rather than assert when you might be wrong. "What happens if the provider times out here?" invites thought; "this is wrong" invites defence.
Explain the why. A review comment that teaches is worth ten that correct.
Be fast. A review that arrives in two hours is worth far more than a better one in three days, because the author has moved on and the cost of change has risen.
Approve with comments where the issues are non-blocking. Holding a change hostage over preferences is how review becomes a bottleneck people route around.

Influence without authority, concretely

what actually works

Be right, visibly, over time. Slow and unglamorous, and it is the foundation. Nothing else works without it.
Do the unglamorous thing nobody else will. Writing the strategy, fixing the flaky test suite, owning the scorecard. Credibility accrues fastest from work others avoid.
Make other people successful, publicly. The engineer whose design you improved becomes an advocate.
Bring data, not opinions. "Lead time on this component is 4x the others" ends a debate that "this code is bad" would sustain for months.
Pick your battles deliberately. Someone who objects to everything is routed around; someone who objects rarely is listened to carefully.
Write things down. A document persists, gets forwarded, and is read by people you will never meet. It is the highest-leverage medium available.

the failure mode to avoid

Being the person who is technically right and organisationally ignored. It is a real and common outcome, and it is almost always a communication problem rather than a political one: the argument was made in the wrong register, to the wrong audience, without the cost expressed in terms they own. Being right is necessary and not sufficient, and treating that as unfair rather than as a skill to learn is what keeps people stuck.

Disagreeing well, and committing after

the sequence

Make sure you understand their position well enough to state it back. Most technical disagreements dissolve here, because they were different assumptions rather than different conclusions.
Identify what would change your mind, and say it. If nothing would, you are not having a technical argument.
Argue the tradeoff, not the conclusion. "I weight recovery time higher than cost here" is discussable; "your design is wrong" is not.
Escalate on substance, not on frustration, and escalate to a decision rather than to an ally.
Then commit, genuinely. Disagree and commit means arguing hard, losing, and then making the chosen approach succeed, including in front of others.

the part people get wrong

Committing is not silence; it is active support. An engineer who lost an argument and then quietly lets the approach fail, or says "I told you so" afterwards, has made the organisation worse than if they had never objected. And record the disagreement in the design document, so that if it does fail, the learning is available without anyone needing to be vindicated.

Growing other engineers deliberately

the mechanisms, in order of leverage

Delegate the interesting work. The instinct is to keep the hard problem. Giving it away, with support, is the highest-leverage thing a staff engineer does, and the hardest.
Pair on the hard parts, particularly incidents and design. Someone watching you reason through ambiguity learns more than from any document.
Review to teach. Per chapter 87: explain why, not just what.
Create scope for others. Notice the problem someone could own, and hand it to them with the context rather than solving it.
Sponsor, do not just mentor. Mentoring is advice; sponsorship is putting your credibility behind someone in a room they are not in. The second is what actually changes careers.

the honest tension

Delegating the interesting work means doing less interesting work yourself, and that is a real cost that nobody mentions. It is also the transition: if you are still doing all the hard problems, you have capped the team at your own capacity. The measure of a staff engineer is what the team can do without them, which is uncomfortable and correct.

Working with product and with finance

with product

Understand what they are optimising for, which is usually a metric they are accountable for. Aligning your argument to it is not manipulation, it is translation.
Offer options with costs, rather than a verdict. "Two weeks for the simple version, six for the one that handles multi-currency" is a decision they can make.
Bring the non-functional cost early. "This design means we cannot add a second currency later without a migration" is useful at design time and useless afterwards.
Say yes to the small thing. Credibility built on delivering unblocks the harder conversations later.

with finance

Part 19 of the CBA module is the shared language. Unit economics, cost per transaction, and the safeguarding assertion are things both sides care about.
Infrastructure cost is their domain and your decision. Bringing a costed option rather than a bill after the fact changes the relationship entirely.
Reproducibility matters more to them than elegance. A number that changes when re-run is a serious problem, and understanding why makes you a useful partner.

the general point

Every function has a model of the business, and yours is one of several. The engineers who have the most influence are usually the ones who learned enough of product's model and finance's model to argue in those terms. It is not dilution of technical depth; it is what makes the technical depth actionable.

Estimation, and being honest about uncertainty

worked numbers

why estimates are wrong, in order of magnitude:

  1. unknown unknowns    the work you have not discovered
  2. dependencies         waiting on people and systems
  3. interruption          incidents, support, reviews
  4. the coding itself    which is what people estimate

estimating item 4 accurately and ignoring 1-3 is why
estimates are consistently 2-3x optimistic.

estimating honestly

Give a range, with the assumptions. "Three to six weeks, assuming the risk team can review in week two" is information. A single number is a promise you did not mean to make.
Separate the known from the unknown. "One week to build what we understand, and we will know after a two-day spike whether the rest is one week or four."
Re-estimate when you learn something, and say so early. A date that slips at the last minute is far worse than one revised in week two.
Never pad silently. Padding that is not visible gets removed by someone else, and then you have neither the buffer nor the trust.

the sentence worth practising

"I do not know yet, and here is what I would need to do to find out, and how long that would take." It sounds like weakness and it is the opposite: it is the answer of someone who has been wrong before and learned what causes it. People trust engineers who are calibrated more than engineers who are confident.

Choosing what not to work on

the filters, applied in order

Is this the constraint? Improving anything other than the bottleneck produces no systemic improvement. Most work fails this test.
Will it matter in a year? A lot of urgent work will be irrelevant by then, and some quiet work compounds for a decade.
Can somebody else do it? If yes, they should, per chapter 90. Your comparative advantage is the work nobody else is positioned to do.
Does it need me specifically? Cross-team ambiguity, a decision nobody owns, a strategy nobody has written. That is the staff-shaped work.
What happens if nobody does it? Sometimes the honest answer is "nothing much", and that is a complete answer.

the hardest part

Saying no to interesting work. There is always a fascinating problem that is not the most valuable thing you could do, and the pull toward it is strong precisely because it is enjoyable. Staff engineering involves a permanent low-grade disappointment about the problems you are not solving, and recognising that as normal rather than as a sign of being in the wrong role is part of the job.

Visibility without self-promotion

the distinction

Self-promotion is claiming credit, usually for work that was collective.
Visibility is making sure the work is known: what was done, why it mattered, and what happened as a result.
The second is a responsibility, because invisible work does not get funded next quarter, and the people who did it do not get recognised.

how to do it without discomfort

Report outcomes, not effort. "Page volume fell from 3.4 to 1.2 per night after the alert review" is a fact, not a boast.
Name the people who did the work, specifically. This is both accurate and the most reliable way to build the kind of reputation that lasts.
Write the thing down, per chapter 88. A document circulates without you in the room.
Use existing forums: the monthly scorecard review, a postmortem, a strategy update. Visibility does not require a new meeting.
Make the metric visible rather than yourself. If the scorecard shows maintenance share recovering, the work is visible and you did not have to mention yourself once.

the closing thought for this part

The work that matters most at staff level is frequently invisible by nature: a bad decision prevented, a design improved before it was built, a conflict resolved quietly. Nobody sees the incident that did not happen, which means making the value legible is genuinely part of the job rather than a distasteful extra. Part 0 made the same argument about non-functional properties, and it is the same problem: things whose success is an absence need someone to articulate them.