Twelve Moves That Take You From Mid Level to Senior

The mid level plateau is real

Getting to mid level is mostly a matter of time and repetition. You learn the stack, you stop breaking things, you can be handed a well defined task and return working software. The path there is clear enough that most people walk it without thinking about it.

Then it stops being clear. The thing that got you here, doing assigned work well, is not what the next level rewards, and nobody tells you that directly. So a lot of capable engineers respond 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.

What follows is twelve heuristics for the part that is not obvious. They apply whether the next step is called senior, staff or something your company invented.

What seniority actually is

1. A title question + a count of years → the answer is scope, not time. Seniority is measured by the size of the thing you can be handed and the amount of ambiguity you can absorb on the way. A task, then a feature, then a system, then a problem area nobody has defined yet. Time only correlates.

2. A promotion goal + a plan to do more work → look for leverage instead. There is a hard ceiling on output from working harder and you are probably near it. The work that moves you up is work that makes other people faster: the tool, the document, the design decision, the interface that stops a whole category of bug.

3. A promotion + a hope it gets noticed → ask what the bar is, explicitly. Ask your manager what specifically is missing and what evidence would settle it, then ask for it in writing. Vague encouragement is the default answer and it is worth nothing. A written bar can be worked towards and can be held to.

Doing work that counts

4. A gap nobody owns + visible pain → own it. The flaky test suite, the release process everyone dreads, the service with no clear maintainer. Unclaimed problems are the fastest available route to demonstrating scope, because the demonstration is that you saw it and nobody had to assign it.

5. A technical decision + a room of opinions → write the options down. Two pages listing the choices, the trade offs and a recommendation converts an argument into a review. Whoever writes that document usually ends up shaping the decision, and it is a skill that transfers to every level above this one.

6. Impact + working alone → 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 work so three can move in parallel. This shift is the actual content of the senior transition.

Making it legible

7. Good work + no written trace → write it where it can be read. A design document, a postmortem, a summary on the ticket. Work that exists only as commits is invisible in every conversation that decides anything, and those conversations happen in rooms you are not in.

8. A promotion cycle + a surprise → your manager should never 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 actually need them in.

9. Feedback + only one source → collect it from peers. Ask two colleagues what you should do more of and less of. Managers see a partial and heavily filtered view. The people who work next to you know exactly what it is like, and almost nobody asks them.

The long game

10. Influence + no authority → the staff level skill is persuasion. 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 need, and being reliably right often enough that people ask before deciding rather than after.

11. A ceiling + a company that has no room → moving is a legitimate answer. Some organisations genuinely have no next level available, or a bar you cannot reach without a seat opening. Waiting for someone to leave is a plan with no timeline, and recognising that early is not disloyalty.

12. Five years out + no direction → pick one and revise it yearly. Deep technical, breadth across systems, or towards leading people. None is better, and you can change it, but drifting means your growth is set by whatever tickets arrived. A direction turns random work into accumulating evidence.

What else belongs on this list

Closing the specific skill gap that blocks your next scope rather than the most interesting one, since an engineer who has never operated anything in production will not be handed a design however much theory they have read. Asking a mentor for something small and concrete, because will you mentor me is a large open commitment that usually gets a polite non answer while would you look at this design does not. Keeping the pace survivable, since careers run in decades and a year of exhaustion buys a burnt out engineer who changes jobs to recover. Learning the business, which is the difference between an engineer who builds what was asked and one who is consulted about what should be asked. Working with people you learn from, since the team you sit in shapes your next two years more than any course. And keeping a record of what you did each week, because promotion cases are lost to bad recall far more often than to weak work.

The one I would put first, if I were choosing only one, is asking what the bar is and then getting it in writing. An extraordinary number of careers stall in the gap between an engineer who believes they are being evaluated on their code and a manager who is evaluating scope, with neither party ever saying so out loud.

The short version

Seniority is scope, not years. Chase leverage, not volume. Ask for the bar in writing. Own the problem nobody owns. Write the options document. Multiply through others. Leave a written trace. Never surprise your manager. Get feedback from peers. Learn to persuade without authority. Leave when there is genuinely no room. Choose a direction and revisit it each year.

Almost none of that is about writing better code, and that is the uncomfortable part. You still have to be good, but past a certain point being good stops being the constraint, and what limits people is that they kept optimising the thing that was already sufficient.