Every job description for an Engineering Manager reads roughly the same. Lead a team. Drive delivery. Grow people. Collaborate with product. Own the technical roadmap.
It’s fiction.
I’ve been an Engineering Manager at multiple companies. The role has never been the same twice - not even close. And I’m not just talking about startup-versus-enterprise differences. I mean two managers at the same company, same level, same title, doing completely different jobs.
The standard definition is a myth we keep telling ourselves because it makes hiring easier. The reality is messier and more interesting.
The Four Pillars Nobody Told You About
In every context I’ve worked in, the EM role pulls across four areas: Product, Process, People, and Programming. The mistake is assuming they’re balanced equally. They never are.
What changes - radically - is which pillar consumes your week.
Large team? Programming disappears. You’re building careers, coordinating across teams, and navigating the organization to secure resources. Your calendar looks like a war zone of 1:1s and stakeholder meetings. That’s not a failure of time management. That’s the job.
Small team? Suddenly you’re managing scope against reality, trimming the roadmap, and - if the stars align - actually writing some code. The communication overhead is lower. You have breathing room.
No product manager? You’re the PM now. Validating features, prioritizing the backlog, sitting in on client calls. This takes over everything else, and it should. Shipping features nobody wants makes everything else pointless. I’ve seen teams work beautifully on the inside while slowly dying on the outside because nobody was checking whether the work mattered.
Reporting directly to the CEO? You’re suddenly the interface to sales, operations, and clients. You’ll spend more time explaining engineering tradeoffs to non-engineers than you ever expected. Your ability to translate is the job.
None of this is surprising in isolation. But somehow we still treat the EM role as if there’s a canonical version of it.
The Real Job Is Bottleneck Detection
Here’s what I’ve come to believe after years of doing this: the Engineering Manager’s primary job is to identify where the team’s bottleneck sits in the software development lifecycle, and fill it.
Not permanently. Not because you’re the most qualified person for it. But because the team’s ability to move forward depends on someone owning that constraint right now.
Sometimes that bottleneck is technical leadership. Sometimes it’s product clarity. Sometimes it’s someone willing to have hard conversations with stakeholders. Sometimes - honestly - it’s someone sitting down and writing the spec nobody else will write.
The pillar you focus on shifts as circumstances change. That’s not role ambiguity. That’s the design.
Will Larson has written about how “good engineering management” is essentially a series of fads - each era of the industry redefines what a manager should be based on business realities, then retrospectively frames the change as moral progress. He’s right. In hypergrowth, the manager was a talent magnet and coach. Post-ZIRP, suddenly managers need to be hands-on contributors again. The definition moves with the market.
What doesn’t move is this: your team has a constraint somewhere, and your job is to find it and resolve it. That stays true across every era, every company size, every reporting structure.
The Interview Trap
Here’s a mistake I see managers make, especially early in their careers: asking the interviewer “what do you expect from an Engineering Manager here?”
It sounds like a thoughtful question. It isn’t.
Most managers believe their own experience is the industry standard. They’ve been doing the job a certain way for years. If you ask what they expect, you’ll get a description of what they’ve seen - not what the role actually requires in that specific context. The answer will be confident and incomplete.
Ask instead about their daily life. What’s taking up most of their time right now? What problems keep coming back? Where does the team get stuck?
That conversation will tell you more about what the role actually is than any job description or generic answer about “ownership” and “technical leadership.”
You’re not just evaluating fit. You’re doing early bottleneck detection.
The Uncomfortable Part
Accepting that the role is context-defined rather than fixed puts the burden on you.
You can’t just get good at “being an EM” in the abstract. You have to get good at reading your situation, identifying the constraint, and shifting your focus accordingly - even when that means spending six months deep in product work when you’d rather be building engineering culture. Even when it means giving up coding for a year because the team needs a different kind of leadership right now.
The managers who struggle most are the ones who have a fixed idea of what their job looks like and try to impose it on every context. I’ve done it. It doesn’t end well.
The role requires flexibility not as a soft skill, but as a core operating principle.
That’s not what the job descriptions say. But it’s what the job is.