Getting to Staff and Staying

We’ve covered the craft of staff engineering, scope, strategy, writing, decisions, projects, influence, glue work, growing others, architecture, incidents. This final lesson is about you: how the promotion actually works (it’s not what most people think), how to make your impact visible, the traps that catch people after they get the title, and a concrete plan to put it all into practice. And I want to start with the most important and most misunderstood thing about getting to staff.

You Get the Title by Already Doing the Job

Here’s the thing nobody tells you clearly: you don’t get promoted to staff and then start acting senior. You act at the staff level first, for six to twelve months, and the title confirms a reality that already exists. Promotion is a trailing indicator of impact, not a reward for tenure, not a prize for wanting it, and not something that happens then enables you. If you’re waiting for the title before you start doing cross-team work, leading on strategy, or influencing beyond your team, you have it backwards, and you’ll wait a long time.

The ingredients of an actual staff promotion:

• Operate at the level first. Do staff-scope work, cross-team, high-leverage, visible, for a sustained period before the promo. The promotion committee is looking for evidence you’re already a staff engineer, not potential.
• Have a signature project. One undeniable thing people point to: “she’s the one who fixed the deploy pipeline”, “he led the payments migration.” A clear, cross-team, high-impact accomplishment that’s unambiguously yours (even if many helped). Diffuse contributions don’t make a promo case; a signature does.
• Build a sponsor (Lesson 9, now pointed at yourself). Someone senior who will argue for you in the rooms you’re not in. This is not optional, promotions to staff are decided by people more senior than your manager, and you need someone credible making your case there. No sponsor, no promo, however good your work.
• Make the impact legible. If your impact is invisible, it may as well not exist. Write it down, demo it, keep the record (the brag doc, below). The committee can only act on what they can see.
• Earn recognition across teams. Staff is an org-level trust signal, so it needs people beyond your own team and manager to vouch for you. Peer feedback from other teams, other leaders who’ve worked with you, that breadth is often what distinguishes a staff case from a strong-senior one.
• Help build the written case. Your manager assembles a packet with evidence and peer feedback. You can make their job easy (here are my projects, their impact, the people who’ll vouch, the docs) or hard (good luck reconstructing my year). Make it easy.

The uncomfortable implication is liberating once you accept it: stop optimising for the promotion and start doing the work that, done visibly, earns it. Chasing the title directly (asking repeatedly, resenting its absence, doing visible-but-shallow work) tends to backfire. Doing genuinely high-impact work and making it legible is both more effective and more satisfying.

Keep a Brag Document

The humble tool that makes impact legible is the brag document, a running log of what you did and the impact it had.

Once a month, spend five minutes logging: projects shipped and their impact (with numbers where you can), hard problems solved, people you mentored or sponsored, docs and decisions you drove, cross-team and glue work (Lesson 8, which would otherwise vanish), times you changed a direction, and the quieter things (talks, reviews, interviews, hiring). Why it’s worth the habit:

• It turns “what did you do this year?” from a panicked two-day reconstruction into a copy-paste. Nobody remembers their own wins at review time, including you, you forget the fire you put out in March by December.
• It surfaces the invisible glue work that’s otherwise uncredited.
• It gives your manager and sponsor the evidence to build your case.
• It shows you your own growth, and, importantly, when you’ve plateaued (if this year’s entries look like last year’s, that’s a signal).

Write impact, not activity: “cut checkout p99 by 40%”, not “worked on latency.” Five minutes a month is one of the highest-return habits in your career.

The Traps After You Arrive

Getting to staff is one thing; staying effective and happy is another, and the failure modes are predictable:

• The hero / bottleneck: every decision routes through you. It feels important, but you’re now a single point of failure, and you’ll burn out. Fix: delegate real ownership, document, build others (Lesson 8).
• The ivory tower: you stopped touching real code, so your advice slowly drifts from reality and loses credibility. Fix: stay hands-on in something, a prototype, a hard bug, a tool. Enough to stay grounded (Lesson 2).
• Chasing visibility: you only work on shiny, promotable things, so the essential unglamorous work rots, and peers notice and resent it. Fix: do the boring-important work too; your credibility depends on it.
• Scope creep of self: you say yes to everything, spread thin, with real impact on nothing. Fix: pick a few bets; say no clearly and kindly. Focus is a staff skill.
• Losing the plot: you start optimising for the title and status rather than the work. Fix: remember you got the role to have impact; if the title becomes the goal, the impact, and eventually the satisfaction, fades.

