The title ‘Engineering Manager’ is doing a lot of damage.
Not because the work it describes isn’t real. But because what we’ve collectively decided the title means and what’s actually required to do the job well are increasingly disconnected.
Most engineers who move into Engineering Manager roles arrive expecting to manage engineering. They find that most of their job is managing people, managing expectations, managing information, and managing organisational dynamics that have almost nothing to do with writing code.
This surprise is not a personal failure. It’s a failure of the title.
What the Title Implies
‘Engineering Manager’ implies that engineering is the primary noun and managing is the mode. The job is about engineering you just happen to do it by managing people rather than writing code yourself.
This is almost completely wrong for most EM roles at scale.
What engineering managers actually spend their time on:
– Performance conversations and career development (30-40% of their time)
– Stakeholder management: product, design, finance, senior leadership (20-30%)
– Organisational and process design (15-20%)
– Hiring, onboarding, and team structure (10-15%)
– Technical direction and architecture (10-20%, and often less than this)
The technical component varies by organisation and team size. But in almost every EM role I’ve observed, the primary leverage comes not from technical decisions but from people and organisational decisions.
Why This Mismatch Is Expensive
Engineers who take EM roles expecting primarily technical work are set up to fail or to be deeply unhappy.
They optimise for the part of the job that feels familiar technical oversight and neglect the parts that create the most value: developing the engineers on their team, building clear communication channels to the rest of the organisation, designing team processes that reduce friction.
They often get into detailed technical debates when they should be giving their team autonomy. They attend technical design sessions when they should be in stakeholder conversations. They review PRs when they should be doing one to ones.
The engineers who thrive in EM roles are almost universally the ones who genuinely enjoy the people and organisational work who find career conversations more interesting than code reviews, who are energised by clearing blockers rather than solving technical problems.
What We Should Call It
‘Engineering People Leader’ is more accurate, though not particularly catchy.
‘Team Lead’ conflates it with senior IC roles in many organisations.
Some organisations use ‘Engineering Director of Team X’ better but suggests a seniority level that doesn’t always apply.
What I’ve seen work best in practice: explicit framing of the role as two distinct work streams, with intentional time allocation between them.
‘Engineering Lead (People)’ for the EM function someone whose primary charter is developing the humans and the team process.
‘Engineering Lead (Technical)’ or ‘Staff Engineer’ for the IC who owns technical direction.
Many teams benefit from having both. The organisations that insist one person must do both often find that one function gets systematically neglected and it’s almost always the people function that loses.
The Uncomfortable Implication
If the job is primarily about people and organisational development rather than technical work, then the selection criteria for Engineering Managers should weight differently than they currently do.
We predominantly select EMs based on technical performance as an IC. We assume that great engineers make great managers because they’ll bring technical credibility to the role.
Sometimes they do. But technical credibility is a minor contributor to EM effectiveness compared to communication skill, emotional intelligence, organisational awareness, and genuine interest in other people’s development.
We are selecting for the wrong things and then expressing surprise when technically excellent engineers become mediocre or miserable managers.
The fix is not to stop promoting strong engineers into EM roles. It’s to be honest about what the role requires before the transition, support the development of the non-technical skills the role demands, and create a clear, respected, well compensated IC track for the engineers who are exceptional technically but have no interest in the people work.
Both tracks matter. Both should be treated as senior career paths. And the title should be honest about what each actually does.
I recognise this is a view that will frustrate some current EMs. Happy to be challenged.