Twelve Moves That Take You From Mid Level to Senior
Going from mid level to senior software engineer is about scope, not years. Twelve moves that actually get you there: leverage over volume, a written promotion bar, design docs, multiplying through others and choosing a direction.
Sep 8, 202614 min read
Going from mid level to senior software engineer: the short answer
The jump from mid level to senior software engineer is not a bigger version of the jump you have already made. Getting to mid level is mostly time and repetition: you learn the stack, you stop breaking things, and you can be handed a well defined task and return working software. Getting to senior is about scope. It rewards the size of the problem you can be handed, the amount of ambiguity you can absorb on the way, and how much faster the people around you move because you are there.
Nobody says this out loud, so a lot of capable engineers respond to the plateau by doing more of what already worked: more tickets, longer hours, tidier code. Two years later the tickets are still closing and the title has not moved. I have watched this happen to strong engineers in Pakistan and abroad, and I have been close to it myself.
What follows are twelve moves for the part that is not obvious. They apply whether your next step is called senior, staff or something your company invented.
What actually changes between mid level and senior
Most companies publish a career ladder, and if you read a few side by side (the open source Engineering Ladders framework is a good place to start) the pattern is the same. Technical skill keeps mattering, but the axis that moves is scope and influence.
| Dimension | Mid level engineer | Senior engineer |
|---|---|---|
| Unit of work | A well defined task or feature | A system, a project or a vague problem area |
| Ambiguity | Needs the problem shaped before starting | Shapes the problem, then breaks it down for others |
| Decisions | Implements the chosen approach well | Proposes the options, the trade offs and a recommendation |
| Impact on others | Helpful when asked | Deliberately makes the team faster through review, mentoring and tooling |
| Visibility | Work shows up as commits | Work shows up in design docs, postmortems and decisions |
| Relationship with the business | Builds what was asked | Is consulted on what should be asked |
Years correlate with this, which is why job adverts say "five plus years". But years are a proxy. Plenty of engineers with eight years are still doing mid level work, and some with four are clearly operating as seniors. If you want the longer version of this answer, I wrote it up in how to go from mid level to senior software engineer.
The twelve moves from mid level to senior software engineer
I have grouped the twelve into four parts: understanding what is being measured, doing work that counts, making that work visible, and the long game.
Understand what is being measured
1. Treat seniority as scope, not time. Seniority is measured by the size of the thing you can be handed and the amount of ambiguity you can absorb along the way. A task, then a feature, then a system, then a problem area nobody has defined yet. Ask yourself honestly which of those you are trusted with today, and what one step up would look like. That question is more useful than counting months until your next review.
2. Chase leverage, not volume. There is a hard ceiling on output from working harder, and most mid level engineers are near it already. The work that moves you up is work that makes other people faster: the internal tool, the runbook, the design decision, the interface that stops a whole category of bug from ever being written. One afternoon spent fixing the flaky local setup that costs ten engineers twenty minutes a week is worth more than another ticket, and people remember who did it.
3. Ask what the bar is, explicitly, and get it in writing. Ask your manager what specifically is missing and what evidence would settle it. Then send a short follow up message summarising what you heard. Vague encouragement ("keep doing what you are doing") is the default answer and it is worth nothing. A written bar can be worked towards, checked against in six months, and held to if your manager changes. If I could give a mid level engineer only one of these twelve, it would be this one.
Do work that counts
4. Own the problem nobody owns. The flaky test suite, the release process everyone dreads, the service with no clear maintainer, the alert that fires every night and gets ignored. Unclaimed problems are the fastest available route to demonstrating scope, because the demonstration is that you saw it and nobody had to assign it. Pick one that has visible pain, tell your manager you are taking it, and finish it properly.
5. Write the options down before the argument starts. When a technical decision has a room full of opinions, two pages listing the choices, the trade offs and a recommendation turn an argument into a review. Google's engineers call these design docs, and Malte Ubl's write up of how they work is worth reading: context and scope, goals and non goals, the design, and alternatives considered. He notes that a one to three page "mini design doc" is fine for smaller changes. Whoever writes that document usually ends up shaping the decision, and it is a skill that transfers to every level above senior. The Design Docs at Google entry in the library links the original.
6. Multiply through other people. At some point your own hands become the constraint. Reviewing well, mentoring deliberately, unblocking two people in ten minutes each, splitting a project so three engineers can move in parallel. This shift is the real content of the senior transition, and it is why the habits in the habits that make an engineer worth routing work through matter so much at this stage. If you want to practise explaining your reasoning to peers, my answer on how to explain technical ideas to other engineers is a good starting point.
Make the work visible
7. Leave a written trace. A design doc, a postmortem, a clear summary on the ticket, a short note in the team channel after a launch. Work that exists only as commits is invisible in every conversation that decides anything, and those conversations happen in rooms you are not in. Julia Evans makes the case well in her post on brag documents: you forget your own work, your manager forgets it too, and your manager is the one who has to explain to other people why you should be promoted. Keep a running list, updated weekly, of what you shipped, what you fixed and who you helped.
8. Never let your manager be surprised. Not by your work, not by your ambitions, not by a resignation. Regular short updates and one explicit conversation about where you are heading turn your manager from a judge into an advocate, which is the role you need them in. If you have never said "I want to be senior within the next year, what would it take?" out loud, your manager may genuinely not know.
9. Collect feedback from peers, not only your manager. Ask two colleagues what you should do more of and less of. Managers see a partial and heavily filtered view of your work. The people who sit next to you in reviews and incidents know exactly what it is like to work with you, and almost nobody asks them. Their answers are also the raw material for the "impact on others" part of any promotion case.
Play the long game
10. Learn to persuade without authority. Above senior you cannot direct anyone, and you are responsible for outcomes anyway. What works is writing clearly, building the case, finding out what other teams actually need, and being reliably right often enough that people ask you before deciding rather than after. Will Larson's staff engineer archetypes (Tech Lead, Architect, Solver and Right Hand) are a useful map of what this looks like at the next level, and his StaffEng guides and Tanya Reilly's The Staff Engineer's Path go much deeper.
11. Accept that moving is a legitimate answer. Some organisations genuinely have no next level available, or a bar you cannot reach until a seat opens. Waiting for someone to leave is a plan with no timeline, and recognising that early is not disloyalty. Before you decide, work through the questions worth answering before you change jobs and my answer on how often a developer should switch jobs. When an offer does arrive, Grokking Tech Salary Negotiations is a practical walkthrough of how to handle the conversation.
12. Pick a direction and revise it every year. Deep technical, breadth across systems, or towards leading people. None is better than the others, and you can change your mind, but drifting means your growth is set by whatever tickets happened to arrive. A direction turns random work into accumulating evidence. If you are unsure which way you lean, read tech lead, engineering manager or individual contributor and look at the staff engineer roadmap and the engineering manager roadmap side by side.
Senior software engineer skills teams actually check for
When a promotion committee or a hiring panel decides whether someone is senior, they are looking for evidence, not adjectives. This is what I have seen them look for, and what counts as proof.
| Skill | What convincing evidence looks like |
|---|---|
| System design | You designed a component others now build on, and you can explain why you rejected the alternatives |
| Operating in production | You have been on call, led an incident, and written the postmortem |
| Breaking down ambiguous work | You took a vague request and turned it into a plan with milestones that others executed |
| Code review | Your reviews catch design problems early, and people ask for you as a reviewer |
| Mentoring | A junior engineer you supported is now noticeably more independent |
| Communication | Non engineers understand your updates, and your design docs get approved without three rounds of meetings |
| Business sense | You pushed back on a requirement and saved the team real time because you understood the goal behind it |
The system design row is the one mid level engineers most often underestimate, because day to day work rarely forces it. If that is your gap, the system design roadmap orders the topics, my learning roadmap for system design explains the sequence, and Grokking System Design Fundamentals is a structured way to build the vocabulary before you need it in a design review.
The mistakes that keep good engineers stuck at mid level
These are the patterns I see most often in engineers who have been "nearly senior" for two years or more.
- Optimising the thing that is already good enough. Cleaner code, faster ticket throughput and deeper framework knowledge are all fine, but past a point they stop being the constraint. What limits people is that they kept polishing the sufficient skill.
- Closing the interesting skill gap instead of the blocking one. An engineer who has never operated anything in production will not be handed a design, however much theory they have read. Close the gap that stands between you and the next scope, not the one that is most fun.
- Asking for mentorship in the abstract. "Will you mentor me?" is a large open commitment that usually gets a polite non answer. "Would you look at this design doc and tell me what you would change?" gets a yes.
- Never learning the business. The difference between an engineer who builds what was asked and one who is consulted about what should be asked is almost entirely domain knowledge. My answer on how to think like an engineer instead of just completing tasks goes into this.
- Burning out to get there. Careers run in decades. A year of exhaustion does not buy a promotion; it buys a tired engineer who changes jobs to recover.
- Losing the evidence. Promotion cases are lost to bad recall far more often than to weak work. See move 7.
What AI changes about the senior bar
AI coding tools make it cheaper to produce code, which pushes more of the value towards the judgment senior engineers are supposed to have. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, but 46% said they do not trust the accuracy of the output, and 45% said debugging AI generated code is time consuming.
That gap between adoption and trust is exactly where a senior engineer earns their title. Knowing when generated code is subtly wrong, when a design will not survive real traffic, and when the tool is confidently solving the wrong problem is the kind of judgment that is hard to automate. If anything, the moves above matter more now, because "I closed a lot of tickets" is a weaker signal when a tool can close many of them.
A six month plan to get from mid level to senior
| Month | Focus | Evidence you should have by the end |
|---|---|---|
| 1 | Get the bar in writing, start a weekly brag document, pick one unowned problem | A written summary of the promotion bar, agreed with your manager |
| 2 | Fix the unowned problem properly and announce it | A measurable before and after (build time, flake rate, incident count) |
| 3 | Write your first design doc for a real decision | A doc that was reviewed and led to a decision |
| 4 | Mentor one person deliberately and ask two peers for feedback | Specific peer feedback you acted on |
| 5 | Lead an incident review or a cross team piece of work | A postmortem or project summary with your name on it |
| 6 | Review progress against the written bar with your manager | A clear yes, a clear list of gaps, or a clear signal that it is time to look elsewhere |
The career growth roadmap breaks this down in more detail, and the career growth cheat sheet is the one page version to keep open.
Learn it on Sefism
- Career growth roadmap and the career growth cheat sheet
- Staff engineer roadmap and the staff engineer cheat sheet
- System design roadmap
- Grokking System Design Fundamentals for the design vocabulary senior work assumes
- Path to Senior Engineer Handbook and The Software Engineer's Guidebook
- Grokking Tech Salary Negotiations for when the promotion or the new offer arrives
FAQ
How many years does it take to go from mid level to senior software engineer?
Many engineers get there somewhere between four and seven years of total experience, but years are only a proxy. What decides it is whether you can own a system or an ambiguous problem end to end and make the people around you faster.
What is the difference between a mid level and a senior engineer?
A mid level engineer delivers well defined work reliably. A senior engineer shapes vague problems into plans, makes and documents design decisions, and multiplies the team through review, mentoring and tooling.
How do I ask my manager for a promotion to senior?
Ask what specifically is missing and what evidence would settle it, then confirm it in writing. Revisit that written bar every few weeks with concrete examples from your brag document.
What skills do I need to become a senior software engineer?
System design, operating software in production, breaking down ambiguous work, strong code review, mentoring and clear written communication. Business understanding is the one most people forget.
Should I switch companies to get promoted to senior?
Sometimes. If your company genuinely has no room or keeps moving the bar, changing jobs is a legitimate route. Get the bar in writing first so you know whether the problem is you or the organisation.
Ask your own question
If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.
Want a learning roadmap built around you, written answers to your own questions and a place to talk through your next career move? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.
Stay in touch
- LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
- X (Twitter): short practical thoughts on engineering and careers.
- Instagram: quick tips and a more personal side.
- Sefism Discord: meet other students and engineers working through the same job market and share what is working.
- Sefism on YouTube: walkthroughs and talks.
Comments (0)
Comments are closed for now.
No comments yet.