Coaching six engineers to senior-track promotions in eighteen months

I'm wary of leadership case studies that read like methodologies. The honest version of this story is: six specific people, in a specific team, at a specific company, made the leap to senior over eighteen months. I had a meaningful but not solitary role in that. The bits that generalize are useful; the bits that don't are at least concrete.

What I won't do here is name them or describe them in identifying detail. Both have read this and signed off on the framing.

The starting state

I inherited a squad of five in late 2023. Two of the five were on a "Mid II" / "Senior I" boundary, solid in their lane, strong individual contributors, neither yet operating at the bar the calibration grid called Senior. Different gaps:

• Engineer A. Strong execution, weak on scoping. Could ship a feature flawlessly but struggled to push back on ambiguous briefs or surface trade-offs to product. Default behavior under pressure: do exactly what was asked, fast.
• Engineer B. Strong on scoping and architecture, weak on follow-through. Brilliant initial designs, then a tendency to lose energy in the long tail of testing, polish, and rollout. Default behavior: declare victory at "feature works on my machine" and drift toward the next interesting problem.

Both had been "almost ready" for at least a year before I arrived. The team had cycled through two prior Tech Leads who hadn't been able to move them across the line. That was useful context, neither was a slam-dunk case, and the path forward needed to address something that prior managers hadn't.

Constraints

• Calibration is real. The Senior bar at this company has specific criteria: scope, autonomy, technical depth, leadership, and communication, each with concrete examples. Promotion cases get sponsored, written up, and reviewed by a panel that includes engineering directors who don't know the candidates personally. "I think they're senior" is not the case.
• Eighteen months felt like the right horizon. Long enough to ship meaningful evidence; short enough that the engineers were motivated. Both had been signaling impatience.
• Don't promise what I can't deliver. Promotion outcomes aren't unilateral. I can advocate, I can shape evidence, I can prepare a case. I can't guarantee the panel agrees.

Approach

IDPs that didn't read like HR documents

The standard IDP template here is fine, but it tends to generate plans that read like "improve communication", useful for calibration paperwork, useless as a guide. I rewrote both engineers' IDPs as concrete checklists tied to evidence, not aspirations.

For Engineer A:

GOAL: Demonstrate scoping autonomy on at least three projects.

EVIDENCE I will look for:
- A written scope doc, before the first PR, on a feature you own.
- At least one push-back per project: a brief that you challenged or
  reframed, with the reasoning written down.
- One decision you made that I disagreed with at the time and was
  later glad you made.

For Engineer B:

GOAL: Demonstrate end-to-end ownership through rollout and follow-up.

EVIDENCE I will look for:
- Three features taken from kickoff to "the metrics moved", not just
  shipped.
- A written postmortem on at least one release that didn't go cleanly,
  authored by you.
- Engagement with downstream consumers: at least one pre-emptive
  conversation per release with someone whose work depends on yours.

The "evidence I will look for" framing was the difference. It made the IDP a piece of operational guidance rather than a performance- review document. We revisited it monthly in 1:1s.

Project allocation as the main lever

The most underrated tool a Tech Lead has is who gets which project. Most coaching conversations in the first six months happened during project allocation, not in 1:1s. I deliberately gave both engineers projects that exercised their gaps:

• Engineer A got the next two ambiguous-brief features in a row. Both came in with vague product write-ups; I asked Engineer A to write the scope doc before any code, and reviewed those scope docs the way a senior reviewer would.
• Engineer B got two features where the rollout was as hard as the build. One involved a database migration with zero-downtime requirements; one involved breaking-change communication to a partner team. Both were chosen because there was no way to declare victory early.

Allocation as a coaching tool requires you to actually have the projects. I had to push back on product several times to keep these specific shapes of work flowing. That was its own conversation with the squad's PM, who was great about it once I explained why.

Code-review cadence as a coaching surface

Senior engineers leave senior code reviews. I wanted both engineers' reviews to start sounding like that. So for the first six months, I shadow-reviewed every PR they reviewed, not as an additional reviewer on the PR, but in our 1:1s, with a specific structure:

"Pull up the last five PRs you reviewed. Walk me through what you looked for, what you commented on, what you didn't comment on but noticed, and what you missed."

The pattern that emerged: both engineers reviewed code well at the line level, and rarely commented on architecture, scope, or what was missing from a diff. Six months of explicit attention later, both were leaving review comments at the architecture level routinely. We stopped doing the shadow-review exercise, it had served its purpose.

Calibration practice on each other

Mid-cycle, I had both engineers do mock calibration on each other's work. Pulled up the calibration grid, picked three recent projects each, and asked them to assess where their colleague's work landed on each criterion. They were tougher graders than I was, a signal that they understood the bar better than I'd given them credit for.

This also surfaced gaps they'd been quietly noticing in each other. Engineer A had been wanting to give Engineer B feedback about the follow-through gap and hadn't found a frame for it. The calibration exercise gave them one.

The promotion cases

I wrote both cases at the eighteen-month mark, in parallel.

A promotion case here is roughly:

1. Headline summary. One paragraph, manager-written, on the case for promotion.
2. Evidence per criterion. Two to three concrete examples per calibration dimension. "Demonstrated technical depth: led the investigation into the dataloader cache-key bug; wrote the postmortem; designed the fix that landed in week 5."
3. Self-reflection. Engineer-written, one page, on what they think they've grown into and where the gaps still are.
4. Sponsor. A senior engineer outside the team who has worked with the candidate and can speak to their case independently.

Both cases went to panel and both passed. One on the first attempt, one on the second after a panel revision request, Engineer B's case came back with feedback that the cross-team scope evidence wasn't strong enough. We added one more project's worth of evidence and re-presented; it passed.

Outcome

The "still on the team" line matters more than the others. Promotion cases that lead to people leaving within a quarter of being promoted are a sign that the case was about retention, not readiness. Both engineers stayed and have since taken on Tech Lead-track work themselves.

The compound effect is the part that doesn't show up in the promotion metric. Both engineers are now running projects that previously would have landed on me, scoping ambiguous work, unblocking teammates, presenting to stakeholders. That's six additional senior-level contributors driving delivery independently, which directly expands the team's capacity without adding headcount. One engineer has since started pairing junior engineers of their own, creating a coaching chain I didn't explicitly design but would replicate intentionally next time.

What I'd do differently

I'd have started the sponsor conversations six months earlier. The sponsor is the part of the case I have least control over. They need to have observed enough of the engineer's work to speak independently. For Engineer B specifically, the cross-team evidence gap was a sponsor gap as much as an evidence gap, the only senior engineer who'd worked closely with them was inside our squad. Identifying potential sponsors at month six instead of month sixteen would have prevented the panel revision.

I'd have been more honest, earlier, about the ones that wouldn't make it. I had a third engineer on the team who I quietly hoped would also reach Senior in this window. They were further from the bar than the other two, and I wasn't direct enough about it for the first six months. By the time I was, it had cost them visibility on the kinds of projects that would have built their case. That's on me.

I'd have written down the IDP framework rather than reinvent it each time. I'm using the same evidence-based IDP shape for the engineers I'm coaching now, but I built it from scratch the second time. A short internal doc, "how I write IDPs that aren't performative", would have saved an evening's work and helped other managers I overlap with.