Engineering Management
Your output becomes the team's output: people, priorities, and the system they work in.
Engineering management is accountability for a team's output, health and direction rather than for your own commits. Your time goes to people, priorities and the conditions the team works in: hiring, growth, delivery, and the trade-offs between them. The craft is still engineering judgement, but applied through other people.
What this path actually involves
Regular 1:1s, feedback, performance and career conversations, hiring and onboarding. Turning vague company goals into work a team can actually deliver, and protecting the team enough that it can. Removing dependencies and organisational friction, negotiating scope with product and other teams, and being the person who answers for it when delivery slips. At Director or Head of Engineering level the same work happens through other managers and across several teams at once.
What it does not mean
It is not a promotion above engineering, and it is not evidence that you are more senior than the people you manage. A Staff or Principal engineer can operate at the same scope or a larger one. It is also not simply the person who codes least: the issue is not how much you code but that your technical judgement now has to travel through other people, which is a different skill from having good judgement yourself. And it is not administration. Approving holidays and filling in forms is the smallest and least interesting part of the job.
Typical responsibilities
- Owning team delivery: commitments, sequencing, and the honest conversation when a date will not hold.
- 1:1s, feedback and performance: naming problems early rather than letting them accumulate into a surprise.
- Growing people: development plans, stretch scope, promotion cases, and sometimes managing someone out.
- Hiring and team composition: interviewing, calibrating the bar, onboarding, and deciding what shape the team needs next.
- Translating between the organisation and the team in both directions, including the parts of the strategy you disagree with.
- Keeping the team's technical health on the agenda when nobody is asking for it: reducing accumulated risk and keeping architecture ownership in your engineers' hands.
Skills that matter
What changes from a strong senior engineer role
A strong senior engineer is rewarded for personally solving hard problems; a manager is rewarded for a team that solves them without them. Your feedback loop becomes much slower and noisier: you may wait a quarter to learn whether a decision was right, and you rarely know which of your actions helped. Your calendar stops being yours, and the long uninterrupted focus that made you good at engineering becomes something you have to defend deliberately.
Signs you may enjoy it
- You get real satisfaction when someone you coached handles something you would previously have handled yourself.
- You find yourself thinking about how the team works, not only about the problem in front of you.
- Difficult conversations feel worth having rather than something to defer.
- A day of conversations with people leaves you energised rather than drained.
- You would rather improve the conditions the work happens in than write the code yourself.
Signs you may dislike it
- You reach the end of the week unable to point at anything you made.
- You keep pulling technical tickets to feel useful, and the management work slips.
- Repeated interpersonal conflict leaves you resentful rather than curious.
- You resent the meetings, not because there are too many, but because you would rather be building.
- You do technical work quietly in the evenings to feel like yourself again.
Common misconceptions
- That it is the next level after senior, rather than a different job with its own ladder.
- That good engineers naturally become good managers, or that weak ones become weak managers.
- That you have to stop being technical. What you stop is being the one who personally does it.
- That moving back to an IC role means you failed. Moving back is common and often a deliberate choice.
Where it typically leads
From engineering manager the path usually widens rather than deepens: managing managers as a Director or Head of Engineering, then VP or CTO scope where the work is organisational design, budget and strategy. Sideways moves into product engineering leadership, or back to Staff and Principal IC roles, are both normal and neither is a demotion.
How AI is changing this role
Where teams lean on agentic tooling, code and pull requests tend to arrive faster than they can be reviewed, so the bottleneck moves from writing to reviewing, verifying and deciding. As a manager you now have to care about how your team gets context to the model, which conventions, tests and documentation exist, because that has become the new equivalent of onboarding. It also compresses the kind of work juniors used to learn judgement from, so you have to be deliberate about where that learning now happens. And you will be asked more often whether an increase in output is real, which means measuring outcomes rather than commits.
Experiments to run before deciding
Borrow the job for a quarter
8-12 weeks
- Ask your manager to give you one engineer to mentor formally, with a written development goal.
- Hold recurring, prepared 1:1s with that person at least fortnightly.
- Delegate a meaningful area you currently own, and do not take it back when it is done differently to how you would have done it.
- Take full ownership of one unpleasant coordination problem: a cross-team dependency, or a commitment that is already late.
- Give one piece of difficult feedback directly instead of routing it through your manager.
- At the end, ask your manager for explicit feedback on how you handled all of it.
Then ask yourself
Did you enjoy succeeding through someone else's growth as much as solving the problem yourself, including the version where they solved it worse than you would have?
Own delivery for something you cannot do alone
10-12 weeks
- Take responsibility for one deliverable that needs at least three people and one other team.
- Write down the outcome, the constraints and what done means, then let others choose the implementation.
- Send a weekly update that you write yourself, including the bad news, to the stakeholders.
- When it slips, tell people before they ask.
- At the end, note what share of your time went to coordination and what share went to building.
Then ask yourself
When it went well, was it satisfying that the team did it, or frustrating that you did not?
Sit in the uncomfortable seat
8 weeks
- Ask to join your manager in hiring: run interviews, write honest debriefs, and argue for a decision. If nobody is hiring, take the internal equivalent instead: run the calibration or promotion discussion for someone in your team, write the case, and defend it in the room.
- Take part in one planning cycle where scope is cut, and take a position rather than observing.
- Ask an experienced engineering manager what their week actually went on, then compare it with the parts of your own week you liked.
- Write down every conversation you avoided over those eight weeks.
Then ask yourself
Did you avoid those conversations because you were busy, or because you would rather not have them at all?
Worth reading
The Manager's Path - Camille Fournier
The most practical map of the transition from engineer to manager to manager of managers; better read before you take the job than after.
An Elegant Puzzle - Will Larson
How engineering organisations actually behave: team sizing, systems thinking, and the trade-offs behind decisions you will be asked to make.
Team Topologies
Gives you language for team boundaries and cognitive load, which is most of what a Director spends their time on.
Accelerate - Forsgren, Humble, Kim
Evidence for what actually correlates with delivery performance, so your improvement arguments rest on more than instinct.
Not sure whether this path is closest to you?
Take the Career CompassHelp improve this page
If you have worked in this role and something here is inaccurate, incomplete or out of date, tell me. Suggestions are reviewed before anything changes.