Engineering Management
The engineering manager's actual job: people, delivery and technical judgement. Covers one-on-ones, feedback, delegation, team design, staying technical, and the failure modes that turn managers into bottlenecks.
Engineering management is the job of making a team of engineers produce good outcomes reliably. That means owning three things simultaneously: the people, the delivery, and enough technical judgement to connect the two. It is a distinct discipline from senior engineering rather than a promotion from it, and treating it as a reward for technical excellence is one of the most reliable ways to lose a strong engineer and gain a struggling manager.
What an Engineering Manager Does
The clearest way to describe the role is by what breaks when nobody performs it. The responsibilities are easier to see in their absence than in a job description.
When nobody owns people, good engineers leave quietly and the exit interview is the first anyone hears of the reason. Weak performance persists unaddressed until it becomes an emergency. Nobody knows what anyone wants to be doing in two years, so growth happens by accident or not at all.
When nobody owns delivery, work starts without finishing, cross-team dependencies surface at the point they block, and commitments get made by whoever last spoke to a stakeholder. The team is busy and the outcome is unpredictable.
When nobody owns technical judgement, the team accumulates decisions that nobody can explain, and the manager cannot distinguish an honest estimate from an evasive one. This is the responsibility most often quietly dropped, because it is the one where a non-technical manager can appear to function for a surprisingly long time.
The Three Surfaces
The work also has three directions. Downward is the team: hiring, growth, feedback, the day-to-day. Outward is peers and stakeholders: other engineering teams, product, design, support, whoever depends on your team or blocks it. Upward is your own management chain: making your team's constraints and results legible to people who allocate resources.
New managers reliably over-invest downward and under-invest outward, because downward work feels like the job and outward work feels like politics. It is not. The outward surface is where the team's work gets prioritised, protected, staffed and unblocked. A team with an excellent internal culture and no external advocacy gets handed the work nobody else wanted.
Core Practices
One-on-Ones
A recurring one-on-one is the mechanism by which you learn things before they become problems. It belongs to the report, not to you, and it is not a status update — status has cheaper channels. Its content is obstacles, feedback in both directions, career direction, and the things people will not raise in front of a group.
Cancelling one-on-ones is the loudest signal available to a manager, and what it signals is that the person is lower priority than whatever displaced them. Keep a shared running document so the conversation has continuity and so commitments made in it are visible rather than remembered.
Feedback and Performance
Feedback that first arrives at a review cycle is a management failure, not an employee failure. Useful feedback is specific, describes behaviour rather than character, and arrives close enough to the event that the person can still remember the context.
Before treating anything as a performance problem, diagnose which of three things it actually is. A skill gap is teachable and responds to training, pairing or a change in assignment. A motivation gap is a conversation about fit, context or circumstances outside work. A systems problem is a person behaving rationally in response to bad incentives, unclear ownership or an impossible constraint. Misdiagnosing a systems problem as an individual performance problem is the most common and most damaging error in this area, because it burns trust while leaving the actual cause untouched.
When underperformance is real, say it plainly and early, write down what resolution looks like and by when, and follow your organisation's formal process — involving your HR function at the start rather than after several months of hinting. The kindest version of this conversation is the clearest one; ambiguity extends the discomfort without improving the outcome.
Delegation and Scope
Delegate outcomes rather than tasks. Specify the constraint, the decision boundary and the check-in point, and leave the method to the person doing the work. Delegation that also specifies the method is slower doing, and delegation without context is abandonment — the person makes locally reasonable choices that turn out to be globally wrong because they never had the information needed to see the conflict.
The hardest part is tolerating a method you would not have chosen producing an acceptable result. A manager who intervenes whenever the approach differs from their own has not delegated; they have added a review queue.
Team Design
Team boundaries determine communication cost, and communication cost determines speed far more than individual talent does. A team that must coordinate with four other teams to ship a routine change will be slow regardless of how good its engineers are. Conway's observation — that systems tend to mirror the communication structures of the organisations that build them — cuts both ways: team structure is a design decision about the architecture, whether or not anyone treats it as one.
The useful vocabulary here comes from Team Topologies by Matthew Skelton and Manuel Pais, which distinguishes teams aligned to a stream of work from platform teams, enabling teams, and teams owning a complicated subsystem. The value of the distinction is that these team types have genuinely different success criteria, and evaluating a platform team on feature throughput or an enabling team on permanent ownership produces bad decisions.
On size: a team should be small enough that everyone can hold the shared context, and large enough to absorb an absence and sustain an on-call rotation without burning people out. On ownership: durability matters more than optimality. A team that owns a system through operation learns things about it that a project team, disbanded at launch, never discovers.
Staying Technical Without Taking the Keyboard
You need enough technical depth to evaluate a plan, ask the question that surfaces the real risk, and be difficult to mislead. You do not need to be the strongest engineer in the room, and trying to remain so is the fastest route to becoming a bottleneck.
The practices that preserve depth without consuming the role are indirect: read the code and the pull requests without commenting on style, participate in design reviews as a questioner rather than a decider, attend incident reviews, and take small pieces of work that are genuinely off the critical path. The rule that matters is not how much you code but what you code — never assign yourself the thing the release depends on, because your calendar will eventually collide with it and the team will pay.
Common Failure Modes
| Failure mode | What it looks like in practice | What to do instead |
|---|---|---|
| Manager as chief engineer | Every technical decision queues on one person's availability | Delegate decisions with stated constraints, not just tasks |
| Status-report one-on-ones | Resignations arrive as a complete surprise | Make it their agenda; ask what is frustrating before asking what is finished |
| Shielding the team from all context | The team makes locally sensible, globally wrong calls | Share the constraint and the reasoning, not only the conclusion |
| Promotion as the only growth path | You lose a strong engineer and acquire a reluctant manager | Maintain a real individual-contributor ladder with comparable reward |
| Avoiding the hard conversation | A small problem compounds for months and the team notices long before you act | Say it early, specifically, and in writing |
| Managing by dashboard | The charts look healthy and delivery does not improve | Use metrics to start conversations, never to conclude them |
| Hero dependence | One person holds the on-call pager and most of the system knowledge | Rotate deliberately, document as you go, treat concentration of knowledge as a tracked risk |
When the Role Is the Wrong Answer
Adding a manager is not always the right response to a struggling team, and sometimes it makes things worse in ways that are hard to reverse.
- The team is very small. A group of three with a clear owner and a clear priority often needs a technical lead and an occasional decision, not a dedicated management layer. Adding one converts an engineer into coordination overhead.
- The real problem is upstream. If priorities arrive contradictory or change weekly, a new manager absorbs the pain rather than fixing the cause, and the organisation stops noticing the cause because someone is quietly compensating for it.
- There is no individual-contributor ladder. If management is the only route to seniority and pay, the role fills with people who took it for the compensation rather than the work, which is bad for them and worse for their reports.
- The move has no exit. Someone trying management should have an explicit, non-punitive path back to engineering. Without one, a person who discovers they dislike the job stays in it, and everyone they manage pays for that.
Key Takeaways
- The job is people, delivery and technical judgement together — dropping any one of the three is visible within a quarter.
- Outward-facing work is not politics; it is how a team gets the right work and the resources to do it.
- Diagnose skill, motivation and systems separately before calling anything a performance problem.
- Delegate outcomes with constraints. Specifying the method is not delegation, and omitting the context is abandonment.
- Team boundaries are an architectural decision, because communication cost dominates individual speed.
- Stay technical enough to be hard to mislead, and stay off the critical path.
- Management should be a reversible move, and it should not be the only way to grow.