It's 6 PM on a Thursday and you have three things to close out before the week ends: a 1:1 with a senior developer whose performance has been slipping, who doesn't know yet that you've noticed; a conversation with Product about which feature drops from the sprint because the team won't make it; and a Slack message from a stakeholder asking why the project is two weeks behind. You won't write a single line of code all day. And of the three, whichever one you handle worst today is the one that costs you the most next week.
That's an average Tuesday for an Engineering Manager (EM), and it's a fairly different job from the one you had as a senior developer, even if it sounds similar on paper.
Put simply: an Engineering Manager (EM) is responsible for the sustainable delivery of an engineering team, clearing what blocks people (unclear priorities, friction with other teams, missing context, performance issues) so each developer can do their best work. It isn't the most senior coding role on the team. It's the person who owns whether the team, as a whole, functions.
Engineering Manager isn't the same as Tech Lead
The confusion makes sense, because at plenty of companies, especially smaller ones, one person does both jobs. But they're different roles, and it's worth separating them even if they currently live in the same person at your company.
A tech lead keeps technical authority: they set architecture, review the hardest design decisions, and often still write code in the trickiest parts of the system. Their influence comes from technical competence, not from managing people.
An EM manages people, priorities, and blockers. They decide, or negotiate, what makes it into the sprint, have the hard performance conversations, decide who works on what, and absorb organizational friction so the team doesn't have to deal with it directly. Their influence comes from formal authority over people and priorities, not from being the one who best understands the codebase.
At larger, more mature companies, both roles usually coexist, with formal reporting to the EM and technical authority delegated to the tech lead. At smaller companies, it's common for the EM to also act as tech lead, especially on small teams. Neither structure is wrong. What's worth knowing before you take an EM role is which version you're signing up for, because it changes how much real technical time you'll have left.
A typical example of what the difference looks like in practice: a tech lead might spend an entire afternoon reviewing a database migration design line by line with the team. An EM, that same day, might spend the whole afternoon in 1:1s, adjusting the roadmap with Product, and resolving a priority conflict between two teams. Both jobs matter. Neither replaces the other, and mixing them up is usually the root of unclear expectations about what each role is supposed to do.
What actually gets measured for an EM (it doesn't look like what measured you as an IC)
As a senior developer, your work got measured in visible things: features shipped, code quality, PRs merged, the technical difficulty of what you solved. As an EM, the metrics change almost entirely.
An EM gets measured, formally or informally, on the team's predictable delivery (not yours, the whole team's), the retention of the people who report to them, the real growth of those people over time, and the health of the process: how much friction exists between the team and the rest of the organization, how clear priorities are, how much noise there is in meetings.
This has a consequence a lot of senior ICs don't see coming: good EM work tends to be invisible. Nobody notices the conflict between two developers that you resolved in a 1:1 before it escalated. Nobody notices the badly defined priority you fixed with Product before the team spent two weeks building the wrong thing. If you need to see the result of your work reflected in something you can point to (a feature in production, a commit, a demo), the most important part of EM work is going to frustrate you, because that part leaves no visible trace when it goes well.
In practice, this shows up as concrete rituals: weekly 1:1s with every person on the team, occasional skip levels if you also manage other managers, and performance reviews that work as a real development tool instead of an annual formality. How well you sustain those rituals matters as much as any delivery number, even though it never shows up on a dashboard.
The trade-off nobody tells you about: you stop coding for real
Nobody tells you this plainly in the interview, so we will: if you move into EM, you stop coding for real. Not overnight, and at plenty of companies you'll still get to jump into something specific, review a tricky PR, fix a critical bug on a weekend. But the hands-on time you had as a senior IC (already reduced if you came from a more senior role) drops to something marginal.
In calendar terms, the change is stark: you go from having multi-hour blocks free to focus on a single technical problem to a day fragmented into 30-minute meetings with 15-minute gaps in between. That's not a minor scheduling detail. It changes the entire kind of cognitive work you can sustain during the day.
If your professional identity is built around being the best coder on the team, this change is going to hurt more than you expect. It isn't a skill problem, it's a question of where your energy goes every day. You move from solving concrete technical problems to solving human ones, almost always messier and less tidy than a bug with a stack trace.
Some senior people try the EM role, deeply miss the daily technical work, and go back to an IC role without that being a failure. That's valuable information about what actually gives you energy at work, and it's much better to find out by trying the role for six months or a year than by regretting it a decade later.
When it makes sense to move from senior IC to EM (and when it doesn't)
The good fit has fairly concrete signals. If unblocking someone who was stuck energizes you more than merging your own PR, that's a strong one. If you genuinely care about multiplying your impact through other people's decisions rather than through your own hands, that's another. And if you have real, not aspirational, patience for messy human problems (someone underperforming, two developers who don't get along, a stakeholder asking for something unreasonable), the daily work of EM will feel sustainable instead of exhausting.
The bad fit has clear signals too, and it's worth being honest with yourself here. Looking for the EM role to escape technical ambiguity (getting tired of hard architecture decisions, for example) is a bad reason, because the role has its own ambiguity, just about people instead of systems. Wanting it for the title or the prestige, without actually wanting the daily work of managing people, doesn't work either. It shows fast, both to you and to the people reporting to you.
There's a middle ground worth naming: trying the role temporarily, covering a leave or leading a small team for a few months, is one of the cheapest ways to find out whether the work fits you before committing fully. If your company offers that option, it's worth taking before deciding in the abstract.
It's worth mentioning something many mature companies have but don't always communicate well: an IC career track that reaches levels comparable to EM (senior, staff, principal engineer), with equivalent compensation at the top bands. It isn't universal (it depends a lot on the company and how formalized that path is), but if you're weighing the jump, it's worth asking explicitly about EM versus Staff or Principal Engineer compensation bands at that specific company, before assuming managing people is the only way up.
The level of seniority that usually precedes this jump has less to do with years of experience and more with how you understand your own technical judgment. It's worth getting clear on that first, by looking at how seniority is actually defined in tech. Becoming an EM won't fit if you treat it as an automatic promotion. It will fit if you understand it's a different job, with its own craft, built around making things happen through other people.
