David talks through career-track decisions like this one with candidates in the Beacon Devs network directly, not just at offer time.
Becoming an engineering manager works best when you're already doing parts of the job unofficially, unblocking teammates, running design discussions, being the person others ask first, not when you're bored of code or chasing a bigger title on its own.
Is it actually a promotion?Not really, and treating it as one is the most common reason people regret the move. It's better understood as a lateral transfer into a different discipline: people leadership, planning, and organizational work, instead of deeper technical craft. The comp doesn't reliably support the "promotion" framing either. At many companies, a staff-level individual contributor earns as much as or more than an engineering manager at the equivalent level, and the two tracks only clearly converge again at director and above.
That doesn't mean the move isn't worth making. It means the decision should be driven by whether you want the actual day-to-day of the job, not by assuming it's simply "the next rung."
The strongest signal isn't a feeling, it's a pattern of behavior that's already showing up before anyone gives you the title.
Teammates come to you when they're stuck, not just when they want a code review. You find yourself explaining architecture decisions more than making your own commits some weeks.
You catch yourself asking how a feature affects the roadmap, or whether the team can realistically ship on time with current headcount, not just whether your part is done.
You're in planning conversations before you have a formal reason to be, and your read on scope and risk gets asked for, not just your code.
You've volunteered to run a project, mentor someone formally, or lead a design discussion, and it held up under real conditions, not just in the abstract.
| What | Individual contributor (senior/staff) | Engineering manager |
|---|---|---|
| Daily focus | Design, code, and technical tradeoffs on your own work | People, planning, and unblocking a team's collective output |
| Success measured by | What you personally ship and the technical judgment behind it | Whether your team delivers, and whether they stay |
| Skill that matters most | Depth: solving hard technical problems well | Breadth: clear communication, prioritization, and people judgment |
| Typical comp trajectory | Can match or exceed EM pay at staff level and above | Steadier, less variance, lower ceiling until director+ |
| Reversibility | N/A | Returning to IC work is common and increasingly accepted |
Yes, and it's far less rare or stigmatized than most engineers assume before they try it. A frequent pattern: someone takes a management role, spends roughly two to five years in it, and then decides deliberately that they'd rather be building than managing. Among people who've actually seen a well-handled return happen, the stigma mostly isn't there, it's the people who've never seen it who assume it's a step backward.
The engineers who make this move well treat it as a genuine experiment, not a one-way door. The ones who struggle are usually the ones who took the title to prove something, not because they wanted the actual job.
Not really, it's better understood as a lateral move into a different discipline. Comp doesn't reliably exceed staying on a strong IC or staff track, especially at senior levels, where staff engineers at many companies match or outearn engineering managers at the same level.
You're already doing parts of the job unofficially: unblocking teammates, running design discussions, being the person others bring questions to, and thinking about roadmap tradeoffs instead of just your own ticket. Wanting a bigger title or being tired of writing code are not, on their own, good signals.
Not reliably. Some first-time IC-to-manager moves see a short-term dip before recovering over the next year or two, and at many companies a staff-level individual contributor earns as much or more than a manager at an equivalent level. Treat the move as a career-path decision, not a raise.
Yes, and it's increasingly common and far less stigmatized than it used to be. A frequent pattern is someone spending two to five years in management before deciding the day-to-day isn't for them, then returning to IC work deliberately rather than it being treated as a demotion.
Volunteer to lead a specific project or a small initiative before asking for the title. Mentor a junior engineer formally. Ask your current manager what their week actually looks like. Trying the behaviors first is far more informative than imagining the role from the outside.
David talks through career-track decisions like this one with candidates in the Beacon Devs network directly, not just at offer time.
Join the Beacon Devs candidate network. It's free, always, and most of the roles we fill never go on a job board.
Join the network