Home → Leadership
Developer to Manager: A Career Change, Not a Promotion
We take the strongest engineer on the team, make them a manager, and call it a promotion. What we are actually doing is asking someone to drop a craft they spent ten years learning and start a job they have never done — one they often cannot walk back from.
- Two different jobs. One scales systems, the other scales people; they overlap less than you think.
- Clear test: if you wrote no code for a week, would anyone be blocked? If yes, you are the bottleneck.
- A bad match costs twice. You lose a strong engineer and gain an unhappy manager.
- Going back is not a failure — but only if that was said out loud beforehand.
In week one, nothing looks different
New title, same desk, same team. So you keep working the way you always did: two stories in the sprint, the hardest one for yourself — because you will finish it fastest. This is the reasonable-looking first mistake almost everyone makes.
I made it too. In the second sprint after my transition, the most critical story in the payments area was mine. That same week brought two 1:1s, a hiring loop and a production incident. The story sat still, and three people spent Thursday waiting on it.
The person who told me this in the retro was the most junior engineer on the team: "When you are busy nobody opens that code, because they assume it is yours." When I added it up, the picture was worse than it felt: the hours my work made other people wait cost far more than the code I wrote.
What actually changed
The hard part of the transition is not the workload. It is that the feedback loop gets longer. In engineering you know in twenty minutes: the test passed or it did not. In management you often learn whether a decision was right months later.
| Engineer | Manager | |
|---|---|---|
| Output | Code you wrote | What the team shipped |
| Feedback | Minutes | Weeks, sometimes months |
| A good day feels like | "I finished that" | "What did I even do today?" |
| Measure of success | Problems you solved | Problems solved without you |
The third row is what wears people down in the first months. You close the laptop with nothing to show. Yet that day you may have corrected a hiring decision, defused a conflict before it grew and kept someone from leaving — none of which appears in a commit log.
"Can I still do code reviews?"
This is the most common question and the answer is not categorical. A manager who stops writing code entirely loses the instinct to challenge estimates within about six months: someone says "three days" and nothing inside objects. A manager who does not stop keeps the team waiting.
- Small tools and scripts that speed up the developer experience
- A one-day prototype that makes an expensive question cheap
- Reviewing code — without being the final word
- Taking an occasional on-call shift, to remember the pain
- A story inside the sprint commitment
- Anything on the critical path that others wait for
- The "I'll take the hard one" reflex
- Making an architecture call alone and announcing it
One-sentence measure: if you wrote no code for a week and nobody was blocked, you are taking on the right work.
Who to offer it to
"Best engineer" is a poor criterion. A better one: does this person enjoy making someone else's work easier? You can see it before the promotion — the person who updates onboarding docs unasked, who writes a worked example in a review, who slows their own work down to get a new joiner started.
And when you offer it, one honest sentence matters: "This is not a promotion, it is a different job. Try it for six months; if it is not for you, going back will not count as a failure — and I will say that to the team now, not later." Without that last part the exit closes, and an unhappy manager stays in place for years. The team pays for it.
The first ninety days
- Week 1: set up 1:1s and hand them the agenda. Change nothing else.
- Weeks 2-4: listen and write. Build the team's complaint list; fix only the two cheapest items this month.
- Weeks 5-8: get off the critical path. Hand over your stories — and let go when you do.
- Weeks 9-12: have the first hard conversation. It is the one thing that only gets harder with delay.
Checklist
- Did anyone wait on me this week?
- Besides me, how many people can make an architecture call?
- Did bad news reach me early or late this month?
- Is there any uninterrupted thinking time left on my calendar?
- Is my urge to write code a need, or a longing for a measurable output?
- Do I like this job — or does going back just feel embarrassing?
Conclusion
Management is not a level above engineering; it is a branch beside it. Done well, the team ships several times what you could alone. Done badly, a good engineer is lost and a team slows down.
The healthiest signal is this: six months in, the team gets through a week without you with no trouble. Read that as the definition of the job, not as a sign you are redundant.