The Hardest Refactor: From Engineer to Manager
Moving from engineer to manager isn't a promotion — it's a career change. On perfectionism, team diversity, and earning leadership one small moment at a time.
The code always did what I told it to. People don't. They do something better.
They surprise you.
What nobody tells you upfront
The transition from engineer to manager isn't a promotion. It's a career change disguised as one.
Your entire value system has to shift. As an engineer, you're measured by what you ship. As a manager, you're measured by what your team ships — and those are completely different games.
I learned this the hard way. My first instinct was to keep doing both: stay hands-on and manage the team. And honestly? Staying hands-on is still something I believe in. A manager who doesn't understand the code can't make good decisions about the code. But there's a version of "hands-on" that's actually just control — and I had to learn the difference.
The perfectionism trap
My biggest breakthrough wasn't learning how to run a sprint or give performance reviews. It was unlearning perfectionism.
As an engineer, perfectionism is almost a virtue. You care about the details. You push back on shortcuts. You refactor because it bothers you.
As a manager, perfectionism becomes a bottleneck — and worse, it spreads. I've seen engineers stay stuck in endless refinement loops, shipping nothing, because the bar they set for themselves was impossibly high. I've noticed this pattern repeatedly — in different teams, different companies. Smart people, talented people, paralyzed by their own standards.
The shift isn't about lowering the bar. It's about knowing which bar matters and when. Good enough to ship beats perfect and stuck — every time.
Building the right team
Hiring is one of the highest-leverage things a manager does — and also one of the easiest to get wrong.
The mistake most people make is optimizing purely for technical skill. But two developers with identical skills and identical working styles will hit the same walls at the same time. What actually makes a team resilient is personality diversity within the same role.
Think about two developers. One is an explorer — restless, always digging into new approaches, questioning the current solution, going down rabbit holes. This person creates noise and sometimes chaos, but they bring back knowledge. They're the reason your team doesn't fall behind the curve.
The other is a finisher — disciplined, focused, moves in straight lines. Give them a well-defined problem and a deadline, and they'll deliver. Every time.
You need both. The explorer keeps the team sharp. The finisher keeps the team moving. Hire only explorers and nothing ships. Hire only finishers and nothing evolves.
The chess board metaphor isn't about having different positions on the field — it's about having different minds playing the same position. Your job as a manager isn't to find the best player. It's to assemble a board where different thinking styles cover each other's blind spots.
The real job
Here's what I think the job actually is:
Remove friction. From the team's path, from the process, from the codebase, from each other.
Stay in the loop technically. Not to micromanage — to earn the trust to make good calls. An engineering manager who can't read a PR isn't managing engineering.
Make the feedback loop faster. Between writing code and knowing if it works. Between a decision and its consequences. Between a person and their growth.
Management and leadership are not the same thing
There's a distinction that took me longer than I'd like to admit to understand: management and leadership are not the same thing.
Management is a role. It comes with the job title. You manage processes, timelines, budgets, performance cycles. You can learn it. You can get better at it systematically. Most of it can even be documented.
Leadership is something else. It's why people follow you when they don't have to. It's the credibility you earn by making good calls, by being honest when it's uncomfortable, by caring about your team's growth more than your own optics.
You can't assign yourself leadership. Your team decides whether you have it.
The trap is thinking the promotion gave you both. It gave you one. The other you have to earn — slowly, repeatedly, in small moments most people don't notice until they add up.
What I'd tell an engineer considering the switch
The skills that made you a great engineer will help — but they'll also get in your way.
Your instinct to fix things yourself? Channel it into fixing systems instead of code.
Your eye for quality? Use it to build review culture, not to be the last line of defense.
Your love of clean architecture? Apply it to how your team works, not just what they build.
The transition is worth it — if you do it consciously. Most people stumble into management and spend years recovering. You don't have to.