Short answer
The thing blocking most mid-level engineers is not technical. It is the ability to take an ambiguous problem, decide what is worth doing, disagree productively about it, and make the outcome visible. Those four skills are what the senior title is actually assessing.
There is a particular kind of frustration that shows up around the third or fourth year of an engineering career. You are good at the work. Your code is solid, your reviews are thorough, you are the person people ask when something is broken. And you keep watching people who are demonstrably worse engineers get the interesting projects, the visibility and the title.
This is almost never because the system is rigged. It is because after a certain point the job quietly stops assessing what you thought it was assessing.
The Skill That Stops Scaling
Raw implementation ability has a ceiling in career terms. Being twice as fast at writing correct code does not make you twice as valuable, because the constraint on most teams is not typing speed - it is knowing what to build, catching the design flaw before it ships, and getting five people pointed the same direction. Those are all communication problems wearing technical clothing.
The four conversations that decide your level
- Disagreeing with a technical decision in a way that gets you listened to twice, rather than filed under "always objects to everything".
- Reviewing someone's code so the standard stays high and the person still wants to work with you.
- Pushing back on a deadline without being the engineer who says everything is impossible.
- Making your work visible without it reading as self-promotion, which is the one most engineers actively refuse to do.
Start here
If you are trying to reach senior, the promotion mechanics matter more than any individual skill - read how to get promoted to senior engineer first, because it tells you what the criteria actually are and what evidence to start collecting now.
If you already know the gap is communication, start with disagreeing with your tech lead and code review feedback - those two produce the fastest visible change in how people respond to you.
The visibility problem, specifically
Engineers are unusually resistant to self-promotion, often on principle: the work should speak for itself. The work does not speak for itself, because the people making promotion decisions are not reading your pull requests. They are reading a document your manager wrote from memory.
The resolution is not to become someone who brags. It is to report outcomes rather than tasks, in writing, on a schedule - which most engineers find they are entirely comfortable with once it is framed as accuracy rather than salesmanship. Talking about achievements without bragging covers the specific formula.
If you are thinking about management
Do not take the job because it looks like the next rung. It is a different profession with a different scorecard, and there is a parallel technical track that goes just as far. The staff engineer path and the engineer-to-manager transition lay out both options honestly, including what each one costs.
Frequently asked questions
What skills do software engineers need to get promoted?
Beyond technical ability: handling ambiguous problems without someone scoping them for you, disagreeing productively about technical decisions, giving review feedback that keeps standards high without damaging relationships, and making your work visible to people who do not read your code.
Why do worse engineers get promoted over me?
Usually because promotion assesses scope and influence rather than implementation quality. An engineer who defines what should be built, gets the team aligned and makes the outcome legible will out-promote a stronger implementer who takes well-defined tickets.
Should I become a manager or stay technical?
They are parallel tracks at most companies, at the same level and pay band. Choose based on whether other people's problems genuinely interest you and whether you can get satisfaction from indirect credit - not on which appears to be a promotion.
How do I get visibility without self-promoting?
Report outcomes rather than tasks, in writing, on a regular cadence. "Notification failures dropped from 4% to 0.2%" is a fact rather than a boast, and it gives your manager something concrete to carry into calibration meetings.