What Nobody Tells You About Going from Engineer to Engineering Manager

I spent years as an individual contributor. I started in Laravel and PHP, moved into React and TypeScript, worked my way up to lead frontend engineer. I was good at it. I liked it. I understood the feedback loops — write code, ship it, see it work (or break), fix it, repeat.

Then I became an engineering manager, and all of that changed.

The output problem

As an engineer, your output is tangible. You open a PR, it gets reviewed, it ships. You can point to it. You can measure it. At the end of the day, you built something.

As a manager, your output is… harder to see. You had a one-on-one that helped someone work through a problem they’d been stuck on. You made a staffing decision that won’t pay off for six months. You defused a conflict between two engineers who both thought they were right (and both kind of were).

None of that shows up in a commit log.

The hardest part of the transition wasn’t learning new skills — it was letting go of the old feedback loops. You have to find new ways to know you’re doing a good job, and most of them are lagging indicators. The team ships more. Retention improves. People grow into roles you helped them see for themselves.

It takes a while to trust that.

The things that transfer

Not everything changes, though. A lot of what made me a good engineer makes me a better manager:

Debugging is just problem-solving. When something’s broken on a team — low morale, missed deadlines, unclear ownership — the process is the same. Observe, form a hypothesis, test it, iterate. Don’t assume you know the root cause. Don’t fix symptoms.

Code review is a leadership skill. Giving good feedback on a PR taught me how to give good feedback on someone’s work, their communication, their career trajectory. Be specific. Be kind. Focus on the what and why, not the who.

Systems thinking scales. As an engineer, I thought about how components interact, where coupling creates problems, where abstractions help or hurt. As a manager, I think about the same things — except the components are people, processes, and incentives. The mental model is surprisingly transferable.

The things that don’t

Some engineering instincts actively work against you:

You can’t optimize people. Engineers like to find the most efficient path. People aren’t paths. They’re messy, emotional, motivated by things you can’t always see. Sometimes the “inefficient” approach — letting someone struggle through a problem instead of giving them the answer — is the right one.

Shipping fast isn’t always the goal. As an IC, I valued speed. Get it done, get it out, iterate. As a manager, sometimes the right move is to slow down. To let the team have the conversation. To not make the decision yourself even though you could make it faster.

Being right matters less than you think. I used to care a lot about being right — about architecture, about tooling, about approach. I still have opinions, but I’ve learned that the team owning a “good enough” decision is worth more than me imposing the “optimal” one. Ownership beats optimization almost every time.

The part nobody warns you about

The loneliest part of being a new manager is that your peer group changes overnight. Yesterday you were one of the engineers. Today you’re their manager. The jokes land differently. The venting goes somewhere else. You’re not in the group chat the same way anymore.

It’s not that people are unkind about it. It’s just… different. And you have to build new relationships — with other managers, with your own manager, with people outside your immediate team — to fill that gap.

That part took me longer to adjust to than any of the tactical stuff.

Would I go back?

No. I genuinely love this work. I love watching someone have the click moment where a concept lands. I love building teams that trust each other. I love the challenge of creating an environment where good engineers can do their best work.

But I’d be lying if I said I don’t miss the commit log sometimes.