One-on-Ones That Build the Promo Case
Most one-on-ones are a status meeting with better seating. Run the weekly thirty minutes as evidence collection instead, and the promotion case is already written by the time the cycle opens, in your engineer's own words rather than your summary of them.
Most one-on-ones are a status meeting with better seating. The engineer walks through what they shipped, the manager nods, they agree the sprint is roughly fine, and thirty minutes dissolve into information that was already in the ticket tracker. Nobody leaves worse off. Nobody leaves with anything, either.
Then the promotion cycle opens and the manager sits down to write a case from memory. Memory reliably returns the last six weeks and the two loudest incidents. The engineer who quietly unblocked three other teams in March is not in the document, because March is gone. The case comes out thin, the committee is unconvinced, and everyone blames calibration.
The status one-on-one is a wasted asset
Nothing about a status one-on-one is harmful. That is exactly why it survives. It feels productive, it fills the slot, and both people leave with the comfortable sense that they are in sync.
But you already have status. It is in the board, the pull requests, the deploy log, the incident channel. Spending your only recurring private conversation re-reading those out loud is spending the scarcest slot in the week on the most available information in the company.
What is not available anywhere else is the reasoning. Why they chose the boring approach over the interesting one. What they saw in the design review that nobody wrote down. Which conversation they had in a hallway that made the migration go smoothly. None of that is in a ticket, and all of it is what a promotion case is made of.
Promo season is a writing deadline
The mistake underneath almost every weak promo doc is treating the cycle as the moment to find out what someone did. By then you are doing archaeology on your own team. You dig through a year of standup notes, you ask the engineer to remind you, and what you get back is a list of projects with the judgment sanded off.
Reframe the cycle as the deadline for assembling and writing, not for discovering, and the work moves to where it belongs: the fifty-odd weekly conversations you were going to have anyway. I have written about the promo packet as a leadership artifact rather than paperwork. This is the collection mechanism that makes that possible without heroics in the last two weeks.
What a committee actually accepts
Committees are not unkind. They are constrained. They are reading many cases, they do not know your engineer, and they are checking one thing: has this person already been operating at the next level, repeatedly, where someone other than their manager could see it.
A committee is not deciding whether your engineer is good. It is deciding whether you have shown them someone already working at the next level. Those are different questions, and only one of them is answerable with evidence.
Scope you can name without adjectives
"Owned the notification service" is scope. "Was a huge contributor across the platform" is an adjective wearing a scope costume. The first one a committee can picture; the second one it discounts, because it has read forty of them this cycle.
Outcomes somebody else will confirm
The strongest line in any case is one a person outside the reporting chain would independently repeat. That is why the partner team's opinion matters more than your own, and why it has to be gathered while the work is fresh rather than reconstructed later.
The decision, not the task
Tasks show that someone is busy. Decisions show level. The question that separates them is whether someone else could reasonably have decided differently, and whether your engineer knew that when they chose. This is the same evidence problem that governs influence without authority, pointed inward at your own team.
Three questions that turn status into evidence
You do not need a new meeting or a new template. You need three questions in rotation, one per week, asked after the status part has been dispatched in five minutes.
What did you decide this week that someone else could reasonably have decided differently? This surfaces judgment. If the answer is nothing, that is useful too: it usually means the person is being handed tasks rather than problems, which is a scope conversation you want to have ten months before the cycle, not two weeks before it.
Who outside this team is better off because of something you did? This surfaces reach, and it names the people worth asking for peer feedback later. Write the names down. Committees weight cross-org impact heavily, and at the deadline you will have a list instead of a guess.
What did you do this month that you would not have been trusted to do a year ago? This surfaces trajectory, which is the axis most cases underserve. A committee is looking for growth it can see, and the person who lived it is the only one who can point at the change precisely.
Write it down the same day, in their words
One running document per person, newest entry at the top, three or four lines a week. Date it. Keep their phrasing rather than your summary, because the specificity is the value and your summary is where it gets lost.
Then do the part that most managers skip: share the document with the engineer. A running case they can read changes the relationship from evaluation to collaboration. They correct what you got wrong, they add what you did not see, and they start noticing which kinds of work show up in it and which do not. That last effect is worth more than the document.
It also makes the hard conversation cheap. When the evidence for the next level is not accumulating, both of you can see it on the page in June rather than arguing about it in November. Saying "this row is still thin, what could you take on that would fill it" is a far kinder sentence than "you are not quite there yet" delivered after a rejected case.
The honest limits
This does not manufacture a promotion. If the scope is not there, a well-documented year of the wrong work produces a well-documented rejection. Evidence collection makes a real case legible; it does not make an absent case exist, and pretending otherwise damages your credibility with the committee for everyone you bring next time.
It also should not curdle into surveillance. The document is built with the person, visible to the person, and about their growth. The moment it becomes a private ledger of performance you keep on them, you have built something else, and they will feel the difference long before they can name it.
And it works only if you protect the slot. A one-on-one that gets cancelled for a launch, twice, has taught the engineer exactly where they rank against the launch. Move it rather than drop it.
The promotion case your engineer deserves is being generated every week, in conversations you are already having, and thrown away every week by a meeting that reads the ticket tracker aloud. Changing that costs no new meetings and no new process. It costs three questions and the discipline to write the answers down while they are still true.
Haseeb Afsar