Promotion when they are one level of scope short

"An engineer wants a promotion. They're one level of scope short. Run the conversation."

What the question is actually testing

Whether you are specific. Vagueness here is the cruellest thing a lead does, because it leaves someone working hard on the wrong things for another year while believing they are close.
Whether you understand that promotion is your job, not theirs. At senior and above, the evidence a packet needs comes from the work someone is assigned. If they have never been given work that generates staff-level evidence, the gap is mine.
Whether you can say no without demotivating. The failure modes are symmetric: soft-no that reads as yes, and honest-no delivered as a verdict rather than a plan.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: check whether the gap is real, and whose it is

Before the conversation, an hour with the rubric and their last two years of work:

Read the next level's rubric line by line and mark where they are: met, partially met, not demonstrated. Not "roughly there"; per line.
Look for evidence, not impressions. Design documents, incidents led, migrations driven, people mentored with a visible outcome, decisions they made that others followed. Artifacts a calibration room can read.
Ask whether they have had the opportunity. This is the question that decides whose problem it is. If the gap is cross-team influence and every project they have been given was inside one team, they cannot have demonstrated it, and that is on me.
Check the calibration bar, not just the rubric. What did the last two people promoted to that level actually do? Rubrics are aspirational; calibration rooms are comparative.
Talk to their peers and partners before the conversation, so the feedback is the organisation's view rather than only mine.

The outcome is one of three:

Finding	The conversation is about
Gap is real, and they have had the opportunity	Specific capability development, with a plan
Gap is real, but they never had the opportunity	My failure. The plan is a work assignment, and I say so
Gap is not real; the packet is weak	Evidence-gathering, which is a very different and much shorter conversation

The third case is more common than people expect. Someone can be operating at the level and have no artifacts a calibration room can point to, which is a documentation problem rather than a performance one.

The conversation

Private, unhurried, and open with the answer so they are not spending the whole conversation trying to work out what you are about to say.

"I want to be direct, because I don't think being vague about this would be kind. I'm not going to put you up this cycle, and I want to tell you exactly why and exactly what would change it.

Looking at the staff rubric: your technical depth is there, your code and design quality are there, and your mentoring of Priya and Sam is genuinely the evidence that section asks for. What's missing is scope. Everything you've driven in the last eighteen months has been inside our team. Staff needs evidence that you moved something across teams: a decision that other teams adopted, a standard you got three groups to follow, a migration you led that wasn't yours to mandate.

And I want to be honest that some of that is on me. I haven't put you on work that would generate that evidence, because you're the person I rely on for our highest-risk delivery, and that's been convenient for me. So the plan isn't 'go and be more strategic'. The plan is that I give you work where cross-team influence is the job."

Four properties, and each is being scored. It leads with the answer. It is specific against the rubric, naming what is met as well as what is not. It names my contribution, which is almost always present and almost never volunteered. And it converts the gap into an assignment, so they leave with work rather than with an instruction to be different.

Then: the plan, with artifacts and a date

Vague plans are broken promises with extra steps. Write it down:

"Three things over the next two quarters.

One: you lead the authentication migration. It touches four teams, none of which report to us, and the hard part is getting them to agree a sequence. That's exactly the evidence the rubric wants, and I'll back you in the rooms where I need to.

Two: you write and drive the API standards RFC. Not because we need the document, but because getting three teams to adopt it is the thing that's missing.

Three: you present the ranking redesign at the architecture review. Visibility to the people in the calibration room is part of this, and it's the part engineers most often think is unfair. It's not a popularity contest; it's that a room can only promote someone whose work they've seen.

We'll review in March. I'm not promising a promotion in March; I'm promising that if those land, I'll have a packet I can argue for, and I'll tell you honestly in January if I think it isn't tracking."

Three properties. Named work, not qualities. A date. And an explicit statement of what is and is not being promised, because "do these things and you'll be promoted" is a commitment you do not control, and making it is how you lose someone's trust permanently when the calibration room disagrees.

Then: build the packet continuously

Promotions are won two quarters early, by assigning work that generates evidence. The packet should be a file you add to as things happen, not a document you write in March:

The design doc, linked.
The migration outcome with numbers.
Quotes from the partner teams, collected at the time, when people remember.
The incident they led and the postmortem they wrote.

Writing a packet from memory at the deadline is how good engineers get stuck: the evidence existed and nobody wrote it down.

And be honest with yourself about the retention risk

If this person is genuinely close, they may leave. That is a legitimate outcome and pretending otherwise helps nobody. What reduces it is that the conversation gave them a real path with real work, rather than a deferral. What increases it is a vague no, or a promise you cannot keep.

