In short
You need a first engineering manager when the person currently doing the management — usually a founder or a lead engineer — is doing it badly because it is their fourth priority. The decision is not about team size alone: it is about whether one-to-ones, feedback, hiring and prioritisation are consistently happening, and what is being dropped so that they do.
Key facts
- The real trigger
- Management is happening late, or not at all
- Promote when
- Someone already does the work informally and wants it
- Hire externally when
- Nobody internally wants it, or the bar is unknown
- Assess on
- Evidence of people grown, not years of tenure
The moment it becomes obvious
The usual sequence is that a founder or lead takes on management informally, does it well for a while, and then starts doing it in gaps. One-to-ones move, feedback becomes annual, an underperformance conversation waits three months, and interview loops fall to whoever is free.
None of that shows up as a missed deadline immediately, which is why it runs longer than it should. It shows up later as attrition and as hires who never quite landed.
Readiness checklist
Tick the statements that are true today. Three or more usually means the layer is overdue.
- One-to-ones are cancelled more often than they happen.
- Nobody can name who is responsible for a struggling engineer's improvement.
- Interview loops are assembled ad hoc and feedback quality varies wildly.
- The lead engineer's own delivery has quietly stopped.
- Prioritisation conversations always escalate to a founder.
- New joiners take noticeably longer to become productive than the last cohort did.
Promote or hire
Both work. They fail for different reasons, so choose deliberately.
| Route | Works well when | Main risk |
|---|---|---|
| Promote internally | Someone already mentors, unblocks and wants the job | You lose your strongest engineer and gain an unsupported manager |
| Hire externally | Nobody internally wants it, or you need a bar you have not seen | Credibility takes longer, and cultural fit is assessed on less evidence |
| Split the role | Technical leadership and people management can sit with two people | Unclear decision rights unless written down explicitly |
| Do neither yet | The team is small and management is genuinely getting done | Drifting past the point where it stopped being true |
What to test in the interview
Four evidence areas that separate a manager from a senior engineer with a title.
Someone they grew
Ask for a specific person, what changed, over what period, and how they know. Vague answers here are the single most useful negative signal.
A performance conversation they handled
What the problem was, what they said, what happened next, and what they would do differently. You are testing whether they will actually have the hard conversation.
How they made delivery predictable
Concrete mechanisms — planning cadence, scope control, how they surfaced risk early — not a methodology name.
How they stay technically credible
Not whether they still code, but how they form a view on technical decisions they no longer make themselves.
Common questions
- At what team size do you need an engineering manager?
- There is no reliable universal number, and quoting one would be inventing a benchmark. The honest test is behavioural: whether management work is consistently happening and what is being sacrificed for it.
- Should the first manager still write code?
- Many do at first, and it helps credibility. The failure pattern is holding them to a full delivery load as well as a full management load, which reliably means one of the two is dropped.
- What if our best engineer does not want to manage?
- Take that at face value and build a senior individual-contributor path instead. Promoting a reluctant manager typically costs you both a good engineer and a functioning team.
- How is this different from hiring a Head of Engineering?
- A first engineering manager owns one team and its people. A Head of Engineering owns the whole engineering organisation, including managers, standards and often hiring strategy.
Turn this into a brief
Answer six short questions and you have a usable technical hiring brief you can keep improving, print or share internally.
Open the hiring brief builderAny percentages or figures shown in this article are illustrative examples used to explain the model. They are not quoted rates, market benchmarks or salary data.