Junior to mid, mid to senior, senior to staff. Why invisible excellent work loses in the promotion room without anyone in it being corrupt.
Your manager is happy with you. That is the part that stings.
You cleared the loop, you took every ticket that landed in your lap, you helped the colleague who asked, you shipped the feature and it did not page anyone at 3am. You asked around for feedback and nobody had a single bad word. Then the promotion cycle comes and your manager says, warmly, that you are not ready for mid-level yet.
And then the reasons. You need more experience. You are not at the top of the band. There is no open position in the team right now. Every one of those is technically true and none of them is the reason.
Here is the rule nobody says out loud: you do not get promoted for doing your current job well. You get promoted for already doing the next one, visibly, for long enough that the title is a formality.
Long enough usually means about two review cycles of it being obvious. If you are on your third and still hearing about headcount, you are being managed rather than promoted, and that is information too.
That sounds unfair. It mostly is not. It is badly communicated, which is worse, because unpublished rules look identical to rigged ones from where you are standing. Headcount is a real constraint, sure. But if you are genuinely operating a level above where you sit, someone who wants to make your case will find the words. The excuses arrive when the case is thin.
So let me publish the rules. Junior to mid, mid to senior, senior to staff, and what each rung is actually measuring when it says „impact.“
a bandwidth problem, not a conspiracy
The complaint you hear is that it is not the most competent people who get promoted, it is the most visible ones. That is true often enough to hurt, and it is also an incomplete reading of what is happening.
Look at the mechanics. Promotions past mid-level are not decided by your manager alone. They go to a room. Senior engineering managers, directors, a few senior engineers, working through a slate of candidates, comparing people across teams they mostly do not observe directly. Someone in that room has to be able to say what you did and why it mattered, out loud, to people who have never seen you work.
That is the whole mechanism. Not a conspiracy. A bandwidth problem. Your work has to survive being described by a third party in a meeting you are not in.
Which means invisible excellent work does not lose to visible mediocre work because the system is corrupt. It loses because nothing about it reached the room. If nobody can retell it, it functionally did not happen, and this is as true at the insurance company with the mainframe as it is at Google. Anywhere there is a committee, there is a retelling problem.
So the fix is not to become a politician. It is to remove the compression loss between what you did and what gets said about it by someone else. That is a different skill from being good at your job, nobody teaches it, and it is most of what people mean by the vague word „impact.“
So the question at every rung is not just what you can do. It is what someone else can say about you in that room, in about three sentences, without you there to fill in the gaps. Here is what each rung needs those sentences to contain.
junior to mid: stop needing to be unblocked
The first denial lands hard because nothing in your day warned you the rules had changed. For a year or two, your whole model of advancement was that a well-defined task appears, you solve it correctly, an authority evaluates the solution and rewards you. That is school, and that is the interview. Then you arrive and the same shape seems to hold. Your manager hands you a task, your tech lead hands you a task, a colleague needs help and you take it. You solve them all well. This is the last stretch of your career where that is the entire job.
The bar for mid-level is narrow and almost entirely about your dependency on other people.
Mid-level means someone can hand you a task and stop thinking about it. Not „you write good code.“ You already write good code. It means the ticket goes to you and it comes back done, and nobody had to answer three Slack questions to make that happen. The ambiguity in the ticket was yours to resolve and you resolved it.
That is the demonstration. Take a task and drive it to done without a hand on your shoulder.
The catch is that this needs to be observed, and you now know why. In a healthy setup your manager notices, writes it down, and files the case for you. That is literally the job. But you will meet managers who do not know how to run a promotion, or are too new to have run one, or are quietly not interested in spending their political capital on you. Assume nothing.
So write it down yourself. Not a manifesto. When something ships, say what it was and what it changed, in the channel where that kind of thing gets said. The impact can be small. It is a bug fix that stopped a recurring support ticket. It is a migration nobody noticed because you did it carefully. Small is fine at this level. What matters is that your name is attached to finished work in a place other people can see it.
mid to senior: the wall everybody hits
Now you are mid-level. You are fast, you are independent, you are hungry, and you have a theory: more, and faster.
So you do more, and faster. You ship a pile of features. They are stable. Customers use them and like them. Your throughput is genuinely at the top of the team. You go into the cycle expecting the obvious result and you do not get it.
This is where people get properly bitter, and I understand why. It feels like the goalposts moved. They did not move. You were promoted last time for reliable execution, so you reasonably concluded that more reliable execution was the currency. But reliable execution is not the currency anymore. It is the entry fee. It is what mid-level already means, and you cannot get promoted for being excellent at your own job description.
What senior asks for is different in kind, not degree. Two things, and the second one is where most people stall.
The first is designing the complicated thing. Not implementing a design handed to you. Sitting in front of a problem with no obvious shape and producing a system other people can build. The tell is what happens when the requirements are contradictory, which they always are. A mid-level engineer takes the contradiction back to whoever wrote it. A senior engineer works out which of the two things the business actually wants, writes down the assumption, names what it costs, and keeps building. Being wrong in a documented way beats being blocked.
The second is working outside your own team, and this is the wall. The interesting problems have three teams in them and no single owner. Going to find those people is the easy part. Getting them to agree is harder. Keeping the agreement alive is the part nobody warns you about, because agreements decay. You get three teams to commit in March. In May one of them reorgs, the engineer who understood your part leaves, and the new priority list does not mention you. Nobody tells you this happened. You find out because a dependency you were promised quietly stops moving.
Handling that is not a technical skill and it is not politics either. It is noticing the silence early, going back to a manager whose priorities have genuinely changed, and rebuilding the case in terms of what they now care about instead of what they agreed to two months ago. Do that twice on one project and you have done the actual job of a senior engineer, most of which never appears in a commit.
senior to staff: you have to bring the problem too
Senior is a terminal level almost everywhere. Nobody pushes you out for staying. The money is good, the work is interesting, and a lot of very strong engineers park here on purpose and have great careers.
If you want the next one anyway, the shape changes again.
At senior, someone still points at the problem. Your team has a goal, the goal has a hard part, you own the hard part. At staff, you supply the problem. You are the one who notices that the thing everybody complains about in passing is costing the company real money, and that fixing it crosses four teams and two orgs and nobody’s roadmap contains it.
Then comes the part that is not engineering at all. You have to convince several senior engineering managers to give you people. They each have a roadmap they are already behind on. So the pitch cannot be „this architecture is wrong.“ It has to be revenue, or cost, or a customer outcome, and it has to be specific enough that a director can defend it in their own planning meeting.
There are also fewer of these seats than there are people who want them, and the other candidates are also strong. Sometimes the answer is not „not yet,“ it is „not here,“ and being clear-eyed about that beats grinding for three more years against a wall. For actual depth on this, Will Larson’s Staff Engineer: Leadership Beyond the Management Track is mostly stories from people who made it, and the useful thing is how little the stories resemble each other.
the part where this system is genuinely unfair
I have spent this whole article arguing that visibility is a bandwidth constraint rather than a conspiracy. Both things can be true: it is a bandwidth constraint, and it still has casualties, and they are not randomly distributed.
The system rewards people who are comfortable narrating their own work in a second language, in a large meeting, in a culture that reads confidence as competence. If you are quiet, or new to the country, or on a team whose entire output is keeping something boring alive, you are paying a tax the loud engineer on the launch team is not paying. That is real. It is not fixed by telling you to speak up more.
There are also organizations where the retelling problem is small. A twelve-person company where the CTO has read your code does not need a committee, and quiet excellence gets seen because there is nobody to hide behind. That is a genuine argument for staying small, and it is a real reason some very good engineers never work anywhere with a promotion cycle again.
What I do not think survives contact with the evidence is the fully cynical version, the one where the whole thing is theater and the promoted are simply the loudest. The loud engineer with nothing behind them gets found out in the room, usually by the one senior engineer sitting there who has actually read the code. The tax is real. It is a tax on top of the work, not a replacement for it.
what to actually do on Monday
Find out what your organization is currently trying to survive. Cost, latency, churn, a migration everyone is dreading. Point yourself at that, not at the ticket queue, and start doing pieces of the next level against it before anyone asks.
Then make it retellable. What was broken, what you did, what changed, with a number in it if a number exists. Present your own design review instead of letting your tech lead present it. Read the ladder document, then go read who actually got promoted last cycle and what was said about them, because the second one is the real rubric.
Some of you will do all of this correctly and still not get promoted, because the seats are finite and the timing is not yours. That is not a reason to skip it. It is a reason to know sooner whether you are in the wrong room.
And here is the part I want to leave you with, because it is the opposite of what your instinct will tell you: do not grind harder. Out-working the entire team is not a promotion strategy, it is a burnout strategy that produces a lot of invisible output. Ship about as much as your solid teammates ship. Then spend the energy you saved on picking the right work and making sure it lands where it counts.
Doing more of the wrong thing, faster, is how you spend three years being the most reliable person on a team and the least promotable person in the room.