If they do start looking, I would rather they leave having been told the truth than stay for another year on the strength of an implication I never intended.

Where this goes wrong

Being vague to be kind. "You're really close, keep doing what you're doing" is the worst possible answer. It is heard as a yes, it produces another year of the same work, and the next conversation is much worse because now they have evidence you misled them.

Making it about them when it is about me. If they have never been assigned cross-team work, "you need to show more scope" is unfair and they know it, even if they cannot articulate why.

Promising a promotion. You do not control the calibration room. Promise the packet and your advocacy; never promise the outcome.

Confusing tenure with scope. "You've been at this level three years" is not an argument, in either direction. Time served is not evidence.

Listing only what is missing. The conversation must include what is met, both because it is true and because a list of only deficits is not actionable, it is demoralising.

Leaving it until packet season. If the first time someone hears they are a level short is when the cycle opens, that is a management failure. No surprises applies to promotion exactly as it does to performance.

Interviewer follow-ups

"They say the rubric is subjective and everyone else got promoted with less." Take it seriously rather than defending the process, because sometimes they are right. I would go and look at what the last two people promoted actually did, and if their case is comparable I would say so and change my position. If it is not, I show the specific difference: "here's what X drove across three teams; here's the equivalent I don't have for you yet." Concrete comparison beats appeal to process, and being willing to be wrong about this is what makes the rest of my feedback credible.

"They ask 'if I do these three things, will I be promoted?'" I answer honestly and precisely: "If those three land the way I expect, I'll have a packet I can argue for, and I'll argue for it. I can't promise the outcome because I don't control the room. What I can promise is that I'll tell you in January if I think it isn't tracking, so you're not finding out in March." The interim checkpoint is what makes the honest answer acceptable rather than evasive.

"They're a flight risk and you need them on the current delivery." That conflict is exactly why they are one level short, and it is worth naming out loud to myself. Keeping the strongest person on the most critical delivery is locally rational and it is precisely what starves them of the evidence they need. The resolution is that someone else takes the critical delivery and I accept the delivery risk, because the alternative is losing them. If I genuinely cannot, then I should be honest that the promotion is a year away for structural reasons, and let them make an informed choice.

"They disagree and escalate to your manager." Good, and I would say so. I would brief my manager beforehand with the same rubric analysis I gave the engineer, so there is no daylight between the two accounts. If my manager sees it differently I want to know that, because it means my calibration is off and that affects everyone on the team, not just this person.

"What if the gap is capability rather than opportunity?" Then the plan is different and I should say so plainly rather than dressing it up as an opportunity problem. Scoped stretch work with support, pairing with someone already at the level, and a specific skill named rather than a general aspiration. And a realistic timeline, which for a genuine capability gap is longer than two quarters. What I would not do is offer an opportunity plan for a capability gap, because they will execute it, still not be promoted, and be entitled to be furious.

Production evidence

Will Larson's Staff Engineer documents the pattern directly: promotion to staff requires evidence of scope beyond a single team, that evidence comes from the work someone is assigned, and the manager's job is to create the opportunity rather than to wait for it. His writing on promotion packets is the practical reference.

Camille Fournier's The Manager's Path supplies the no-surprises principle and the argument that specificity is a form of respect in career conversations.

Google's and Meta's published promotion processes both work through a committee reading a packet of evidence, which is why "visibility to the room" is a real mechanism rather than politics: a committee can only promote on the basis of artifacts it can read.

Tanya Reilly's writing on glue work is directly relevant to the failure mode: the work that makes teams function is often invisible in a packet, and a lead's job includes making sure that work is either visible or redistributed, so the person doing it is not systematically disadvantaged at promotion time.

Interview delivery note

Open with the structure, and then with the diagnosis that most candidates skip: "First move, information I'd gather, line I wouldn't cross. And before the conversation I'd go through the next level's rubric line by line and ask one question that decides everything: have they had the opportunity to demonstrate what's missing? If the gap is cross-team influence and every project I've given them was inside the team, the gap is mine."

Then the conversation itself: "I'd lead with the answer so they're not spending it guessing, be specific against the rubric including what's met, name my own contribution, and convert the gap into named work rather than an instruction to be more strategic. Then a plan with three specific pieces of work, artifacts, and a review date."

The two lines that make it a lead-level answer: "I'd promise the packet and my advocacy, never the outcome, because I don't control the calibration room. And I'd commit to telling them in January if it isn't tracking, so they're not finding out in March."

Close: "The line I wouldn't cross is being vague to be kind. It's heard as a yes, it costs them a year, and the next conversation is far worse."

The Staff & Team Lead Interview Reference