Software Engineering · Chapter 6 of 31
What actually changes from mid to senior to staff
The most common promotion failure is doing the previous level extremely well.
| Mid | Senior | Staff | |
|---|---|---|---|
| Given | A task | A problem | A situation nobody has framed |
| Scope | Your ticket | Your team's area | Across teams, or a technical domain |
| Judged on | Delivery | Outcomes, and unblocking others | Whether the org's technical decisions got better |
| Writing | Comments and PRs | Design docs | Documents that change decisions |
| The trap | Not asking for help | Becoming the bottleneck | Being an expensive senior nobody consults |
The three things that get you to senior
- Own an outcome, not a task. Take something ambiguous through to working, including the parts nobody assigned you.
- Make others faster. Reviews, documentation, a tool, an onboarding path. Mentorship is named in 43% of postings, and assumed in a good many more.
- Communicate in writing. The step from senior upward is almost entirely about whether your reasoning scales beyond the room you are in.
The staff-level artefact
One document you wrote that changed a decision — ideally on a team you were not on. That single artefact does more for a staff-level case than any amount of shipped code, because it demonstrates the thing the level is defined by: influence beyond your own hands.
If you do not have one, write one now about something real in your current job. The worst outcome is that you understand your own system better.
The three transitions, and what actually changes
Levels are described in ladders that all read the same. What actually changes is narrower than the ladder suggests, and it is worth being able to state precisely, because “why are you ready for the next level?” is asked in almost every senior loop.
| Transition | What changes | The trap |
|---|---|---|
| Junior → mid | You stop needing the problem decomposed for you. Given a feature, you can find the work yourself | Continuing to ask for tickets. The signal is that someone else is still doing your decomposition |
| Mid → senior | You become responsible for the outcome, not the task. That includes noticing the requirement is wrong, the estimate is fantasy, or the design will not operate | Being an excellent implementer and waiting to be assigned. Speed is not seniority |
| Senior → staff | Your output stops being your output. Value comes through other people — designs they follow, standards they adopt, problems you stopped before anyone noticed | Staying the best individual contributor. It is the most common way to be stuck at senior indefinitely, and it feels like doing well |
The evidence that actually reads as senior
- A decision you made with incomplete information, and what you did to reduce the risk of being wrong. Not a decision that turned out well — one where you can describe the uncertainty and how you bounded it.
- Something you chose not to build. Scope you cut, a system you decided not to write, a migration you deferred. This is disproportionately strong evidence and almost nobody brings it.
- A time you were wrong and how you found out. The mechanism matters more than the mistake: did the system tell you, did a colleague, or did a customer? ‘A customer told us’ is an honest answer and an opening to talk about what you instrumented afterwards.
- A conflict you resolved without escalating, or escalated deliberately and well. Both are fine; ‘we never disagreed’ is not a credible answer at this level.
- Someone who got better because of you, described specifically enough that you can say what they could not do before.
Why staff engineers get stuck, and it is not skill
The senior-to-staff transition fails in a specific and predictable way: the engineer keeps doing the thing that got them promoted.
At senior, being the person who can be handed the hardest problem is exactly right. At staff, it is a bottleneck — the organisation now has one person who can solve a class of problem, and that person is fully occupied.
The transition is uncomfortable because the new work is less visible and feels less productive. Writing a design document that ten people follow produces no commits. Preventing a bad architecture produces nothing at all. A week spent unblocking four people looks, in any activity metric, like a week of nothing.
So the evidence you need is second-order, and you have to collect it deliberately: what did other people ship because of something you did? Whose design changed after your review? What did the team stop doing?
The honest framing for an interview: “the shift was learning that my throughput had stopped being the constraint.”
Check yourself