Switching From IC to Engineering Manager Without Losing Your Team

You shipped great code, mentored juniors informally, and now you're the engineering manager. Nobody gave you a manual, your first one-on-one is in two days, and the people who used to be your peers are now your direct reports. That gap between getting the title and knowing what to do with it is where most new managers quietly struggle.

The good news: you don't need to figure this out through trial and error alone. The patterns that sink new EMs are predictable, and so are the moves that build lasting credibility.

What you'll learn

• How to mentally shift from "doing" to "enabling" without feeling useless
• What to say (and not say) in your first weeks as a manager
• How to handle the awkwardness of managing former peers
• Which IC habits will hurt you and which ones will actually help
• How to measure your success when your output is no longer code

Why This Transition Breaks Smart Engineers

Individual contributors are rewarded for personal output. You write the feature, fix the bug, close the PR. The feedback loop is tight and the score is visible. Management inverts all of that. Your output is now the team's output, the feedback loop stretches across quarters, and your most important work is often invisible.

Engineers who were the best coders on the team frequently struggle the most. They've spent years building habits around personal execution, and those habits don't transfer cleanly. Reaching in to fix a problem yourself feels productive but signals to the team that you don't trust them — even when you have good intentions.

The First 30 Days: Listen More Than You Plan

Resist the urge to improve things immediately. You probably have real ideas about what's broken. Save them. In the first month, your job is almost entirely to understand context you don't have yet.

Run structured one-on-ones with every direct report in week one. Ask open questions: What's slowing you down? What would you change if you could? What do you wish your previous manager had done differently? Write down the answers. Don't commit to fixing anything yet — just listen and take notes.

You're building two things simultaneously: a picture of what's actually happening on the ground, and early trust signals that tell your team you're someone who pays attention. Both matter.

What to cover in early one-on-ones

• Current projects and any blockers
• How they prefer to receive feedback
• Their short-term goals and what motivates them
• Any concerns about the team transition (including your promotion)
• What a good working relationship with their manager looks like to them

Managing Former Peers Without Making It Weird

This is the part nobody talks about enough. You were colleagues. Maybe you complained about the same things, went to lunch, reviewed each other's code as equals. Now the dynamic has changed, and both of you feel it.

Address it directly and early. A short, honest conversation in a one-on-one goes a long way: