Back to Insights

The Conversion Loss

A management title changes who does the work. Your release plan needs to change with it.

6 min readBy The Bushido Collective
LeadershipEngineering ManagementCoachingTeam StructureAI
Share:LinkedInX
Before you make your best engineer a manager, open the next release plan. Which of her engineering commitments are you taking away? If you’re keeping a full engineering workload alongside the new management duties, you’ve budgeted for a new manager by spending the same person’s time twice.

She may be exactly the right person to lead. But the title changes what you need from her, while the release plan still records what you needed before. Keep both expectations intact and she has to choose which obligation to disappoint, or try to make up the difference after everyone else goes home.

If she’s already doing much of the management informally, the title could give her authority to match the work, with little extra demand on her time. Start from her actual workload, including the coordination the plan may never have acknowledged. That gives you a basis for deciding which engineering commitments can stay.

What the title changes

A difficult engineering problem can reward taking ownership and doing the work yourself. A difficult management problem may require helping someone else do it, even when taking over would be faster. Good engineers already mentor colleagues and coordinate work. Those skills matter, but responsibility for someone’s performance, pay, and working conditions adds obligations that a record of shipping software doesn’t establish readiness for.

Preparation is a real gap. The Chartered Management Institute’s 2023 research with YouGov, covering more than 4,500 UK workers and managers, reported that 82% of managers entered management without formal management and leadership training. That measures preparation across UK occupations. It can’t tell you whether your engineer will succeed, or how much difference a particular course would make.

There is also evidence that rewarding the old job can conflict with selecting for the new one. In Promotions and the Peter Principle, Alan Benson, Danielle Li, and Kelly Shue studied sales workers at 214 firms. Their 2018 paper found evidence that firms prioritized current sales performance over other characteristics that better predicted managerial performance. The authors left open whether the incentive to perform well enough to earn promotion justified the managerial mismatch. Their finding concerns sales, so it supplies a warning about selection criteria, not a verdict on your engineering team.

Your decision needs evidence about both jobs. If she already helps colleagues become more capable, that counts in favor of the move. If she wants the role mainly because it’s the only available raise, you have an org-design problem wearing a promotion’s clothes.

Count the AI gains where they actually occur

AI adds another assumption to inspect before moving her. The largest gains needn’t belong to your strongest engineer.

A June 2025 paper on field experiments at Microsoft, Accenture, and an anonymous Fortune 100 company covered 4,867 developers. Pooling the experiments, the researchers estimated about 26% more completed tasks with an AI coding assistant, with substantial uncertainty around that estimate. Less-experienced developers had higher adoption and larger productivity gains. The tools suggested code completions; the finding doesn’t establish that one experienced engineer can replace a whole team.

Newer tools also complicate measurement. In its February 2026 update, the research organization METR said its newer developer experiment gave an unreliable estimate of current gains. Developers reluctant to work without AI were selecting themselves or particular tasks out of the experiment, and parallel agent use made time accounting harder. The researchers believed gains had increased since their early-2025 study, but described their data as only weak evidence for the size of that increase.

Trace a recent AI-assisted change from the first draft through review and rework to acceptance. If it still depends on her reviewing generated code, taking away review time can leave more work waiting for her. If AI lets colleagues finish work that previously required her intervention, moving her into management may cost less engineering capacity. Check the kinds of work in the next release before relying on that gain; independence on a routine fix doesn’t settle who can review a risky migration.

What the handoff still costs

The conversion loss is the engineering contribution you give up while moving a proven builder into a job she’s learning. Management can produce a larger return through the rest of the team: resolving a priority conflict may let colleagues finish work that would otherwise sit blocked. Counting her old output and that hoped-for return at the same time still hides the trade.

Suppose she’s due to build an integration. You give it to another engineer so she can take on management, but keep her as the required reviewer and the person who settles every design question. The coding assignment has moved. The team still needs her attention to finish it.

Keeping her as a reviewer may be right while the new owner learns. Make that retained commitment visible, and check what comes out of the receiving engineer’s plan too. A handoff can need more of her attention before it needs less. A name change alone gives you no basis for counting the whole assignment as time freed.

Find out which job she wants

A management title can bundle together things that could be offered separately: better pay, more influence over technical decisions, and responsibility for people. Ask which of those she’s seeking before making her take the whole bundle.

Charity Majors described a useful distinction in her 2020 account of a conversation with Honeycomb engineer Martin Holman. He had managed before and had expressed interest in doing it again. When she asked whether he still wanted to, he explained that what he’d wanted was information and a say in his work. He already had those at Honeycomb, so he no longer felt a need to become a manager. That was his stated preference at the time; Majors said she’d support him if he changed his mind.

The distinction gives you a choice before you reorganize. For an engineer who wants greater technical scope, a credible technical career path needs pay and decision-making authority to match. A more impressive title with the same ceiling won’t give her what she asked for. Majors’s recommendations include comparable engineering and management pay bands, access to consequential decisions, and support for moving between the roles.

When she does want to manage, give her someone to learn the work with. An experienced internal manager who has time to discuss a difficult feedback conversation or a delegation decision is a sensible starting point. Their mentoring time needs room in their own plan too. Formal training can sit alongside that work.

If the experience is missing internally, outside coaching is an option. Revisit actual decisions with whoever supports her. For the integration handoff, does the new owner need more technical knowledge, or permission to make decisions she still reserves for herself? More coaching won’t resolve an authority gap unless someone inside the company changes who gets to decide. No coach can make an unchanged release commitment disappear.

Return to that release plan before the announcement. The engineering work she’s giving up needs another owner, a smaller scope, or an explicit delay. Which one are you choosing, so she doesn’t have to make the choice at night?

Want this looked at in your business?

Start with the rough map: thirty minutes, owner to owner, and a written report on where AI pays off for you and what it's worth. It's free, and if you don't need us the report says so.

Get your rough map, free

Not ready to talk? Stay sharp anyway.

We send insights like this to technical leaders every week or two. The thinking we bring to our engagements, no fluff, no spam.

Keep reading

Share:LinkedInX