Most software engineers who don't get promoted aren't underperforming. They're doing the work but not making the work visible — or they're optimizing for the wrong things entirely. Here's how promotions actually work, and what to do differently.
How Promotions Actually Work (Not How They're Supposed to)
In theory, you meet performance criteria, your manager nominates you, and the committee approves.
In practice: promotions go to people whose work is visible to the people making promotion decisions, who have an advocate willing to fight for them, and who have been performing at the next level before the promotion is approved.
That third point is the one most engineers miss: you need to demonstrate next-level performance before you get the title and pay of the next level. The promotion is recognition of work you've already done — not permission to start doing it.
What Actually Gets You Promoted
1. Scope and Impact, Not Just Output
The difference between SWE II and Senior, Senior and Staff, is almost always about scope — how much of the system, team, or organization you're affecting.
SWE II → Senior: You own features, not just tasks. You ship complete features end-to-end including design, implementation, testing, and monitoring. You work with some ambiguity.
Senior → Staff: You own projects that span multiple teams or significant portions of the product. You're setting technical direction, not just executing it. Your decisions affect multiple engineers' work.
What this means practically: Take on work at the edges of your current scope. Volunteer for cross-team projects. Own the technical design of a feature, not just one service within it.
2. Multiplying Others, Not Just Yourself
At senior levels and above, it's not enough to be highly productive individually. You need to make the people around you more productive.
This shows up as:
- Thorough code reviews that teach, not just approve/reject
- Technical writing (design docs, RFCs) that others use as reference
- Mentoring junior engineers
- Being the person others come to when they're stuck
What this means practically: Start tracking when other engineers benefit from your work. "Three engineers used the caching abstraction I built" is evidence for a Staff case.
3. Ownership Through Completion
Many engineers start projects well and finish them adequately. Promotable engineers carry their work all the way: shipped, monitored, iterated on, documented, and handed off cleanly.
They also own things that go wrong. When a service they own has an incident, they own the post-mortem, the remediation, and the prevention story — not just the fix.
What this means practically: For every project you touch, ask "is this actually done?" Run the post-deploy monitoring. Write the runbook. Update the docs.
4. Solving the Hard Problems
Easy work is visible but not promotion-driving. Engineers who get promoted consistently choose to work on the hard problems — the ones other people are avoiding.
The legacy codebase nobody wants to touch. The cross-team dependency that everyone knows is a problem but nobody owns. The performance issue that "isn't blocking anyone" but affects 10% of users.
What this means practically: When you see a problem that's being avoided, ask your manager if it's worth owning. Volunteer before you're asked.
What Does NOT Get You Promoted (Common Mistakes)
Working harder in the same scope. Doing twice as many tickets doesn't signal next-level performance. It signals strong performance at the current level. Promotions require widening scope, not deepening velocity.
Fixing bugs without communicating the impact. "I fixed 12 bugs this quarter" is a weak promotion case. "I identified a class of memory management bugs affecting 0.5% of user sessions and systematically eliminated them" is a promotion case.
Waiting to be asked. Promotable work often requires volunteering for things before they're assigned to you. Nobody will schedule you for the cross-team migration project if you haven't demonstrated interest in that kind of scope.
Not making the implicit explicit. Your manager cannot champion you in committee if they don't know what you've done. Documenting and sharing your impact is not self-promotion — it's helping your advocate do their job.
How to Make the Case to Your Manager
Start the Conversation Early
Don't wait for promotion cycle to ask "how do I get promoted?" Have that conversation 6–12 months before you want the promotion. Ask specifically:
"I want to be on track for a promotion to [level] in the next 2 performance cycles. What would that look like? What evidence do you need to see?"
Write down the answer. This creates alignment and gives you a checklist.
Build a Brag Doc
Keep a running doc — updated weekly — of everything you've done, with impact. When promotion time comes, you should be able to hand your manager a document they can use in committee.
Format each entry as: What I did → Impact → Evidence
"Redesigned the search indexing pipeline → Reduced p99 latency from 4.2s to 800ms → Monitored in Datadog, confirmed stable for 6+ weeks."
Request Explicit Feedback at Milestones
After every major project, ask your manager: "How would you characterize this work in the context of a Senior-level performance bar? What would have made it stronger?"
This keeps you calibrated and gives you actionable feedback rather than generic praise.
Identify and Close Your Gaps
Every level has gaps — things where you're not quite demonstrating next-level performance. Find yours by asking directly: "What's the gap between where I am now and a strong promotion case?"
Then systematically address those gaps. If the gap is technical breadth, volunteer for work in that area. If the gap is communication, write more design docs. If the gap is scope, ask for a project with broader impact.
The Promotion Conversation
When you think you're ready, don't hint — ask directly:
"I believe I've been operating at the [next level] for the past [X months] based on [specific examples]. I want to understand where I am in the promotion consideration and what the timeline looks like."
Come prepared with 3–5 specific examples that demonstrate next-level work. Quantified where possible.
If the answer is "not yet," ask: "What specifically would you need to see to support my promotion in the next cycle?" Get it in writing.
Timelines
SWE II → Senior: Typically 18–36 months, depending on company and your performance trajectory. Engineers who are targeting it proactively can sometimes compress this.
Senior → Staff: Typically 2–4 years at senior. This jump is harder than all previous promotions combined and some engineers never make it — often because they're excellent senior engineers who don't expand their scope and multiplier work.
Staff → Principal: Extremely variable. Some companies don't have principal ICs. Some engineers stay at staff for decades. The work is inherently organizational and political, not just technical.
The fastest path to promotion is doing the work at the next level before you have the title, making that work visible, and having an advocate who's fighting for you. Start with the first one — the rest follows.
Practice your technical and behavioral interviews for your next role →