What the level actually means — scope, blast radius, and how to tell.
Engineering Manager
Also seen as: EM, Development Manager, Software Engineering Manager, M1, Team Lead (sometimes)
Scope
One team, typically 5-9 engineers. Owns what the team delivers and, equally, whether the people on it are getting better and staying.
Blast radius
The team's output and its retention. A bad EM shows up as attrition six to twelve months later — the slowest and most expensive failure mode in engineering to detect, because by the time it's visible the good people have already gone.
Autonomy
Given team goals and headcount; owns how the work gets divided and who does it. Escalates trade-offs rather than absorbing them silently.
With other people
The job is mostly other people: one-to-ones, performance conversations, hiring, unblocking, and translating between the team and everyone else. Whether they still write code varies enormously by company and says little about quality.
Resume tells
Names team size, and how it changed under them — growing a team from 4 to 9 is a different job from inheriting 9
Describes outcomes delivered through other people, not features they personally shipped
Evidence of hiring: how many, and whether those hires are still there
Someone they grew, and where that person got to
A process change they made, and what it cost as well as what it fixed
Title inflation risk
'Team Lead', 'Tech Lead' and 'Engineering Manager' get used interchangeably, and they are not the same job. A Tech Lead with no direct reports has never done performance management, hiring, or a difficult conversation about someone's future — the parts that are actually hard. Watch for player-coach titles at small companies where someone codes 80% of the time and 'manages' two people.
Calibration questions
“How many direct reports did you have, and did that include performance reviews and compensation conversations?”
“Tell me about someone on your team who wasn't performing. What did you do, and how did it end?”
“Who did you hire, and how many of them are still there?”
“What percentage of your week was hands-on code, and was that the right amount?”
Where this goes wrong
Hiring a Tech Lead into an EM role, or the reverse. Ask about direct reports and performance management within the first five minutes — it sorts this faster than anything else. The other common failure is hiring an EM who wants to keep coding into a role with no coding time, which ends in a resignation about a year in.
Years of experience: Usually 5+ years as an engineer first, but there's no reliable number here. Some of the best EMs moved across early; some people with fifteen years of engineering make poor first-time managers.
Staff or manager? The fork
Staff engineers and Engineering Managers both work across team boundaries and both influence people who don't report to them, so their resumes can read almost identically. The difference is not seniority — they are peer rungs at most companies. It's where the leverage comes from: a Staff engineer's comes from technical judgement and the documents and designs that carry it; an EM's comes from the people they hire, grow and organise.
“Have you had direct reports, and do you want them?”
A Staff engineer's impact story ends in a technical decision that changed what teams built. An EM's ends in a team that shipped, grew, or stopped losing people.
Ask what they'd want to spend a Tuesday on. Staff-inclined people describe a problem; management-inclined people describe their team.
Someone who moved to management and back to IC is not a red flag — it's one of the more useful things a candidate can tell you about themselves, and it's usually deliberate.
Player-coach roles — 'you'll manage four people and still code half the time' — satisfy neither track and are a common source of one-year attrition. If a req reads like that, it's worth establishing with the hiring manager which half they'd sacrifice under pressure, because they will have to.
Where was the title earned?
The same title means different things at different companies. Apply this before believing the level on a resume.
Seed / early startup (under ~50 people)
Titles are recruiting currency and cost nothing to give. 'Senior' often means 'third engineer hired'. Scope can genuinely be large — they may have built whole systems alone — but calibration against a wider bar has never happened.
“How many engineers were at the company when you joined, and when you left?”
Growth-stage (~50-500 people)
The ladder is usually being invented while people are on it. Titles are often regularised in a single re-levelling event, so the same person can be Mid one quarter and Senior the next without the job changing.
“Was there a re-levelling or a formal promotion process, and where did you land in it?”
Large tech company with a calibrated ladder
Titles mean something specific and were defended in a promotion committee. A Senior here has been measured against a written bar. This is the most reliable title signal you'll get — and the reason level codes (L5, IC3) are worth asking for.
“What level were you at, in your company's internal terms, and when were you last promoted?”
Agency, consultancy or outsourcing firm
Titles are often client-facing and inflate to justify billing rates. Scope tends to be broad but shallow — many projects, rarely owning anything after handover. The 'operate it after launch' evidence that separates Senior from Mid is frequently missing, through no fault of theirs.
“Which of those projects did you stay on after go-live, and what did you have to fix?”
Non-tech company (bank, retailer, manufacturer, public sector)
Ladders are often HR-wide rather than engineering-specific, and titles can be tied to tenure or grade rather than scope. Deep domain expertise is common; exposure to modern tooling and fast release cycles may not be.
“How often did your team release, and who decided when something shipped?”