The Real Job of an Engineering Manager

The week I got promoted to manage the payments team, nobody told me my job had changed. My calendar changed, sure. But the mental model in my head was still the one that had gotten me the promotion: find the hard technical problem, solve it faster and cleaner than anyone else, ship. For about three months I kept doing exactly that, and my team quietly got worse.

They got worse because I was still trying to be the best engineer in the room instead of the person who made the room full of good engineers. That is the whole shift, and almost nobody explains it out loud. So here is my attempt to say the thing plainly.

The title that misleads you

Engineering manager sounds like a senior version of engineer. It is not. It is a different job that happens to require you to remember what engineering feels like. The skills that made you a strong individual contributor - deep focus, ownership of a problem end to end, the satisfaction of a clean diff - are mostly the wrong instincts now. Deep focus becomes a way to hide from your team. End-to-end ownership becomes a bottleneck. That clean diff you wrote at 11pm is a diff a junior didn't get to write.

I watched a brilliant staff engineer take a management role and burn out in eight months because he could not stop pulling tickets. He shipped a lot. His team shipped almost nothing on their own, because every interesting problem got vacuumed up before they could touch it. When he left, three of his four reports were still, functionally, at the level they'd joined at. He had spent a year being productive and zero years building anyone.

Your output is now their output

The single hardest adjustment is accepting that your personal contribution is no longer measured in what you produce. It is measured in what the team produces, and specifically in the gap between what they'd produce with you and without you. If your team would ship the same amount if you vanished for two weeks, you are either a very good manager who has built independence, or you are a passenger. The difference is whether the team gets better over time.

This is uncomfortable because the feedback loop stretches from hours to months. When I write code, I know within a day whether it worked. When I coach an engineer through their first incident command, or push back on a design that will paint us into a corner in six months, I might not see the payoff until next quarter. You have to learn to work without the dopamine of the merge button, and that is genuinely hard for people who became engineers partly for that hit.

The one-on-one is not a status meeting

If you use your weekly one-on-one to ask "what are you working on," you are wasting the single most valuable thirty minutes you have with each person. You already know what they're working on; that is what the board is for. The one-on-one is the only reliable place to hear the things that never make it into a standup: that someone is bored, that they think the roadmap is nonsense, that they're interviewing elsewhere, that they're quietly drowning on a task they're too proud to flag.

My rule is that it is their meeting, not mine. I come with maybe one thing, and if they have something, mine waits. I've had one-on-ones where an engineer spent twenty-five minutes on a problem that had nothing to do with code and everything to do with why they'd stopped caring. If I had steamrolled that with a sprint update, I'd have lost them within a quarter. The best signal I ever get about a team's health comes from these conversations, and it arrives weeks before it would ever show up in delivery metrics.

Protecting focus is a real deliverable

Engineers do their best work in long, uninterrupted stretches. Every meeting you accept on their behalf, every "quick question" you forward, every context switch you fail to absorb is a tax on the exact thing you were hired to produce. A big part of the job is being a shock absorber - taking the chaos coming from above and sideways and converting it into something the team can act on calmly, in batches, without panic.

The most useful sentence I say in any given week is "leave that with me." It means: I have heard the noise, I will figure out what actually needs to happen, and I will come back to you with one clear thing instead of five confused ones.

When a VP pings me at 4pm on a Friday about a customer escalation, my team should not feel that ping. My job is to catch it, work out whether it's a genuine fire or someone's anxiety, and only then decide whether it's worth interrupting anyone's weekend. In a regulated payments shop the escalations are real often enough that you can't dismiss them - but they are also panicky far more often than they are urgent, and telling the difference is exactly the value you add.

Hiring is the thing you can't undo cheaply

Most of what your team can do over the next two years is decided in interviews you're running this quarter. A bad hire on a five-person team isn't a twenty percent problem; it can be a net-negative person who consumes review time, morale, and your own attention while producing work that has to be redone. I have kept a mis-hire around six months too long because firing feels like a personal failure, and I can tell you the team knew before I did, and they resented me for the delay.

So I take hiring more seriously than almost anything else on my plate. That means writing the job spec myself rather than pasting a template, sitting in on debriefs to fight recency bias, and being honest that a lukewarm "yes" is a no. It also means the reverse: when I find someone genuinely good, I move fast and I fight for the offer, because the market for people who are both technically sharp and pleasant to work with is thin, and the good ones have options.

Feedback people can actually use

The most common management failure I see is not being too harsh. It is being too vague, too late, and too rare. "Great work this quarter" tells someone nothing they can repeat. "The way you wrote up the incident timeline so the support team could follow it without asking questions - do that every time" tells them exactly what to do more of. Specificity is respect. It says you were actually paying attention.

The harder half is corrective feedback, and the trick is to give it small and give it now. If you save up frustrations for the annual review, two things happen: the person is blindsided by problems they could have fixed months ago, and you've been quietly stewing the whole time, which corrodes the relationship. A few habits that have served me:

• Say the hard thing within a week of noticing it, while the example is still fresh and low-stakes.
• Separate the behavior from the person - "this PR was hard to review" not "you write unreviewable code."
• Never deliver real criticism over text; the tone gets lost and people spiral.
• Ask what they saw before you tell them what you saw. Half the time they already know.

The pull to stay technical

You should not go fully non-technical. If you can't read a design doc critically or smell when an estimate is fantasy, you'll lose the respect of your team and make bad calls on their behalf. But there's a difference between staying technical enough to have judgment and staying technical because coding is the comfortable thing you know how to be good at. The second one is a trap, and it's seductive precisely on the days management feels hard and thankless.

My compromise is that I stay on the critical path for nothing. I'll pick up a gnarly investigation nobody has time for, write a prototype to de-risk a decision, or pair with someone stuck. What I won't do is own a feature that's due next sprint, because the moment my managerial week explodes - and it will - that feature stalls and I've let the team down to protect my own ego.

Measuring the wrong things

Nothing rots a team faster than a manager who reaches for the metric that's easy to count instead of the one that matters. Lines of code, tickets closed, hours logged - these measure motion, not progress, and engineers see through them instantly. I once inherited a team that had been ranked on story points for a year. They had become world-class at inflating estimates and shipping features nobody used. The number went up every sprint and the product got worse.

What I actually watch is softer and harder to game: is the on-call rotation getting quieter or louder? Are people cleaning up messes without being asked? When something breaks at 2am, does the person who gets paged know what to do, or do they have to wake me? Those tell me whether the system - people plus code - is genuinely healthy. They don't fit in a dashboard for the board deck, which is a nuisance, but the dashboard version is usually a comforting fiction.

Conclusion

Here's the part I wish someone had told me in that first quarter: the job feels bad long before it feels good, and that is not a sign you're failing. It's a sign the feedback loop got longer. You've traded the daily satisfaction of solving problems yourself for the slower, stranger satisfaction of watching someone you coached solve a problem you couldn't have. If you can learn to want that second thing - genuinely want it, not just tolerate it - you'll be a good manager. If you can't, that's fine too, but do everyone a favor and go back to building. The world needs strong engineers a lot more than it needs reluctant managers.