Engineering Management

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.

The seven areas underneath

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.

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.

sequenceDiagram
    participant E as Engineer
    participant M as Engineering manager
    participant P as Product manager
    participant D as Director
    E->>M: The migration is harder than we scoped
    M->>E: What is the new realistic date and what is uncertain
    E-->>M: Three weeks late, the unknown is the data backfill
    M->>P: Date moves to 12 June, here are two scope options
    M->>D: Early warning, with the options and my recommendation
    D-->>M: Take option two and tell me if the backfill slips again
    M->>E: Option two confirmed, and nobody is annoyed with you

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.

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.

flowchart TD
    A[Output is below the level expected] --> B{Do they know it}
    B -->|No| C[Feedback gap, and that is yours]
    B -->|Yes| D{Could they do it before}
    D -->|Never| E[Skill or levelling problem]
    D -->|Yes, recently| F{Has something changed around them}
    F -->|Yes| G[System or life problem, not performance]
    F -->|No| H[Motivation problem, needs a direct conversation]

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.

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.