Developer to Manager

The Grief Nobody Talks About

I talk to a lot of first-time engineering managers - including first-time CTOs. The situation is always the same. They were great software engineers. They shipped features, solved hard problems, got into flow state where hours disappeared. That felt good. That was why they got into this business.

Now? Wall-to-wall meetings. No real code in weeks. At the end of the day, nothing to show. Nothing made. This is grief. And nobody warned you.

Most new engineering managers go through this. The good ones admit it. The rest pretend they’re fine while quietly wondering if they made a terrible mistake. I know many of you are in that second group right now.

What You Actually Lose

Let’s be honest.

First: the dopamine. Deploying code gives you immediate feedback. Tests pass, feature works, users are happy. You knew if you did a good job. That feedback loop is gone now. Did that one-on-one go well? Was that feedback received correctly? You won’t know for months. Maybe never.

Then there’s flow state. I miss it myself sometimes. Deep work requires uninterrupted time. Managers don’t get uninterrupted time. Your job is interruptions now. That’s not a bug, that’s the job description (though nobody tells you that upfront).

You also lose being the expert. You were probably the best developer on the team - that’s why they promoted you. Now you’re a beginner again. No Stack Overflow for “how do I give difficult feedback to a senior developer who’s been here longer than me.” I looked. And while AI helps, it feels strange.

This loss is real. Pretending otherwise doesn’t help.

What You Gain (Eventually)

Here’s the thing nobody tells you: the gains take longer to appear than the losses.

Losses hit day one. You miss coding immediately. The gains? Six months to a year. If you stick with it.

The big one is leverage. I argue this is actually the entire point of management, but most people don’t frame it that way. A great developer can do the work of maybe two or three average developers. A great manager can make an entire team better. That’s 5x, 10x, 20x impact. But you won’t feel it until your team ships things you never could have built alone. That takes time. And faith. And trust.

You also get bigger problems. As a developer, you solved technical problems. As a manager, you solve people problems, strategy problems, organizational problems. These are harder. More ambiguous. Also more impactful. Whether that’s a good trade - honestly, it depends on you. Some people hate it. That’s fine.

There’s compounding impact too. The developer you mentored will mentor others. The process you fixed will outlive you. The culture you build multiplies across everyone who joins. This impact is invisible day-to-day but enormous over years. I didn’t understand this until I saw people I’d coached become CTOs themselves.

The trade isn’t worse. It’s different.

Managing Former Peers

A challenge many face when going from engineer to manager: Monday you were equals, complaining about the same things over lunch - the management was the enemy, if they could just let you work. Tuesday you’re their boss. The relationship changes whether you want it to or not.

Acknowledge the change

Don’t pretend nothing changed. Everything did. I’ve seen new managers try to act like “nothing’s different, we’re still buddies!” - it never works. Better to acknowledge it directly: “This is weird for both of us. Let’s figure it out.” That honesty helps more than pretending.

Distance is necessary

You can’t be their friend the same way anymore. Not because you don’t like them. But you now have information you can’t share. You’ll make decisions they disagree with. Finally you’re the one with the power to fire them - and you might need to use it. You need some distance to do your job. Uncomfortable? Yes. Necessary? Also yes.

Some relationships won’t survive

A few people will resent you for getting the promotion. That’s their problem, not yours. Focus on the people who want to work with you. I wasted too much energy on the resentful ones early in my career. This loss of peer connections is part of what makes leadership lonely.

Don’t play favorites

The temptation is strong. Your former lunch buddy shouldn’t get special treatment. Everyone’s watching. Act accordingly. You’re the role model now.

Handling complaints

The hardest part: you’ll hear complaints about management decisions. Sometimes those complaints are about you. And you can’t defend yourself the way you used to. You just have to take it. This gets easier with time. Not sure it ever gets easy. And the more people in your department, the more complaints you’ll hear - and from people who don’t know you! In a small team everyone knows your story, you went through the bad times together. In a big team, the new junior developer doesn’t know but thinks the CTO has no clue.

The Coding Trap

Don’t keep coding.

I did it. You’ll do it. It feels productive. It’s comfortable. You’re good at it. You jump in and fill the gap. You’re team is overloaded already, what can you do? CODE!

But it’s also making you worse at your new job.

Every hour you code is an hour you’re not managing. Not having one-on-ones. Not thinking about team dynamics. Not removing blockers. Not working on strategy and vision. Not supporting the CEO with technical expertise. You’re hiding in the thing you already know how to do. I get it. I did it for too long myself.

I’m not saying never touch code again. But be honest about why you’re doing it. “The team needs me to code” usually means “I don’t know how to contribute any other way yet.” That’s fine to admit. Most new managers feel this. Just don’t let it guide you. Coding from time to time because you enjoy it is fine - and it’s your responsibility to create an environment where this doesn’t create problems for the team.

If your code blocks the release, you’ve failed as a manager. You’re the bottleneck. Your job is to make the team work without you, not to make yourself indispensable. This is counterintuitive when you’ve spent your whole career becoming indispensable through technical skill.

The transition is hard. Harder than anyone tells you. Just recently I had a new CTO client for coaching who is blocked as a CTO because he is coding too much. The managers who make it are the ones who let go of their old identity and build a new one. That’s just what I’ve observed over 25 years.

Common Mistakes

I’ve made all of these. So will you.

My biggest: solving problems instead of coaching. A developer comes to you with a bug. You know the answer. It’s faster if you just tell them. But if you always give the answer, they’ll always need you. Ask questions instead. Let them struggle. That’s how they grow. This was hard for me - I liked being the one with answers.

Training means investing in a better future. If you’re not invest lots of time into training your team, the future will not be better but the same.

New managers also avoid hard conversations. As a developer, you could ignore a difficult colleague. As a manager, you own the team dynamics. That person everyone’s afraid of? Your problem now. You can’t pretend it’ll sort itself out. It won’t.

Then there’s measuring your day by what you produced. Stop asking “what did I make today?” Start asking “what did I enable today?” Different question. Different answer. Takes getting used to (Trick: One thing a day - do want big thing a day and it feels again like you accomplished something).

And waiting too long to let go of coding. There’s no perfect moment. You’ll never feel ready. But the longer you stay in the code, the longer your team waits for a real manager. Harsh? Maybe. True? From what I’ve seen, yes.

The developer-to-manager transition - or engineer to manager if you prefer, some are picky about developer, coder and engineer, not me ;-) is one of the hardest in tech. You’re learning a completely new job while grieving the old one. No wonder it’s overwhelming.

Most new managers struggle in silence. They think everyone else finds this easy. They don’t. I’ve talked to hundreds of them. The transition is hard for almost everyone.

If you’re wondering whether you made the right choice - that’s normal. Doesn’t mean you’re failing. Means you’re paying attention.

I’ve been through this transition myself. Made the mistakes. Eventually figured it out. Now I coach engineering managers and CTOs through exactly this. If you want someone in your corner who’s been there - let’s talk.

Learn About Coaching