Engineering managers
An engineering manager is accountable for how a team works rather than for what its code looks like. The remit covers the people — hiring, growth, performance, progression — and the conditions around them: team composition, process, coordination with other functions, and whether the group can be relied on to deliver. It is a genuinely different profession from engineering, and this guide explains what it involves and how to assess it.
What does an engineering manager do?
An engineering manager is accountable for the functioning of an engineering team: who is in it, how they develop, how they perform, how they work together, and whether the team delivers dependably. The remit typically includes hiring, one-to-ones, feedback and performance conversations, career development and promotion cases, team composition and ownership boundaries, process design, coordination with product, design and other functions, and reporting on delivery to the wider organisation. Technical decisions about the software itself usually sit with a tech lead or the engineers themselves; the manager is responsible for the conditions under which those decisions get made well.
The transition into the role is a change of profession, not a promotion within one. The satisfaction of finishing something yourself is replaced by influence exercised at a remove, on a delay, through other people. Results arrive months later and are hard to attribute. Managers who have not made this shift internally keep reaching for the work they know how to finish, and the visible symptom is a manager who codes on the critical path while the feedback conversation nobody wants to have is postponed for another quarter.
Most of the job is done before anything goes wrong. A team that is well composed, whose ownership is clear, whose expectations are explicit and whose members are individually supported produces very few crises. That makes the work quietly difficult to evaluate, because the strongest managers appear to be dealing with less than their struggling peers, and the temptation to measure the role by visible activity is the reason so many organisations promote the wrong people into it.
The remit is broader than delivery and narrower than everything. An engineering manager is not the team’s chief architect and should not overrule its technical decisions by virtue of seniority; that habit removes ownership from the engineers and steadily deskills the team. Equally, a manager who declines all engagement with technical substance cannot judge risk, cannot sponsor a promotion credibly and cannot represent the team’s constraints to anyone outside it. The working position is technically literate and technically restrained.
When organisations need this capability
Engineering management is often absorbed by a senior engineer or a founder for as long as it can be. These are the signs that the arrangement has stopped working.
Someone is doing people work in the gaps between other duties
One-to-ones are cancelled when delivery is tight, feedback happens only during an incident, and progression is discussed once a year because that is when the form is due. The people work is being done at whatever quality the leftover time allows.
Good engineers are leaving and the reasons are not being learned
Resignations are attributed to money or opportunity because nobody asked earlier or well enough. Departures are usually preceded by months of retrievable signals, and noticing those signals is a practice rather than an instinct.
Progression has stalled and nobody owns it
Engineers cannot describe what would move them to the next level, promotion cases are argued from advocacy rather than evidence, and the strongest people conclude that growth requires an external move. That conclusion becomes self-fulfilling quickly.
Delivery is unpredictable for organisational reasons
Commitments slip because of unclear ownership, unmanaged dependencies, constant interruption and competing demands rather than because the engineering was hard. These causes sit outside any individual engineer’s control and outside a purely technical remit.
Coordination is happening informally or not at all
Product, design, data and commercial functions each hold part of the picture, and the team discovers the missing parts during implementation. Somebody has to be accountable for the seams between functions, which is separate from being accountable for the code.
A team is about to grow substantially
Adding people to a group whose norms were never made explicit dilutes them. Hiring at pace, onboarding well and keeping the culture intelligible during expansion is specific work, and it is much cheaper to do deliberately than to repair afterwards.
Core capabilities
One-to-ones that surface problems early
A regular conversation the other person shapes, held often enough that difficulties appear while they are still small. Managers whose one-to-ones are status reports learn about problems at the same time as everyone else, which removes the main advantage of holding them.
Feedback and performance conversations
Saying the difficult thing early, specifically and without ambiguity. Sustained underperformance handled late is the single most common management failure, and its cost is borne by the colleagues covering for it long before it is borne by the individual.
Career development
Understanding where each person wants to get to, being honest about the distance, and arranging work that closes it. Development happens through assignments far more than through courses, which makes it a scheduling and negotiation problem as much as a coaching one.
Hiring
Defining what a role actually requires, designing an interview process that tests it, calibrating those involved so assessments are comparable, and deciding. Interview processes assembled by habit tend to measure comfort and familiarity rather than the ability to do the job.
Team composition
Shaping the mix of skills, seniority and ownership so the team is neither top-heavy nor stretched thin, and so no single person is the only route to a critical system. Composition decisions have longer consequences than almost anything else a manager does.
Delivery accountability
Forecasting honestly, communicating slippage as soon as it is known rather than when it is unavoidable, and protecting the difference between a commitment and an aspiration. Credibility here is built by early bad news and destroyed by late reassurance.
Process design and removal
Introducing the minimum ceremony that solves an identified problem, and removing what has outlived its purpose. Process accumulates by default because each addition was individually justified, and nobody is assigned to notice the total weight.
Cross-functional coordination
Holding the working relationships with product, design, data, operations and commercial functions, negotiating priorities and surfacing dependencies before they bite. Much of the friction attributed to engineering originates at these boundaries.
Reading team health
Interpreting the indicators that precede trouble — sustained overtime, silence in reviews, on-call fatigue, the same person always volunteering — and acting while intervention is still cheap.
Representing the team upwards
Explaining constraints, trade-offs and risks to people without engineering context, and returning with decisions and reasoning rather than instructions. A manager who absorbs pressure without transmitting information leaves the team confused about why anything changed.
How the discipline is practised
This role is not defined by a technology stack, so what follows describes method instead. The practices and artefacts below are those in general use across the industry — an account of how the discipline works, not a claim about how any particular manager works. They are also easy to adopt superficially, which is why the substance behind them is what deserves examination.
People practice
- Regular one-to-ones
- Growth and development plans
- Levelling and competency frameworks
- Performance and promotion cycles
- Structured feedback conventions
Hiring practice
- Role scorecards
- Interview loop design
- Interviewer calibration
- Structured debriefs
- Onboarding plans
Delivery management
- Roadmap and commitment planning
- Dependency mapping
- Risk registers
- Capacity and allocation planning
- Stakeholder reporting
Team operating rhythm
- Planning cadence
- Retrospectives
- Working agreements
- Ownership and escalation paths
- Interruption and on-call rotation policy
Health indicators
- Engagement and pulse surveys
- Retention and attrition review
- On-call load review
- Delivery flow measures
- Post-incident follow-through
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Management candidates present well, because the job is partly the ability to present well. The evidence that separates them is specific and retrospective: named people who grew, difficult conversations that happened on time, and decisions about team shape that the candidate can still justify.
Whether the transition actually happened
Ask what they miss about engineering and how they handle the pull back towards it. Candidates who describe management as engineering with meetings attached tend to keep the interesting work and the critical path for themselves.
- Talks about the team’s achievements before their own contribution
- Has a considered position on how much they should still build
- Can describe resisting the urge to take over a struggling piece of work
Handling underperformance
This is the work most avoided and the most revealing. Ask for a specific case, including how long it took them to raise it, what changed and how it ended.
- Raised the concern early and in plain terms
- Distinguishes a capability problem from a fit or context problem
- Has both a case that recovered and a case that did not
Growing people, specifically
Ask about individuals they developed and what they did that made the difference. Vague enthusiasm for growth is universal; a concrete account of a stretch assignment, a promotion case built over months or an honest conversation about a gap is not.
- Names the assignments used to close specific gaps
- Has told someone they were not ready and stayed constructive
- Can describe someone who outgrew the team and left with their support
Delivery without theatre
Ask how they handled a commitment that was going to be missed. The distinguishing behaviour is early, specific communication with options attached, rather than optimism maintained until the deadline made the truth unavoidable.
- Communicated slippage as soon as the evidence supported it
- Separates estimate from commitment when talking to stakeholders
- Can explain why a team was late without blaming the team
Hiring judgement
Ask how they designed an interview process and what they changed after seeing how the hires performed. Managers who have never revised a process have either hired very little or not tracked the outcome.
- Adjusted the process based on how hires actually worked out
- Can describe a hire that did not work and what the process missed
- Aims for comparability across interviewers rather than consensus enthusiasm
Restraint on technical decisions
Ask what they do when they disagree with a technical decision their team has made. Managers who overrule on seniority remove ownership; managers who never engage cannot assess risk. The wanted answer occupies the middle.
- Challenges by asking rather than by deciding
- Can describe accepting a decision they disagreed with, and why
- Works with a technical leader without competing for the same ground
Noticing before it breaks
Ask what tells them a team is in trouble before any metric moves. The answer reveals how closely they observe and whether their picture of the team comes from the team or from a dashboard.
- Cites behavioural signals rather than only delivery numbers
- Has intervened on a quiet problem and can say how it surfaced
- Treats sustained overtime as a defect in the system, not commitment
Interview questions worth asking
Provided as input to the interview process you run yourself. They are aimed at behaviour that has actually occurred, since management ability is poorly predicted by hypothetical reasoning.
Tell me about someone on your team who was not performing. How long was it between you noticing and you saying something?
What a strong answer shows
Willingness to act on discomfort. The interval is the signal, and a candidate who cannot recall any such case has either not managed for long or has been avoiding the situation rather than encountering none.
Describe a promotion case you built. What evidence did you gather, and what happened?
What a strong answer shows
Whether progression is managed as a fair, evidenced process or as advocacy for favourites. Look for evidence collected over time, an understanding of the bar, and awareness of who else was in contention.
Your team is going to miss a date the business has already communicated. Walk me through the next few days.
What a strong answer shows
How they handle bad news travelling upwards. Strong answers move quickly to a specific message with options and consequences, and never involve hoping the position recovers before anyone asks.
What process did you remove, and what convinced you it was no longer earning its place?
What a strong answer shows
Whether they treat process as a cost as well as a benefit. Managers who can only describe what they introduced are usually accumulating ceremony that nobody has been assigned to question.
How is the technical direction of your team decided, and what is your part in it?
What a strong answer shows
Boundary clarity. The concerning answers are at both extremes: a manager who decides technically by default, and one who cannot describe how decisions get made at all.
Someone excellent tells you they are considering leaving. What do you do, and what should have happened earlier?
What a strong answer shows
Retention understood as a long practice rather than a counter-offer. The second half of the question is where the useful answer lives, and candidates who focus only on the response have usually not examined the run-up.
What is the hardest thing about your current team that you have not solved?
What a strong answer shows
Candour and self-assessment. A manager with no unsolved problem is either describing an unusually fortunate situation or is not looking closely at the one they have.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A growing engineering group has outrun the arrangements that supported it. Development conversations happen when delivery allows, expectations for progression are unwritten, coordination with other functions relies on individual relationships, and commitments slip for reasons that have little to do with the engineering itself.
- Approach
- Additional management capacity operates entirely within the client’s organisation — the client’s reporting lines, the client’s progression framework, the client’s priorities and the client’s engineering standards. Decisions about performance, promotion, pay and team structure remain the client’s, as does all technical and architectural direction.
- What this adds to the team
- The organisation gains experienced capacity for the work of running a team, while every decision about people, structure, product and technical direction stays with the client and its own leadership.
Related disciplines
Frequently asked questions
- What is the difference between an engineering manager and a tech lead?
- They are accountable for different things about the same team. The manager answers for how the team functions: who joins it, how people develop, how performance is handled, how work is coordinated and whether delivery can be relied upon. The tech lead answers for the technical substance of the work — how it is designed, reviewed and built to a consistent standard. In smaller organisations one person often carries both, which works while the team is small and tends to break as it grows, because the two remits compete for attention and the urgent one wins.
- What is the difference between an engineering manager and a project manager?
- A project manager is accountable for a defined piece of work reaching completion — scope, schedule, dependencies, reporting — and the accountability ends when the project does. An engineering manager is accountable for a standing team over time, including the people in it, which continues regardless of what is currently being delivered. A project manager coordinates work; an engineering manager builds and sustains the capability that does it.
- Does an engineering manager need to be technical?
- They need enough technical literacy to judge risk, hold a substantive conversation about trade-offs, sponsor a promotion credibly and represent constraints outside the team. They do not need to be the strongest engineer present, and the belief that they should be produces managers who compete with their own team. Managers from a non-engineering background can succeed where technical decision-making is genuinely owned elsewhere, though they generally need a strong technical partner and considerable humility about what they cannot assess.
- Should an engineering manager still write code?
- A little, on work that is not on the critical path, is a reasonable way to stay literate and to experience the same obstacles the team lives with. As a routine commitment it usually fails: management work is interruptible and unpredictable, so the code becomes the thing that slips, and the manager becomes an unreliable dependency for their own team. The safest form is small, deferrable and nobody’s blocker.
- How many engineers should one manager support?
- The workable span is in single figures, and it varies with how much else the person carries. A manager who is also acting as technical lead, or supporting several people through significant growth, or holding a large share of cross-functional coordination, will reach the limit sooner. The reliable indication of an over-extended span is not a number but a pattern: one-to-ones being cancelled, feedback delayed, and the manager learning about problems from other people.
- What should stay with the team rather than the manager?
- Technical decisions, design approaches, estimates and the details of how work is done. A manager who takes these on removes the ownership that makes a team capable of operating without them, and creates a bottleneck that gets worse as the team grows. The manager’s contribution is to make sure those decisions are made by the right people, with the right information, and that the consequences are visible.
- How does an engineering manager work with an existing engineering team?
- Inside your organisation’s structure, never over it. Where a role is staffed through augmentation, your organisation keeps reporting lines, performance and pay decisions, progression, team structure, priorities and process, together with architecture, technical direction and product ownership. Your leadership directs the work. Talent.ID holds the employment side alone — the employment relationship, payroll, employee benefits and talent administration — and no part of running your engineering organisation moves with it.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.