Why Becoming an EM Makes You Worse at Your Job — For About Six Months

Why this matters

Everyone sells the EM move as a promotion. It's actually a demotion in leverage for two quarters straight — you'll make worse calls than you did as an IC, and if nobody warns you going in, you'll read that as proof you don't belong in the seat instead of the toll for taking it.

Month 4: the call I would've gotten right six months earlier

A report on my team wanted to let our coding agent auto-merge 'low-risk' PRs on one service — dependency bumps, small refactors, nothing that needed a human reading the diff. He wrote it up: low complexity, high test coverage, clean rollback story. I read the doc, asked two questions, said go. Two weeks later, one of those auto-merged PRs touched a file mid-migration on a stateful schema change nobody had flagged as in-flight. It shipped clean, passed CI, sat quietly for three days, then broke during an unrelated incident when the rollback path assumed the old schema. Six hours gone, and a Saturday with it.

As an IC, I would never have signed off on that from a summary. I'd have pulled the actual diff, checked what else was touching that table, and caught the in-flight migration in about ten minutes. As EM, I signed off on someone else's read of the risk — and I didn't clock that anything was wrong until the third postmortem in a row landed on the same line: 'if I'd looked at the code myself, I'd have caught this.' That repetition is what told me my own track record had quietly gotten worse since I picked up the title.

The thing nobody says out loud: a leverage deficit, not a skill regression

The pitch for the EM role is always 'more leverage' — your decisions now scale across a team instead of just your own output. True, eventually. What nobody puts in the offer letter is that the first two quarters run the opposite direction: a leverage deficit. You've given up the feedback loop that made you good at the job, and the new one doesn't exist yet. You haven't built the judgment, the trust calibration, or the team maturity that make delegated decisions reliable. You're worse at the job before you're better at it, and there's no way to skip that gap — only to shorten it.

The mechanism: two feedback loops running at different speeds

As an IC, the loop closes in hours. You write code, CI runs, a reviewer comments, it ships, you watch the dashboard. Right or wrong is a same-day fact, and it's your fact — nothing filtered it on the way to you.

As a manager, the loop closes in weeks, and someone else's execution sits in the middle of it. A report makes a call, builds it over a sprint, and you find out it was wrong in a retro or a postmortem — filtered through their explanation, their context, their blind spots as much as yours. That gap is disorienting, and the instinct it produces is predictable: reach back into the old loop. Review the PR yourself. Drive the incident yourself. Write the design doc yourself. It feels productive because it's fast and it closes today, the way IC work always did. It's actively corrosive because every time you do it, your report gets zero reps at building the judgment that loop was supposed to build in them.

Three incidents where 'I'll just fix it myself' cost more than it saved

• ▹An agent-generated refactor PR looked clean but hid a race condition in a queue consumer. My report was about to approve it. I took the review myself, fixed it in twenty minutes, moved on. Three weeks later he approved a different agent PR with the same category of concurrency bug — he'd never had the rep that would've taught him to spot it, because I'd absorbed the one lesson that could have.
• ▹During an on-call escalation, a junior engineer was running agent-assisted triage and froze on the rollback decision. I took the terminal and drove the mitigation myself instead of coaching him through it. That night resolved faster. Next incident, he froze again — because the only rep he had was watching me do it, not doing it himself under pressure.
• ▹I thought a report's proposed service-boundary redesign was mediocre, so I rewrote it myself over a weekend instead of pairing with him to sharpen his version. His next three proposals came back more hedged, more conservative. He'd learned, correctly, that I'd override the ambitious version anyway — so why bring one.

What changed at month 6 wasn't skill — it was which loop I was optimizing

I stopped grading myself on 'was my call right' and started grading myself on 'did my reports' calls get better.' Concretely: when I disagreed with a decision but the blast radius was small enough to tolerate, I let it ride instead of overriding it — and treated the outcome as a calibration signal about their judgment, not just a bet I'd won or lost. In the AI-agent era this compounds fast, because your reports aren't just making their own calls anymore — they're also deciding how much autonomy to grant the agents they run. Keep personally reviewing every agent-generated PR, keep personally setting every agent's guardrails, and neither muscle develops: not their judgment about their own work, not their judgment about what to trust an agent with. The job stopped being 'have the best individual judgment in the room' and became 'be the reason the room's judgment is rising.'

The reframe for tomorrow

If you're about to take the title: budget six months of feeling measurably worse at 'being right' as the structural cost of the transition, not evidence you took the wrong job. The metric to watch isn't your own call quality anymore — it's the trend in decisions your reports make and close without escalating to you, while outcomes hold steady or improve. When that ratio moves and quality doesn't drop, the leverage the promotion promised you finally shows up.

Extend your knowledge

• ▹Camille Fournier, "The Manager's Path" — covers the disorientation of the jump from IC to first-time manager and losing the feedback loop that made you good at your old job.
• ▹Will Larson, "An Elegant Puzzle" — his writing on leverage in engineering organizations is a useful frame for building your own decisions-without-me tracking.
• ▹Charity Majors' writing on the engineer/manager pendulum and engineering management — a good starting point for thinking about feedback loops in team decision-making, not just in systems.
• ▹This week: pick one production-impacting decision you're tempted to make yourself, and instead write down the question you'd ask to help your report make it — then track what happens to the outcome.