The pull request that sat for four days
Here is the moment you notice. A junior dev opens a PR on Monday morning. It's small — a config change, maybe forty lines. By Thursday it still hasn't been reviewed, because the only person who can sign off is your new engineering manager, and your new engineering manager spent the week in a hiring loop, a planning offsite, two skip-level 1:1s, and a vendor call. The forty-line change is now blocking three other branches. That's the tell. Six months ago this person merged the trickiest refactor in your codebase over a weekend. Now they can't clear a config diff in four days.
You did the obvious thing. Your lead engineer was the one holding the architecture together in their head, the one everyone Slacked before touching the payments service. Headcount grew, you needed someone to own the team, and you handed the title to the person everyone already deferred to. It felt like rewarding your strongest player. What you actually did was quieter and more expensive: you took your highest-leverage individual contributor off the keyboard and bet their full salary on a skill — managing humans — that you had never once watched them perform.
The bet is failing in a specific, recognizable pattern. Velocity dropped because the bottleneck moved from "hard problems" to "this one person's calendar." Your juniors aren't being coached; they're being silently corrected, because a stressed senior engineer's instinct under pressure is to grab the keyboard and fix it themselves rather than spend ninety minutes teaching someone slower. And the manager hates it. They didn't take this job to mediate a disagreement about sprint scope. They took it because saying no felt like turning down a promotion. Across scaling tech teams this same transition fails for roughly 40% of new managers inside the first 18 months — and engineers, who self-select for deep focus over context-switching, sit at the rough end of that range.
What Google found when it actually measured this
The assumption underneath the promotion — that being better at code makes you better at leading coders — has been tested at scale, and it does not survive contact with data. Google ran a multi-year internal study, Project Oxygen, to rank the behaviors that actually distinguish its effective managers. Of the eight behaviors that mattered, technical expertise finished dead last. The two that finished first were being a good coach and empowering the team without micromanaging — the precise two muscles a "just let me fix it" engineer has never had a reason to build. You promoted on the one dimension that ranked eighth.
Gallup puts a harder number on it: companies pick the wrong manager about 82% of the time, because the raw talent that makes a great manager — naturally engaging people, driving accountability, building relationships — is genuinely rare, sitting in roughly one person in ten. Coding talent and managing talent are two different lotteries. Winning one tells you almost nothing about the other. And there's a second, quieter signal worth reading before you ever make the offer: a lot of strong engineers don't even want the job. Research on the IC-to-manager step shows a real reluctance to take the leap — many accept the title only because, in a broken org chart, it's the sole path to more money. That's not ambition. That's a comp problem wearing a leadership costume.
Now price the failure. When this breaks, you don't lose one person — you lose the engineer (who leaves embarrassed) plus a teammate or two who quit the manager, not the company. Replacing a senior engineer runs anywhere from 30% to well over 100% of their salary once you count recruiting, ramp, and the work that didn't ship during the gap. On a five-person team a botched manager can cascade into a seven-figure hole — recruiting spend, broken roadmap, and the architectural context that walked out the door — inside a single year. That's a direct EBITDA hit no amount of weekend heroics buys back, and it's the same compounding cost pattern as any mis-hire at the senior level.
The reversal: get them back to the keyboard without it reading as a demotion
If you recognize the four-day PR, you intervene now — not after the resignation Slack. Three moves, in order.
Have the role-change conversation this week. The job is to strip the shame out of stepping back. Frame it as a role change, not a level change. Something close to: "You're spending most of your week firefighting and almost none of it on the architecture only you can do. I need your brain on the systems more than I need you running a calendar. Let's build you a seat where you shape the product without owning the people." Said early, that's a relief. Said after they've already updated LinkedIn, it's a severance conversation.
Build the dual-track ladder so the back door isn't a step down. The reason this trap exists is that your org chart only has one way up, and it requires managing people. Stand up a Staff and Principal Engineer track that pays in parallel with the management track — a Principal who owns architecture, technical risk, and mentorship without direct reports should be able to out-earn a Director. Until a senior engineer can get richer by going deeper instead of going wider, every strong IC will keep accepting a job they'll be bad at, purely for the raise.
For every future promotion, make it a 90-day trial, not a coronation. Run an explicit "acting manager" period with scorecard items that have nothing to do with shipping code: did they hold weekly 1:1s, did they make a hire, did team velocity steady out without them touching the keyboard. At day 90, either confirm it or hand them a graceful return to IC with zero loss of face — because the off-ramp was named on day one, not improvised in a crisis. If you're already past the warning signs and senior people are threatening to walk, you're in stabilization territory, and the playbook shifts to triage — closer to a 48-hour leadership-gap plan than a gentle career chat. Either way the principle holds: let your best coders code, and hire managers who actually want to manage. Solve for strengths, not status.