The good path is simple to state and hard to sustain: depth + humility + leverage. Keep learning, keep shipping through others, keep your judgment grounded in reality, and measure yourself by what your teams achieve, not by your title or your personal output. The best staff engineers I know stay curious, stay kind, stay close to the work, and keep their egos out of it. That’s what makes a long, effective, enjoyable career at this level, rather than a title that slowly curdles.

Capstone: Your First 90 Days as a Staff Engineer

Let’s make it concrete. Suppose you’ve just stepped into a staff role (or decided to start operating like one). Here’s a 90-day plan that applies the whole course. Adapt it freely, the shape is what matters, not the exact days.

Days 1–30: Listen and map. Resist the urge to arrive with answers. Read the code, the docs, and especially the last six months of incidents and design docs (they tell you where the pain and the decisions are, Lessons 2, 10). Meet every team you’ll touch; ask what’s broken and, critically, who decides what (Lesson 7). Map the stakeholders and the real org (not the org chart). Don’t propose big changes yet, you don’t have the context, and you’ll spend credibility you haven’t earned.

Days 31–60: Find the leverage. Now you can see. Identify the one or two problems that are genuinely important, wide-reaching and durable (Lesson 2). Write one sharp document, a diagnosis plus a proposal (Lessons 3, 4), and circulate it for real feedback. Ship one small, visible, useful thing to build credibility and stay grounded (Lessons 5, 8). Start sponsoring someone (Lesson 9), it’s never too early.

Days 61–90: Commit and drive. Pick your bet. Write the one-pager and get explicit cross-team agreement (Lesson 6). Set the technical direction in your area, in writing, with the trade-offs owned (Lessons 3, 5). Establish one healthy practice that outlasts any single project, an ADR habit, a blameless postmortem culture, a paved road (Lessons 10, 11). And keep the brag doc from day one (Lesson 12).

The Throughline

If this whole course had to compress to one idea, it’s this: staff engineering is leverage. It’s about changing what many people build, through judgment, writing, influence and trust, not through your own keystrokes. You operate at the right altitude, choose the work that actually matters, make decisions well and record them, write clearly enough to move teams, lift the people around you, keep the systems healthy, and stay close enough to reality to keep your judgment sharp. Do that consistently and visibly, and the title follows the impact, not the other way around.

None of it is mysterious once it’s named. It’s a craft, with techniques you can learn and templates you can use, which is exactly what this course has tried to give you. The rest is reps: go do the work, make it visible, lift others as you go, and keep your ego out of it.

Pitfalls to Avoid

1. Waiting for the title before operating at the level. You earn staff by already doing the job, visibly, first.
2. Chasing the promotion directly. Do high-impact work and make it legible; chasing the title backfires.
3. No signature project or no sponsor. You need one undeniable accomplishment and someone senior arguing for you.
4. Invisible impact. Keep a brag doc; what the committee can’t see, it can’t reward.
5. Becoming the hero/bottleneck or the ivory tower. Delegate and stay hands-on; both traps cap you.
6. Only doing visible work, or saying yes to everything. Do the boring-important work; focus on a few bets.
7. Optimising for the title over the work. You took the role for impact; if the title becomes the goal, the impact fades.

Quick Recap

• You get the staff title by already operating at the level for 6–12 months; promotion trails impact, it doesn’t precede it.
• The ingredients: a signature project, a sponsor, impact made legible, recognition across teams, and a written case you help build.
• Keep a brag document, impact not activity; five minutes a month beats frantic recall and surfaces invisible work.
• Avoid the post-arrival traps: the hero/bottleneck, the ivory tower, chasing visibility, spreading thin, losing the plot.
• The throughline: staff engineering is leverage, judgment, writing, influence and trust applied to change what many people build. Do it visibly, and the title follows.

That’s the course. Thank you for working through all twelve lessons. Now go operate at the level, make it visible, and lift the people around you as you climb.