Engineering management is accountability for a team's output, health and careers rather than for code. It is a change of profession, not a promotion: the skills barely overlap with senior engineering, and the interview tests judgement under ambiguity rather than knowledge.
Steady demand20 min readEngineering Manager, Team Lead / Development Manager, Senior Engineering Manager, Director of Engineering, Head of EngineeringUpdated 2026-07-27
Assumes you know: Several years shipping software on a team, enough to read a design review credibly, Willing to be judged on outcomes you do not personally produce
Overview
What this area actually covers
Engineering management is accountability for a team: what it produces, how
healthy it is, who is on it, and whether those people are getting better. You
own hiring, one-to-ones, feedback, performance and promotion cases,
prioritisation and forecasting, and the flow of information in both directions
between your team and the rest of the company. You do not own product strategy,
and in most companies you do not own technical direction either.
Understand before anything else that this is a change of profession rather than
a promotion. Management and senior engineering share an org chart and a
vocabulary, and that similarity misleads. Decomposing a problem, holding a
system in your head, being right about a design — those transfer thinly. The
manager's skills are conducting a conversation someone does not want to have,
forecasting work you cannot see, writing so that a director changes their mind,
and noticing that a quiet person has checked out. Being excellent at the
previous job predicts very little about any of them.
Three adjacent roles get wrongly bundled in. A tech lead sets technical
direction without owning anyone's review. A staff or principal engineer has
influence across teams with no reporting lines at all. A delivery manager owns a
plan and its dependencies but not the people. If your appetite is for the
technical decisions, you want one of those three.
Now practise it
22 interview questions in Engineering Management, each with the rubric the interviewer is scoring against.
An EM loop tests a handful of separable capabilities, and candidates are
routinely strong on two and unrehearsed on the rest. The subsections follow the
capabilities rather than the calendar, ending with the scenario format most
interviews actually use.
Subsection
What it is for
People Management
One-to-ones, motivation, feedback, safety
Performance & Growth
Underperformance, promotion, stagnation
Hiring & Interviewing
Loops, bars, scorecards, defending a decision
Delivery & Planning
Commitments, capacity, dependencies, slips
Technical Judgement
Staying credible without writing the code
Org Design & Influence
Topology, alignment, managing upward
EM Scenarios
Situations handled live, with complications added
People Management covers the recurring machinery: one-to-ones that are not
status meetings, understanding what actually motivates a particular person,
delivering feedback that lands, and building an environment where someone will
tell you bad news early. It comes first because it is the substrate everything
else runs on — a performance conversation with someone you have never had a real
conversation with is a very different and much worse event. Expect structures
for the recurring one-to-one and worked language for feedback that is specific
without being cruel.
Performance & Growth is the hard end: managing someone whose work is below
the level their title implies, running a career framework honestly, writing a
promotion case that survives a committee, and handling a strong performer who
has stopped growing and is about to leave. It is separated out because it is the
part of the job with legal and human consequences, the part most managers are
taught worst, and the part interviewers probe hardest for whether you act or
avoid.
Hiring & Interviewing covers designing a loop, calibrating a bar, scoring
against evidence, and defending a no-hire when the team is drowning. It has its
own area because it is the highest-leverage thing a manager does and the easiest
to do badly under pressure. You will find material on structuring a scorecard,
running a debrief that is not swayed by the loudest interviewer, and the
specific ways sunk cost distorts a hiring decision.
Delivery & Planning deals with turning a demand into a commitment you can
keep: capacity planning that accounts for the things nobody plans for,
dependency management across teams, and communicating a slip upward before it
becomes a surprise. It exists separately because it is the visible half of the
job, the one your director judges you on weekly, and because the technique is
concrete enough to be taught.
Technical Judgement is about remaining credible when you no longer write the
code daily: reading a design well enough to ask the question that matters,
arbitrating between two senior engineers who disagree, and deciding how much
technical debt to carry. It is its own subsection because the failure modes run
in both directions — the manager who has drifted into being unable to evaluate
anything, and the one who cannot stop making the decisions themselves.
Org Design & Influence covers team topology and boundaries, cross-team
alignment, managing your own manager, and driving change in an organisation
where you have authority over eight people and need the cooperation of eighty.
It is separated out because it is what distinguishes a manager from a senior
manager, and because it is the material that leads towards director-level work.
EM Scenarios puts you in the situations live: two senior engineers in open
conflict, an inherited project three months late, an attrition wave, a top
performer who has quietly disengaged. It sits last because scenarios draw on
everything before them, and because this is the format the interview will
actually take.
Where it sits in a real business
The manager sits on the join between what the business has promised and what the
team can build, and most of the job is negotiating that join without lying in
either direction. Above you is a director who wants a forecast, early warning of
a slip and no surprises. Beside you is a product manager who owns what and why,
plus peer managers whose teams you depend on. Below you is a team whose careers
you now partly determine.
Your budget is people-time, denominated in headcount. So you will spend real
weeks of the year hiring, because a vacancy is a permanent tax on everyone else,
and you will operate compensation and levelling processes you did not design and
cannot override — meaning part of the job is explaining a decision you would not
have made. Because your output is other people's output, the only lever that
scales is who is on the team and what they point at.
The upward flow of information is the part new managers handle worst, and it is
worth seeing as a sequence, because the ordering of the messages is the whole
skill.
Loading diagram…
The message to study is the fifth. The director hears about the slip from the
manager, with options already attached, before hearing about it from anyone
else. A manager who reports the problem without options has escalated rather
than managed, and a manager who withholds it until the date arrives has spent
credibility they will need later. The last message matters too: an engineer who
is punished for reporting bad news early will report it late next time, and the
whole chain above depends on them not doing that.
Who does this work
Titles are unstable. At a small company, engineering manager means player-coach:
five or six reports, and you still pick up the tickets nobody misses when you
drop them. At scale the same title means no code and eight to ten reports. Above
that sit senior EMs with two teams, then directors who manage managers.
Development manager and team lead usually mean the same thing in enterprises
with older job families.
The hour-to-hour shape is what surprises people, so here is a representative
week.
Where the time goes
Roughly
What it looks like
One-to-ones
5-6 hours
Six half-hour conversations, the only reliable channel into how someone is really doing
Planning and forecasting
4 hours
Refinement, capacity, dependency chasing, rewriting a date you already gave
Upward and sideways
4 hours
Honest status, a written argument, a stakeholder who wants your team's time
Hiring
2-4 hours
Screens, debriefs, a scorecard nobody filled in
Technical involvement
3-4 hours
Reading designs and pull requests to stay credible, not to be the author
Unplanned people work
What is left
The conflict, the resignation, the reorganisation
Notice what is absent: a block of uninterrupted hours. That absence, not the
workload, is what former engineers find hardest.
It is also worth being clear about who you depend on. A tech lead or staff
engineer holds the technical direction you do not, and the relationship between
those two roles determines how well the team runs; where it is good, the manager
handles people and commitments and the lead handles design, and neither
undermines the other in public. A product manager owns what and why. A recruiter
determines how quickly your vacancy is filled and is influenced almost entirely
by how responsive you are. And your own manager is the person whose expectations
you have to shape actively, because nobody will tell you what they are.
The one-to-one, and what it is actually for
Five or six hours of the week go into recurring one-to-ones, and new managers
almost universally waste the first three months of them by running a status
meeting. Status is available from the board. What is not available anywhere else
is whether someone is bored, whether they are quietly considering leaving,
whether they think a decision you made was wrong, and whether the thing blocking
them is something they are embarrassed to raise.
The structural principle is that it is their meeting, not yours. That sounds
like a platitude until you apply it: they set the agenda, they speak first, and
you resist the urge to fill the silence with your own updates. A manager who
arrives with a list has converted the one channel into the team into another
broadcast.
A ONE-TO-ONE THAT IS WORTH THE HALF HOUR
Their agenda first, always.
"What is on your mind this week?" - then stop. If they have nothing,
that is data; the third consecutive nothing is worth a gentle probe.
Rotate one deeper question in each week. Pick one, not four.
- What is the most frustrating part of your week at the moment
- Is there anything you think we are getting wrong that nobody
is saying
- What would you want to be doing in a year that you are not
doing now
- Who on the team has helped you recently - I want to know
Your feedback, if you have any, delivered small and immediately.
Specific, dated, one thing. Feedback saved for a review is
feedback you have decided not to act on.
Their growth, roughly monthly rather than weekly.
What the next level looks like, what evidence exists so far,
and what the gap concretely is.
Close by writing two lines in your own notes.
What they said, and what you committed to. The commitments are
the ones you will otherwise forget, and forgetting one costs
more trust than the thing itself was worth.
The question that produces the most value per minute is the second one in that
list — asking what the team is getting wrong that nobody is saying. It works
because it gives explicit permission, and because it asks about the system
rather than about the person, which is far easier to answer honestly. The first
few times you ask it you will get nothing. Keep asking.
The other discipline is note-keeping, and it pays off in three separate places.
It is what makes a performance conversation specific rather than impressionistic.
It is what makes a promotion case writable, since a case is assembled from nine
months of instances that you will not otherwise recall. And it is what protects
someone quiet in a calibration meeting where the loudest evidence usually wins.
Demand, adoption and how that is changing
Demand for managers is a derivative of engineering headcount, not a market of
its own. Teams need one manager per six to ten engineers, so EM openings track
both the number of engineers and the span of control an organisation tolerates.
Both have been under pressure: the cost discipline that began in 2022 targeted
middle management deliberately, with several large technology companies naming
flattening and layer reduction as explicit goals. In practice that means wider
spans, fewer new EM roles, and more managers holding two teams than three years
ago.
Two other shifts matter. The individual-contributor ladder is now real at most
serious engineering companies, with staff and principal levels paying
comparably, so management has stopped being the only route upward and choosing
it is a genuine choice rather than a reward for tenure. And most EM roles are
still filled internally, because the hiring risk is high and internal candidates
come with evidence; external EM hiring concentrates in scale-ups. Treat the
field as steady and competitive rather than expanding.
A third shift is quieter and affects the content of the job rather than its
availability. As AI-assisted tooling raises the volume of code a team can
produce, the constraint moves further towards review capacity, judgement about
what should be built, and the coordination cost of shipping it safely. Those are
all management problems. It does not follow that more managers will be hired —
wider spans point the other way — but the managers who remain are being asked
less about throughput and more about whether the throughput was aimed at
anything.
What makes it hard
The part nobody warns you about is losing the feedback loop. Engineering hands
you a compiler, a test suite and a deploy: you learn within minutes whether you
were right, and that loop is most of what made the work satisfying. Management
gives you signals at a lag of weeks to quarters, usually confounded and often
unattributable. Did the team ship because of your reprioritisation or despite
it? You will not know. New managers often describe having done nothing all day
despite eight hours of talking, and this is the cause.
Performance conversations are the second thing. You will tell a competent,
decent person that their work is below the level their title implies, with
specific evidence, in a way that does not surprise them, having already
documented it — and then live alongside them as the person who said it. The
mechanics are learnable and taught badly. The emotional load is not reduced by
learning them, and a manager who avoids these conversations does more damage
than one who handles them clumsily, because avoidance teaches a team that the
stated bar is fictional.
Hiring is hard because the pressure runs the wrong way. A drowning team wants a
body, so the sunk cost of eleven interviews pulls you towards a candidate you
have reservations about, and that mistake lands on the same team six months
later. Holding a calibrated bar while your own delivery slips is a discipline,
and defending a no-hire against people who want the headcount filled is a skill
EM loops probe on purpose.
Saying no upwards is where first-time managers err in a predictable direction.
The job is converting demands into commitments you can keep, which means
declining, resequencing, or naming a price in scope. A manager who accepts
everything has not protected anyone; they have transferred an impossible plan
into the team and left the team to discover it. Done well this is mostly
written: assumptions stated, options with consequences, a recommendation, no
implied blame.
And you cannot debug a person. Reproduce it, bisect it, read the source — none
of that has an analogue. You act on partial information about someone's
motivation and find out much later whether you read it correctly.
Diagnosing before intervening
The scenario that appears in almost every EM loop is a version of "one of your
engineers is not delivering". What is being scored is not your intervention but
your diagnosis, because the same symptom has at least four causes and the
correct response differs completely between them.
Loading diagram…
The gate worth studying is the first. A surprising share of underperformance
cases turn out to be a manager who has never said the words out loud, and in
that situation the first intervention is not a plan or a process, it is a
conversation the manager should have had three months earlier. Interviewers ask
follow-up questions specifically to find candidates who leap to a formal process
before establishing whether the person has ever been told.
The second thing to notice is that two of the four leaves are not performance
problems at all. A capable engineer whose output collapsed after a
reorganisation, a bereavement or an on-call rotation that ate their week is
describing something about their circumstances, and treating it as a performance
matter is both wrong and expensive — the person usually leaves and takes their
capability with them.
When it genuinely is performance, the conversation itself has a shape worth
rehearsing, because ambiguity here is a kindness that helps nobody.
A PERFORMANCE CONVERSATION THAT LANDS
Open with the conclusion, not the evidence.
"I want to be direct with you. Your work over the last quarter has
been below what we expect at senior level, and I need us to change
that. I should have said this a month ago."
Give two or three specific instances, dated, factual, no adjectives.
"The payments retry change took five weeks against a two-week
estimate, and the estimate did not get revised until I asked.
The design for the ledger split arrived without alternatives,
and when it was challenged in review it was withdrawn rather
than defended."
Name the standard, not the person.
"At senior level I expect a slipping estimate to reach me from you
rather than from the board, and a design to arrive with the
options you rejected."
Ask, then be quiet. This is the part people rush.
"That is how it looks to me. How does it look to you?"
Agree something specific and short-horizon, and write it down.
"For the next six weeks: flag any estimate change within a day,
and bring the sharding design at the options stage. We will
talk about it in each one-to-one, and I will tell you plainly
if it is not moving."
Say what happens if it does not change. Do not soften this.
Two lines in that script carry most of the weight. The admission that you should
have said it earlier costs you nothing and disarms the reasonable objection that
this is coming out of nowhere. And the closing statement of consequence is the
one managers omit, which is precisely why the same conversation gets repeated
three times and then escalates to a formal process the person genuinely did not
see coming.
The vocabulary of the management layer
A lot of what makes the first six months disorienting is that decisions are
discussed in a vocabulary nobody explains. These are the words that carry
consequences.
Term
What it means
Why it matters
Span of control
How many people report directly to you
Above about eight, one-to-ones alone consume a day a week
Levelling
Assigning a person or role to an internal grade
Determines pay band, expectations and promotion distance
Calibration
Managers comparing ratings across teams before they are final
Your rating of your own engineer can be moved by peers
Promotion case
The written argument that someone is already operating at the next level
Built over quarters from evidence, not written in a week
Performance improvement plan
A formal, documented, time-boxed process
Often a legal instrument as much as a developmental one
Regretted attrition
Someone leaving whom the company wanted to keep
The number your director watches most closely about your team
Headcount and requisition
An approved budget line for a person, and the vacancy for it
Losing one to a reorganisation is quietly a large loss
Skip-level
Your manager meeting your reports without you
Normal and healthy; treating it as a threat is a tell
Two of those are worth extra attention because they surprise new managers.
Calibration means your assessment of your own engineer is negotiated with people
who have never met them, which is why undocumented impressions lose and written
evidence wins. And regretted attrition is the metric that most shapes how your
own performance is read, which has an uncomfortable implication: keeping a
strong engineer engaged is worth more to your standing than shipping one extra
project.
Why study it
Study it if leverage genuinely appeals, because a good manager raises the output
and durability of eight people by more than any of them could raise their own.
Study it if the people problems interest you on their own terms rather than as a
tax — if why a team with all the right engineers keeps missing is a question you
want to sit with. And study it for range: managers see the commercial context
and the budget, which is the material the director and CTO paths are made from.
Study it also if you are a tech lead with no intention of becoming a manager,
because half of this material is simply how to work with one. Knowing what your
manager is being asked for, why they keep pressing for a date, and what a
calibration meeting does to your promotion case makes you dramatically easier to
represent well.
Do not do it for money, since staff engineering often pays comparably at the
same level and costs far less of what you enjoy. Do not do it because you are
the strongest engineer on the team, which is the commonest reason and the worst.
Be clear-eyed about the return path: after twelve to eighteen months you can go
back with your credibility intact, but after three or four years without
shipping, returning usually means a step down in scope or title, because
interviews will test coding and design depth you have not exercised and all your
recent evidence describes other people's work. The door narrows steadily, and
people consistently overestimate how long it stays open.
If an EM loop is next week, note that it is structured unlike an engineering
loop. There is little to recall. You get scenarios — two senior engineers in
open conflict, an inherited project three months late, a top performer who has
stopped growing, an attrition wave — and you are scored on judgement: whether
you gather information before acting, whether you separate a performance problem
from a motivation problem from a system problem, whether you own the decision
instead of escalating it, and whether your answer survives the interviewer
adding a complication. Expect a delivery and forecasting round, a technical
judgement round checking you can still lead engineers, and a leadership round
where specific past examples beat frameworks. You prepare by having real stories
with real outcomes, including bad ones.
Your first hour
Write a feedback ledger, and show nobody. Take the four or five people you work
with most closely and for each write three sentences: one strength with a
specific instance and date, one thing limiting their impact with a specific
instance, and one concrete change you would ask for next quarter. No adjectives
you cannot evidence.
Priya - Senior Engineer
Strength: rewrote the payments-consumer retry logic (14 May) after spotting the
duplicate-charge pattern nobody had reported. Found it herself; fix was small.
Limit: her designs land as finished decisions. On the ledger split she had
chosen the schema before review, so both objections arrived as attacks.
Ask: bring the next design at the options stage, with two rejected and why.
Target: the sharding decision in Q3.
Now inspect what you wrote. A vague entry means you have an impression, not
evidence, and an impression is not deliverable in a performance conversation. If
a strength is really "agrees with me", or a limit is really "communicates
differently from me", you have found a bias you would otherwise have promoted
on. And if five of these took ninety minutes, note that a manager with eight
reports produces this every cycle on top of everything else.
The second thing to notice is which people were easy and which were hard. The
person you could not fill in is almost always the person you have the least
contact with rather than the person doing the least, and that gap is the single
most common way a quiet, competent engineer ends up under-rated in calibration.
Fixing it costs one deliberately different conversation a fortnight.
What this is not
It is not a promotion. The level may be higher, but you are starting a new
profession near zero, in front of an audience who depend on you being good at
it, with no compiler to tell you when you are wrong.
It is not technical authority. In healthy organisations the final technical
decision-maker is a staff engineer, principal engineer or architect, and a
manager who overrides designs from positional authority reliably loses the
team's best engineers.
Nor is it project management, though it contains some, or scrum mastery, though
you will run ceremonies. The distinction that matters is accountability: a
delivery manager owns a plan, and you own the people who make the plan possible
and the consequences when it does not hold.
It is not an escape from technical work: you keep enough depth to review a
design and arbitrate a dispute, you just stop being the one who writes the code.
And it is not permanent, though it becomes more so every year — which is worth
knowing before you take it rather than after.
Management is not the next rung of the engineering ladder; it is a different
ladder that happens to start on the same landing.