It’s a career change, not a promotion
I’m about to make this move myself, so I’ve spent the last while talking to people who’ve done it and reading whatever I could find. The clearest lesson so far: going from engineer to engineering manager isn’t a step up. It’s a step sideways into a completely different job. Your output stops being code and becomes whatever your team produces. Everyone says this, and from what I can tell, everyone still underestimates it.
What actually changes
You stop solving technical problems directly and start solving people problems. The calendar fills up with 1:1s, planning meetings, and cross-team alignment. Hiring and performance reviews land on your desk. Most of the job becomes making sure the team has what it needs — context, clear priorities, and as little nonsense as possible — to get on with the work.
The awkward part is that you still have to stay technical enough to hold your own in architecture discussions and make sensible judgment calls, while accepting that you can’t be the one writing the code anymore. The managers I’ve watched try to do both usually end up doing both badly.
Engineer vs engineering manager, side by side
| Software engineer | Engineering manager | |
|---|---|---|
| Your output | Code, designs, reviews | What the team ships, and the team itself |
| Judged on | The quality and impact of your own work | Delivery, retention, and how much people grow |
| A typical day | Focus time, pull requests, design discussions | 1:1s, planning, hiring, unblocking people |
| Feedback loop | Hours or days: the tests pass, the feature ships | Months: a hire works out, someone gets promoted |
| Hands-on technical work | Most of the week | Reviews and architecture calls, rarely the critical path |
The feedback loop is the row people warn about most. As an engineer you get a small win most days. As a manager the wins are real but slow, and you have to get used to not knowing for a while whether a decision was right.
The skills that seem to matter
Communication is most of it. You become the translator between your team, product, and leadership, and a surprising amount of the job is making sure those three groups are talking about the same thing. Trust matters more than any process: if people don’t feel safe telling you what’s broken, you’ll be the last person to find out. Your calendar will genuinely try to eat you alive, so protecting time to think — and time for your team — is a constant fight. And you need to understand what the business is actually trying to do, or you can’t point anyone in a useful direction.
Preparing before the title arrives
The advice I keep hearing, and the bit I can already vouch for: start leading before anyone gives you the title. Run a project, mentor someone, organise something. I’ve spent the past year acting as a project lead, and that experience is doing far more for me than any book. That said, books help — “The Manager’s Path” by Camille Fournier is the one everybody recommends, and having read it, I see why. Keep your technical skills sharp, because the architecture debates don’t stop. And find a mentor who’s already made the transition; they’ll steer you around mistakes that only look obvious in hindsight.
The trade-off
More influence over how things get built, but you’ll rarely build them yourself. I expect some days that will feel great, and other days I’ll badly miss writing code. Everyone who’s done this tells me that’s normal. Ask me again in six months.