The Conversion Loss

Six months later, count what you actually have. The pull requests that used to carry the release now trickle out between one-on-ones and Slack triage. She's in meetings she doesn't run well, mediating disputes nobody trained her to mediate, and doing the team's hardest tickets at 11pm because that's the only part of the job that still feels like hers. The team can tell she'd rather be coding, because she would. You didn't gain a manager. You converted your best builder into a stressed one, and the building went with her.

This is the most expensive routine promotion in software, and almost every company runs it on autopilot.

The job you handed her isn't the job she was good at

Start with the thing nobody says out loud at the promotion. Management isn't a higher-difficulty version of engineering. It's a different job, with a different unit of output, that happens to share a hallway with the old one. Charity Majors put it as plainly as anyone has: management is not a promotion, it's a change of career. The traits that made your engineer worth promoting, deep focus, ownership of a system end to end, the satisfaction of a hard problem solved alone, are close to the opposite of what the new role rewards: interruption tolerance, delegating the fun parts, and measuring your day by other people's output instead of your own.

The data on how that goes is not ambiguous. The Chartered Management Institute, surveying more than 4,500 workers and managers with YouGov, found that 82% of people who step into management have had no formal training for it. It called them accidental managers: promoted because they were good at the previous job, or popular, or simply available, then left to figure out an entirely new one in public. Harvard Business Review documented the same mechanism from the performance side, that the most productive individual contributors often make the worst managers, precisely because personal output and team development pull in different directions.

None of this is your engineer's failing. She's doing exactly what the org set her up to do: excel at a job it stopped letting her do, while improvising one it never taught her.

Why the bill is bigger than it used to be

Here's what changed, and why this old problem deserves a fresh look right now.

For most of software's history, pulling your best engineer partly off the tools cost you one very good engineer's worth of code. Real, but bounded. AI moved the ceiling. A strong builder with agentic tooling in her hands now does what used to take a small pod: she scopes, generates, reviews, and ships across surfaces that would have needed three people a year ago. When the tools arrived, the gap between your best builder's output and everyone else's didn't hold steady. It widened.

So look again at the trade. At the exact moment AI made your single most leveraged builder more valuable than she's ever been, the org's one reward mechanism yanks her off the work where that leverage lives. You're not spending down an asset that's holding flat. You're spending down the one that's appreciating fastest.

Call it the conversion loss. Promotion feels like addition, a manager added to the org chart. It's actually a conversion: one great builder transformed into one novice manager, and like every conversion in the physical world, it sheds something in the change. Run a current through a transformer and part of it always leaves as heat; you never get all of it out the far side. Promote your best IC without a plan and the loss shows up as stalled shipping on one side and a struggling, underwater leader on the other. Two jobs, both now done worse than one of them was done before.

The mistake isn't the promotion. It's believing there's one ladder.

The reflex fix is to stop promoting strong ICs, and that's wrong too. Some of them genuinely want to lead, and starving them of that path just sends them somewhere that offers it. The real error sits underneath the promotion: the belief that the org has a single ladder, so the only way to reward someone is to change their job.

Two moves come out of dropping that belief.

The first is to build a real technical track, so your best builder can grow in scope, title, and pay without ever managing a person. Charity Majors calls the healthy version the engineer-manager pendulum, where moving between the two roles is lateral and expected, not upward and permanent. If the only way your company can say "you matter" is a people-management title, that's an org-design problem wearing a promotion's clothes.

The second matters when someone does want to lead: treat leadership as a skill you coach into a person, in the real work, not a title you drop on them and hope. The accidental-manager number sits at 82% because the standard playbook is to hand over the team and walk away. Leadership isn't learned from a slide deck the week before the reorg. It's learned in the actual one-on-one that's going sideways, the actual delegation that's tempting to snatch back, the actual quarter where their instinct is to close the tickets themselves and the harder right move is to let someone else struggle through it and grow.

That's the work a coaching lane does: a new leader paired with someone who's run the transition before, working through their real situations as they happen, until leading stops feeling like a second job stapled onto the first and starts being a skill they own. It runs alongside a building lane that keeps the actual building moving while they learn, so you don't pay the conversion loss on both sides at once. Two different jobs, done by two different kinds of attention, priced as two different lanes instead of pretending one person suddenly holds both.

So before you print the next title as a thank-you, ask the quieter question: are you rewarding your best builder, or are you quietly taking away the job she was great at and handing her one nobody taught her to do? The clap on Friday feels like the answer. The next two quarters are the real one.