The Engineering Manager (EM) is a software developer who was promoted into a role where the primary deliverable is no longer code but people — their growth, their happiness, their conflicts, their Performance Reviews, and their mysterious tendency to quit right after the big release.
The Engineering Manager is the most conflicted role in technology. Every other role has a clear output: developers ship code, designers ship designs, product managers ship roadmaps. The EM ships… team effectiveness? Morale? The absence of problems? The output is invisible, unmeasurable, and attributed to the team when it goes well and to the EM when it doesn’t.
The EM is a Manager of the “Former IC” subspecies by default — because every EM was, until recently, an IC, and the transition from “I write code” to “I facilitate the writing of code” is the identity equivalent of learning to cook by watching someone else use your kitchen.
The First Week
The Engineering Manager’s first week follows a script:
Monday: Receives access to the HR system. Discovers the salary of every direct report. Cannot unknow this. The person who writes the best code is paid less than the person who joined six months ago during a hiring market. The EM cannot mention this. The EM will think about this in every one-on-one for the next year.
Tuesday: First one-on-one as a manager. The direct report asks “so what changes?” The EM says “nothing changes.” Everything has changed. The EM is now the person who writes the Performance Review, approves the holiday, and decides the PIP. “Nothing changes” is the first managerial fiction. There will be more.
Wednesday: A production incident. The EM knows exactly how to fix it. The EM opens the IDE. Then closes it. Then opens it. Then closes it. The EM’s job is no longer to fix it. The EM’s job is to ensure someone else can fix it, which is slower, less satisfying, and more important. The EM watches. The EM does not enjoy watching.
Thursday: The skip-level meeting. The EM’s manager meets with the EM’s direct reports without the EM present. The EM spends the hour wondering what’s being said. What’s being said is: “things are fine.” This does not reduce the wondering.
Friday: The EM reviews a pull request. Old habit. The review is thorough, technically excellent, and entirely unwelcome — because the EM is no longer a peer reviewer, the EM is the boss, and a “suggestion” from the boss is an order wrapped in a question mark. The EM learns that code review, as a manager, is a power dynamic, not a collaboration. The EM stops reviewing pull requests. The EM misses reviewing pull requests.
The Calendar
The EM’s calendar is the material evidence of the career change:
IC CALENDAR EM CALENDAR
───────────────────── ─────────────────────
09:00 [focus time] 09:00 Standup
10:00 [focus time] 09:30 1:1 (Alice)
11:00 Standup (15 min) 10:00 1:1 (Bob)
11:15 [focus time] 10:30 1:1 (Charlie)
12:00 [lunch] 11:00 Hiring panel
13:00 [focus time] 11:30 Cross-team sync
14:00 [focus time] 12:00 Lunch (at desk, reading Slack)
15:00 PR review 12:30 1:1 (Diana)
15:30 [focus time] 13:00 Sprint planning
16:00 [focus time] 13:30 EM peer group
17:00 [done] 14:00 Skip-level with VP
14:30 Incident review
15:00 Hiring debrief
15:30 Performance calibration
16:00 1:1 (Eve)
16:30 "Focus time" (Slack + email)
17:00 [not done]
22:00 Reviews PR (at home, in secret)
The IC has six hours of focus time. The EM has zero. The EM’s “focus time” is a calendar block that other people schedule over, because the EM’s calendar is public and everyone’s need is urgent. The EM’s actual focus time is 10 PM, at home, when the house is quiet and the IDE is open and the EM remembers, briefly, what it felt like to be good at something they could see.
The Technical Credibility Half-Life
The EM’s technical credibility has a half-life of approximately eighteen months.
At month 0, the EM was the best developer on the team. The EM’s opinions on architecture carry weight because the EM built the architecture. At month 6, the EM’s opinions still carry weight, but the codebase has changed and the EM’s knowledge is increasingly historical. At month 12, the EM’s opinions carry the weight of seniority rather than currency — the team listens because the EM is the boss, not because the EM knows the current state of the code. At month 18, the EM’s technical opinions are a liability: correct enough to sound authoritative, outdated enough to be wrong, and delivered from a position of power that prevents the team from pushing back.
The best EMs recognise the half-life and deliberately step back from technical decisions. “What do you think?” becomes their most important sentence. The worst EMs do not recognise the half-life and continue making technical decisions based on the codebase they remember, which is no longer the codebase that exists. The team implements the EM’s decisions out of deference, not agreement, and the architecture accumulates the geological layers of a manager who can’t let go.
The Reward Problem
The EM’s reward structure is inverted relative to their previous role.
As an IC, the reward was immediate and tangible: write code, run tests, see green, deploy, watch users use the thing you built. The dopamine loop was tight. Ship something, feel good, ship something else.
As an EM, the reward is delayed and intangible: have a one-on-one in March, coach a direct report through a problem, watch them grow over six months, see them ship something in September that they couldn’t have shipped in March. The EM’s contribution to that shipment is real but invisible. The direct report is congratulated. The EM is not, because the EM’s job is to be invisible — the best manager is the one whose team says “we did it ourselves.”
This is beautiful in theory. In practice, it means the EM goes months without the feeling of having built something, which is the feeling that made them become an engineer in the first place. The midnight PR review is not a failure of management discipline. It is a person feeding a hunger that their job description no longer satisfies.
The Return Path
Some EMs go back to IC. The return is more common than the industry acknowledges and more difficult than it appears.
The difficulty is not technical — the EM can learn the new frameworks, catch up on the codebase, rebuild the muscle. The difficulty is status. The return from EM to IC is perceived as a demotion, because the Org Chart is a ladder and ladders go up. The EM who says “I want to go back to coding” hears: “Are you sure? It’s a step back.” It is not a step back. It is a step sideways, to a different ladder, the one the EM was climbing before someone offered them 25% more to climb a ladder they didn’t enjoy.
The companies that make the return path dignified — Staff Engineer at EM-level compensation, no stigma, no career penalty — retain their best technical minds. The companies that treat the return as failure lose their best EMs to companies that don’t.
Measured Characteristics
- EMs who were the best developer on the team before promotion: ~70%
- EMs who are still the best developer on the team (in their own estimation): ~70%
- EMs who are still the best developer on the team (in the team’s estimation): ~20% after 18 months
- Calendar hours in meetings: 6-8 of 8
- Calendar hours coding (official): 0
- Calendar hours coding (midnight, at home, in secret): 1-2
- PRs reviewed as manager that were welcomed: first few
- PRs reviewed as manager that were resented: the rest
- Months before the EM misses coding: 2-3
- Months before the EM stops admitting they miss coding: 6
- Technical credibility half-life: ~18 months
- EMs who have considered going back to IC: most
- EMs who went back: ~15%
- EMs who wish they had: more than 15%
