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.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).