Software Engineering · Chapter 6 of 8
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 appears in 87% of postings for a reason.
- 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.