What Does an Engineering Manager Actually Do? Plain Definition
The most common myth in our industry: an Engineering Manager is a senior developer who got admin rights in GitHub and the authority to approve pull requests on Fridays. Two reasons that's wrong. First, the median EM on the 100+ B2B teams we measure writes code for roughly 18 minutes per day, and that's the healthy number. Second, the highest-leverage thing an EM does has nothing to do with the IDE. It's the conversation that prevents a senior from quitting. The spec rewrite that saves a quarter. The hiring loop that finds an engineer one level above what the team thought it could afford. Will Larson, who built engineering at Stripe, Calm, and Carta, puts it bluntly in An Elegant Puzzle: an EM's job is to make the team output more than the sum of its parts. You cannot do that with your hands on a keyboard.
This is a plain-language definition. Who an EM is, what they do during a week, how the role differs from Tech Lead, the path from senior engineer, and how to measure whether one is doing the job well.
{/* truncate */}
Engineering Manager: the one-sentence definition
An Engineering Manager is the person accountable for the performance, growth, and delivery of a software engineering team — primarily through people, not code.
Three words in that sentence carry the weight. Accountable, not "involved." If the team misses the quarter, the EM owns it. Team, not a project or codebase. An EM manages people who happen to build software, not the software itself. People, the medium through which work happens. Leverage lives in conversations, decisions about who does what, and the design of how work flows. Not in commits.
Camille Fournier's The Manager's Path (2017) frames the transition this way: as an IC you debug code, as an EM you debug systems of people. The skills don't transfer one-to-one. That's why senior engineers pushed into management without prep tend to either revert to coding or burn out trying to do both.
Engineering Manager vs Tech Lead — the split
These two roles are confused constantly. They're parallel tracks, not steps on a ladder. Here's how they split on the four dimensions that actually matter:
| Dimension | Tech Lead | Engineering Manager |
|---|---|---|
| Coding share of week | 40-60% | 0-10% |
| Ownership focus | Codebase, architecture, technical direction | People, delivery, team health |
| People management duties | Mentorship only — no perf, no hiring sign-off | Full — perf reviews, comp, hiring, firing |
| Strategic horizon | This quarter's architecture, next year's tech bets | Headcount plan, growth ladders, team structure |
A Tech Lead forced to also run performance reviews ends up either skipping the people work or skipping the code work. We covered the split in detail in Tech Lead vs Engineering Manager vs Engineering Lead. The takeaway in one line: combining the two roles into one title is the most common and most expensive leadership mistake at the 8-15 engineer scale.
What an EM actually does in a week
A 40-hour week for a mid-sized-team EM (6-8 reports) looks roughly like the chart below.
Where 38 of an EM's 40 hours go. The remaining ~2 hours are absorbed by Slack triage and the things that don't fit on a calendar.
| Activity | Hours/week | What it actually means |
|---|---|---|
| 1:1s with reports | 6-8h | 45-60 min per report, weekly. Career, blockers, signal-gathering |
| Cross-team meetings | 5-7h | PM, design, other EMs, dependencies, planning |
| Hiring + interviews | 4-6h | Pipeline review, panel interviews, debrief, write-ups |
| Planning & roadmap | 4-6h | Sprint shaping, quarterly bets, scope negotiation with PM |
| Unblocking + escalations | 3-5h | Anything where the EM's authority moves something the team couldn't |
| Code, reviews, docs | 2-4h | Small fixes, PR review for context, an RFC comment, occasional prototype |
| Growth + perf | 3-5h | Promotion packets, performance feedback, comp conversations |
| Skip-level, org work | 1-3h | Manager's manager, cross-org initiatives, hiring panels for other teams |
Notice what's missing: meaningful coding. Most EMs who try to stay in the codebase end up on the critical path for a feature, go heads-down, the team stops getting unblocked, the next sprint slips. The honest tradeoff: be an IC contributor or be a manager. Trying both at scale is what burns people out.
How to become an EM from senior engineer
There's no single path, but there are reliable signals of readiness, and reliable failure modes for the first 12 months.
Signals you're ready
- People come to you with non-code problems. Career questions, conflict, "is this normal?" If juniors already use you as an informal mentor, the formal version is a small step.
- You make others productive. Your PRs are useful, but your unblocking is more useful. The team notices when you're out.
- You stop wanting to write every PR yourself. You're starting to enjoy designing the work more than doing it. This is the most reliable signal because it's the hardest to fake.
- You can write clearly and quickly without rage-quitting Google Docs. Most EM work is written communication. If you hate writing, the job will be miserable.
Typical first-year mistakes
| Mistake | Why it happens | What it costs |
|---|---|---|
| Coding 30+% of the week | "I'm still the strongest engineer here" | Team un-blocks slower, EM becomes a single point of failure |
| Avoiding hard conversations | Engineering culture rewards technical disagreement, not personal feedback | Performance issues fester for 2-3 quarters before getting addressed |
| Trying to be everyone's friend | Promoted-from-within EMs over-correct on relationship preservation | Lose authority when a real decision needs to be made |
| Treating 1:1s as status meetings | Defaulting to the most familiar pattern (standup) | 1:1s become useless, real signals never surface |
| Optimizing only for delivery | Easiest to measure, looks good to leadership | Team retention craters by Q3, all the "wins" evaporate |
The most underrated first-year skill: learning to be bored productively. New EMs often feel useless because nothing they did all day produced an artifact. The artifact is the team's output next quarter. If that idea makes you anxious, the role will be hard.
For a structured framework on running better 1:1s with data instead of vibes, see Data-Driven One-on-Ones.
How to measure an EM
Honest limit first: there's no DORA for engineering management. DORA gives you four numbers any team can argue about productively. "Is my EM good?" doesn't reduce to four numbers. It depends heavily on team stage, company maturity, and what the EM was hired to fix.
That said, the dimensions worth tracking are stable across contexts:
| Dimension | What to measure | Healthy range / signal |
|---|---|---|
| Team delivery health | Cycle time stability (std dev / mean over 8 weeks), commitment vs delivered ratio | std dev < 0.5× mean; commitment-delivery within ±15% |
| Retention | Voluntary attrition over 12 months, regretted-departure rate | < 10% voluntary; < 3% regretted |
| Growth | Promotion velocity, IC level distribution change year-over-year | At least 1 promotion / 4 reports / year |
| Hiring | Time-to-hire, offer-acceptance rate, 90-day pass rate | < 60 days; > 75% accept; > 90% pass |
| Engagement | eNPS or pulse, cross-checked with behavior | Survey ≥ 30 AND no after-hours spike pattern |
| Cross-team coordination | Skip-level + peer-EM feedback, dependency hit-rate | Stable peer ratings, < 1 missed dependency / month |
The contrarian claim hiding in this table: the best EM is often a noticeably worse coder than her best senior IC. That's not a bug. Time spent in the IDE is time not spent unblocking, hiring, or having the conversation that keeps someone from quitting. If your EM is shipping more lines of code than half her reports, she's under-investing in the parts of the job that only she can do.
The same logic applies upward. See VP Engineering's First 90 Days for what this looks like at the org level, and The Staff Engineer Framework for the parallel IC track if leadership is not the goal.
Where PanDev Metrics fits in
EMs we work with use our team-level views to do one specific thing: separate what they think is happening from what's actually happening. Focus time vs meeting time per direct report, after-hours patterns by individual, cross-project allocation when someone is "split" between three things. All measured passively from IDE heartbeat, Git, and tracker data. The point isn't surveillance. The point is making 1:1s about the actual work shape of the week instead of a self-report already distorted by what the engineer thinks the manager wants to hear. One workflow rule unlocks it: branches named with task IDs (feature/PDM-3475).
FAQ
Is an Engineering Manager a manager or an engineer?
A manager who used to be an engineer. The engineering background is necessary for credibility and good technical judgment, but the day job is management. If "manager" is uncomfortable, the role might not be the right fit. There's no shame in staying IC. The Staff Engineer track exists exactly for this.
How much does an Engineering Manager code?
Median: ~18 minutes per day, usually prototype code or to unblock a critical bug. Range: 0-10% of the week. EMs who code more than 20% of the week usually have either a team-of-2 (where the math forces it) or a delivery problem they're trying to fix with their own hands instead of leadership.
Engineering Manager vs Tech Lead, what's the actual difference?
Tech Lead = senior IC with architectural ownership, still codes 40-60% of the week, no people management authority. Engineering Manager = people leader with delivery accountability, codes 0-10%, owns hiring, perf, comp. Parallel tracks, not sequential. Full breakdown in Tech Lead vs Engineering Manager.
What skills does an Engineering Manager need?
Roughly in this order of leverage: (1) written communication, (2) structured 1:1s and feedback, (3) hiring judgment, (4) scope and priority negotiation with PM and design, (5) technical judgment good enough to call BS on bad estimates, (6) calmness in incident response. Coding skill matters far less than people-skill.
When does a team need an Engineering Manager?
Rough rule: when one person is responsible for 5+ engineers and starts spending more than 50% of their week not coding. Below 5 engineers, a Tech Lead model usually works. Above 8, the team almost always needs a dedicated EM.
How many reports does an Engineering Manager have?
Healthy range: 5-8 direct reports. Below 4, the EM has too much time and tends to over-manage. Above 8, 1:1 cadence collapses. Do the math: 8 reports × 1h/week = a full day already gone. Above 10, you need either skip-level EMs or a smaller team. The 10 metrics every EM should track piece has more on team-size signals. For promotion mechanics into this role, see Junior-to-Senior Promotion.
The honest summary
An Engineering Manager is not a senior engineer with admin rights. The role is a different job. Leverage moves from your IDE to the team's calendar, and the artifacts are people who are productive, growing, and not leaving. The path from senior engineer is real but bumpy, and the first year usually involves either coding too much or hiding from hard conversations. The skill is learnable. The EMs we see do it best are the ones who admitted early that they wouldn't be the best coder on the team anymore, and treated that as the point of the job, not a loss of identity.