How do you take a mid-level engineer and get them to senior?

Say what the level is before you plan anything

Promotion conversations go wrong at the definition. If the engineer thinks senior means five years and deeper knowledge of the stack, and the committee thinks it means leading work across more than one person without supervision, then every piece of effort in between is aimed at the wrong target and the disappointment at the end is guaranteed.

The definition that survives calibration is about scope and autonomy, not skill inventory. A useful way to put it is in terms of what arrives on their desk and what leaves it.

	Mid-level	Senior
Input	A well-formed task or a small feature	A problem, sometimes badly formed
Ambiguity	Resolved by asking you	Resolved by them, then told to you
Blast radius	Their own work	Their work plus a few people's
Failure mode you plan for	Needs review to catch mistakes	Escalates early, having already tried
Effect on others	Reviews well, helps when asked	Raises the level of people around them
Your involvement	You check in	You find out at the demo

Read that with the engineer, in their words, against real examples from the last quarter. Two things happen. Sometimes they discover the level is not what they wanted, which is a legitimate and valuable outcome. More often the conversation converts an aspiration into two or three concrete gaps, which is the only form in which it is workable.

Narrow to two or three gaps, in writing

A general goal of "get to senior" cannot be worked on. Two named behaviours can. Write them down in the shared document where you both can see them, in the form of what would be observably different.

"The two things standing between you and senior, as I see them today. First, you resolve ambiguity by asking me — on the notifications work you sent me four questions in a week that you were better placed to answer than I was. At senior I would expect a note saying here is what I am assuming and why, tell me if that is wrong. Second, you have not yet led a piece of work that involved somebody else's time. Everything you have delivered has been yours end to end, which is why it has all gone well. Those are the two. Nothing about your technical work is on that list."

Naming what is not a gap matters as much as naming what is. Engineers assume unstated criticism, so an unqualified statement that the code is not the problem removes an entire category of wasted effort.

Growth happens through assignments, not intentions

The mechanism by which people reach the next level is work they could not previously have done, with a support structure that makes failure survivable. Everything else — courses, reading, mentoring, conferences — supplements that and substitutes for none of it.

Designing such an assignment has four properties. It must contain genuine uncertainty, because a task whose answer is known develops nobody. It must require someone else's cooperation, since that is the boundary the level sits on. It must be consequential enough that succeeding is evidence and small enough that failing is recoverable — a project whose failure damages a customer commitment is a gamble with someone's reputation, not a development opportunity. And it comes with air cover stated out loud: if this goes wrong, I chose to hand it over and I will say so publicly.

Then the hard part, your behaviour during it. The commonest way a manager destroys their own stretch assignment is taking the decisions back the first time the engineer hesitates. Agree in advance which decisions are theirs and what they should escalate, then let them make a worse choice than you would have, provided it is reversible.

Collect the evidence as it happens

Calibration and promotion committees run on specifics, and specifics do not survive memory. Keep a running note per person, updated after one-to-ones and at the end of anything significant, holding the artefact and the impact rather than an adjective: the design doc they wrote and the two teams that reviewed it, the incident they led and what they changed afterwards, the junior engineer whose review turnaround improved because of their pairing, the decision they escalated well.

Assembling this in the fortnight before a committee produces a case built from whatever you happen to remember, which correlates with recency and visibility rather than contribution — and that is the mechanism by which quiet, high-contribution engineers get passed over. Four quarters of log is what lets you say in the room, "here are three examples, from June, September and January."

Visibility is part of your job, not theirs. Someone operating at senior on work nobody outside the team sees will not be promoted, and the fix is not telling them to self-promote. It is routing them into the forums where the work is discussed, having them present their own design rather than presenting it for them, and naming their contribution accurately in your own updates.

Saying not this cycle

The message that damages people is not the refusal, it is the vagueness. Be specific about where they are, what is missing, and what happens next, and do not spend the meeting managing your own discomfort.

"The decision is that it is not this cycle, and I want to give you the actual reason rather than a softened one. The case I put forward was strong on delivery and thin on the cross-team piece — the committee's view, and I did not disagree with it, was that the search migration was substantially your work but that it did not require you to bring anyone else with you. That is the one thing left. The ingestion consolidation starting next month needs three teams to agree an interface. I want you to own that, including the meetings I would normally run, and I will be in the room but not speaking. If that goes the way I expect, I will put the case again in the next cycle. What I am not going to do is promise you the outcome, because I do not decide it alone — what I will promise is that the work exists, that I will tell you every time I see a gap, and that nobody will be deciding this without knowing what you did."

The three elements are the real reason, one concrete piece of work attached to it, and an honest statement of what you do and do not control. Interviewers listen for the last one specifically, because a manager who promises outcomes they cannot deliver creates a worse problem two quarters later.

Where the organisation is the problem

Two situations deserve a mention because strong candidates raise them unprompted. Where levels are undefined, someone has to write them, and a manager who has drafted a level definition and had it adopted has done more for their engineers' careers than any number of coaching conversations. And where there is genuinely no headroom — a small team, a flat structure, a hiring freeze — the honest move is to say so early rather than let someone spend eighteen months building a case for a promotion that does not exist. You will lose some of them, and you will lose them as people who trust you.

The level is a scope, not a skill list; your job is to hand over that scope early enough that the evidence exists before the committee meets, and to be exact about which part of the outcome is yours to promise.