Engineering Management: The Transition and the Job

Engineering Management

The hardest thing about becoming an engineering manager is that the job has almost nothing in common with the job you were good at. As an engineer, you had tight feedback loops, unambiguous success criteria, and output you could point at. As a manager, your feedback loop is measured in months, "good" is contested, and your output is entirely other people's work. Many strong engineers become mediocre managers not from lack of ability but because nobody told them it was a career change rather than a promotion.

The core of the job is straightforward to state: your output is the team's output. Everything follows from that. Time spent unblocking four people beats time spent coding. Hiring one strong engineer outweighs a quarter of your personal contribution. And the thing that feels least like work — a conversation about someone's career — is often the highest-leverage hour of your week.

The other thing worth saying plainly: it's a job you can leave. Trying management and returning to individual contribution is common, healthy, and carries no stigma at any company worth working for.

TL;DR

Your output is the team's output. Stop measuring yourself by what you personally produce.
The transition is a career change, not a promotion. Different skills, different feedback loops.
The first-year mistakes are predictable: not delegating, avoiding hard conversations, and still coding too much.
Hiring is your highest-leverage activity — one strong hire outlasts a year of your effort.
One-on-ones are the core instrument. Weekly, never cancelled, their agenda.
No surprises in performance reviews. If it's news, you failed earlier.
Measure the system (DORA), not individuals. Individual output metrics get gamed.
You can go back to IC. Try it as an experiment rather than a commitment.

The Transition

That last line causes more new-manager distress than anything else. You will finish weeks having written no code, shipped nothing, and made no visible artifact — and have been extremely valuable. Recalibrating what "a productive day" means takes about a year.

The first 90 days

The instruction to change nothing in month one is the one people ignore and later regret. A new manager who reorganizes in week two has changed something they didn't understand, and spent credibility they hadn't yet earned.

Core Concepts

What the job actually contains

Notice what isn't there: architecture, code review, technical decisions. Those belong to the tech lead or staff engineers. A manager who owns technical direction and people at anything beyond a very small team is doing two jobs and will do both badly.

Delegation

The delegation ladder — task, then problem, then ownership — applies here as it does for a tech lead, with one addition: as a manager you're also delegating decisions, and that's the harder one. Letting someone make a call you'd have made differently, and living with a worse outcome, is how you build people who can operate without you. The alternative is a team that escalates everything.

The test: what happens when you take two weeks off? If the answer is "everything waits," that's a diagnosis of your delegation, not of your team.

Difficult conversations

The single biggest differentiator between adequate and good managers is willingness to have the conversation early.

The structure is the same as any feedback: situation, behavior, impact, and then genuinely listen to their side. What makes it hard isn't the technique — it's that it's uncomfortable and easy to postpone by one more week, indefinitely.

Performance management, when it comes to that, needs to be documented, specific, time-bound, and — critically — not a surprise. Someone who is put on a formal plan without having heard clear concerns for months has been failed by their manager, whatever the underlying performance issue.

Measuring your own effectiveness

You can't measure yourself by output, so use these:

None of these is immediate, which is the fundamental discomfort of the role. You act now and find out in six months.

Protecting the team

A significant, invisible part of the job is absorbing organizational noise: reorganization anxiety, shifting priorities, stakeholder pressure, and the fourth request this week from another team. Most of it shouldn't reach the people building.

The counterweight is honesty. Filtering noise is your job; concealing genuinely relevant information is not. When something real is coming — a reorganization, a change in direction, budget pressure — people can tell something is happening, and discovering they were kept in the dark costs more trust than the bad news ever would.

Best Practices

Have the hard conversation this week

Whatever you've been putting off. It gets more expensive every week, and it's almost always less bad than you've imagined. Managers who consistently do this early are perceived as fair; managers who avoid it end up perceived as both weak and, eventually, arbitrary.

Hire deliberately and slowly

One strong hire compounds for years; one bad hire consumes your attention, damages team morale, and takes months to resolve. Structured, calibrated hiring is worth more of your time than almost anything else you'll do.

Protect focus time, including your own

An engineer with four hours of fragmented time and three meetings ships nothing. Consolidate meetings, defend no-meeting blocks, and be honest that your calendar is now the shock absorber that makes theirs possible.

Give context, not instructions

"We need to reduce checkout latency because it's costing us conversions, and finance has flagged it for the quarter" gets you better solutions than "add a cache." People who understand why can make good decisions you never had to be involved in.

Advocate visibly on compensation and promotion

Your reports cannot see the calibration meeting where you argued for them. Tell them what you're doing and what the constraints are. Silence looks like indifference, and someone who believes their manager isn't fighting for them will leave.

Write things down

Decisions, commitments, feedback given, growth goals. Six months later you'll need to write a review, defend a promotion case, or remember what you promised. Memory is not sufficient and the stakes are people's careers.

Keep a small amount of technical context

Not coding on the critical path — but reading code, attending design reviews, and understanding the architecture well enough to ask good questions and to advocate credibly for technical investment. A manager with no technical context can't tell whether a two-week estimate is reasonable and can't defend technical debt work to a skeptical stakeholder.

Ask for feedback and act on it visibly

"What should I start or stop doing?" every one-on-one, and then change something noticeable. A team that has never seen their manager change in response to feedback stops offering any.

Common Mistakes

Still doing the IC job

Avoiding conflict

Managing by metrics on individuals

Being everyone's friend

Surprising people at review time

Not building a successor

FAQ

Should I become a manager?

Only if the work appeals — the conversations, the ambiguity, the long feedback loops, the fact that your best day may involve no visible output. Do it because you want to build teams and grow people, not because it's the next rung or because it pays more. The staff-plus IC track carries comparable scope and influence at most serious companies, and many people are far happier and more effective on it.

Can I go back to being an IC?

Yes, and it's common. Try management as an experiment with an explicit review point — six months, a year — rather than as a one-way door. Companies with functioning career frameworks treat the move back as a lateral change, not a demotion. If yours treats it as failure, that tells you something useful about the company.

How much should I still code?

Very little, and not on the critical path. Reading code, reviewing occasionally, and doing small non-blocking work keeps enough context to be credible and to ask useful questions. Taking a real feature means the team waits on you while you're in meetings, and it means you're not doing the management work. The technical judgment matters; the technical output doesn't.

How many direct reports is reasonable?

Five to eight is the usual range for a hands-on manager. Below four, you probably have capacity for a technical scope as well. Above ten, the one-on-ones alone consume a day a week and you have no capacity for the rest of the job — that's a structural problem, not a time-management one. See Team Topologies.

What do I do when my best engineer resigns?

Understand why before responding, and assume the stated reason is incomplete — compensation is often the surface answer for growth, autonomy, or a manager problem. A counteroffer that changes only money usually delays the departure by a few months. The more important question is what you missed: retention problems are typically visible for a quarter before anyone resigns, if the one-on-ones are the kind where people say true things.

How do I manage people more technically skilled than me?

Normally, and this is the standard case rather than the exception at any level above the first. You're not there to out-engineer them; you're there to set context, remove obstacles, give honest feedback about impact and collaboration, and advocate for them. Be honest about the limits of your technical judgment and rely on your tech lead and senior engineers for technical direction. Pretending to a depth you don't have is the failure mode; asking good questions is the skill.