Short answer
You get promoted to senior when you consistently deliver work nobody had to break down for you, and when your presence measurably improves other engineers' output. Writing more code does not get you there - taking ambiguous problems and returning finished decisions does.
The most common reason strong mid-level engineers stall is that they are optimising for the wrong variable. They ship more tickets, faster, with fewer bugs - and get told they are "not quite ready" for reasons nobody can articulate. The gap is almost never technical.
The Ticket-Taker Ceiling
A mid-level engineer takes a well-defined problem and produces a correct solution. A senior engineer takes an ambiguous problem, decides what the actual problem is, and produces a solution plus the reasoning. If every piece of work you do arrived pre-broken-down by someone else, you are demonstrating mid-level scope no matter how well you execute it.
The four things senior actually means
Titles vary between companies but the underlying criteria are remarkably consistent:
- Autonomy under ambiguity. Given "checkout is slow and customers are complaining", you can go from that sentence to a shipped fix without someone else scoping it.
- Blast radius awareness. You think about migration paths, rollback, on-call burden and what happens at 3am - not only whether the code is correct.
- Force multiplication. Your code reviews make other people better. Your design docs get referenced. Junior engineers get unblocked faster because you are on the team.
- Judgement about what not to build. Senior engineers talk teams out of work as often as they do it. Knowing when the answer is "this is a config change, not a project" is a senior skill.
Build the case before you ask
Promotion decisions are made in calibration meetings you are not in, by people who mostly have not seen your work. Your manager walks in with a document and argues from it. Your job is to make that document easy to write.
- Keep a running impact log. One line per meaningful piece of work: what it was, what changed, what the number was. Do it weekly, because reconstructing a year in December is impossible and you will undersell yourself.
- Translate work into outcomes. "Rewrote the notification service" is a task. "Cut notification delivery failures from 4% to 0.2%, removing the top source of support tickets" is a promotion case.
- Collect the force-multiplier evidence. The design doc three teams used. The onboarding guide that cut ramp-up time. Peer feedback saying you unblocked someone. This is the category engineers most consistently forget to record.
The conversation to have six months early
Do not ask "can I be promoted?" - it invites a yes/no with no follow-up. Ask for the criteria instead:
The script
"I want to be promoted to senior at the next cycle, and I'd rather know now if that's unrealistic. What specifically would you need to see from me between now and then to be able to argue for it? I'd like to write it down so we're both working from the same list."
This does three things at once: it states intent so your manager can plan for it, it converts a vague judgement into a checklist, and it creates a written record you can revisit. If your manager cannot produce specifics after being asked directly twice, that is information about the organisation rather than about you.
What to do if you are told "not yet"
Ask for the single biggest gap and a date. A no with a specific gap and a review date is a plan. A no with "keep doing what you're doing" is a stall, and repeated stalls are the most reliable signal that the fastest route to a senior title is an offer from somewhere else - which is also, uncomfortably often, the thing that produces the internal promotion.
Frequently asked questions
How long does it take to get promoted to senior engineer?
Typically three to five years of experience, but time is a floor rather than a criterion. What actually decides it is whether you handle ambiguous work autonomously and make the engineers around you more effective.
What is the difference between a mid-level and a senior engineer?
Scope and ambiguity. A mid-level engineer reliably solves problems that have been defined for them; a senior engineer defines the problem, decides what is worth building, and owns the consequences including on-call and migration.
Do I need to lead a project to make senior?
Usually yes, in the sense that you need evidence of owning something end to end - but it does not have to be a large project. Owning a migration, a subsystem or an incident follow-up completely demonstrates the same thing as owning a headline feature.
What if my manager keeps saying "not yet" without specifics?
Ask once more in writing for the single largest gap and a review date. If two cycles pass with no concrete criteria, treat it as a signal about the organisation - many engineers find the fastest path to a senior title is an external offer at the level they are already operating at.