From engineer to engineering manager: a practical transition guide

By Luigi Di Lena · June 2026 · 9 min read

You got the promotion. Or maybe you're considering it. Either way, you're staring at a role that looks nothing like what made you successful so far. Welcome to one of the most disorienting career transitions in tech.

I've been through this transition myself and I've coached dozens of engineers through it. Here's what I wish someone had told me at the start.

The identity shift nobody warns you about

For years, your value was measured by the code you shipped, the systems you designed, the bugs you fixed. As a manager, none of that counts anymore. Your output is now your team's output. And that's a genuinely difficult thing to internalize.

Most new managers struggle with this for months. They keep jumping into code reviews, picking up tickets when the sprint is behind, rewriting things their reports wrote. It feels productive. It's not. It's actually the opposite — you're doing your old job badly while not doing your new job at all.

The first shift is accepting that your job is no longer to be the best engineer on the team. Your job is to make everyone else better.

What actually changes on day one

Let's be concrete about what's different:

• Your calendar fills up. You'll go from maybe 2-3 meetings a day to 5-8. This is normal and it won't go away. Your job now happens in conversations, not in your IDE.
• You lose the dopamine loop. No more daily sense of "I built something." Progress becomes slower, less tangible, and measured in quarters rather than sprints.
• People problems become your problems. Underperformers, conflicts between team members, someone unhappy about their project assignment. That's all you now.
• You get less feedback. As an IC, your PR gets reviewed. As a manager, you can go months without anyone telling you how you're doing.
• Context switching becomes constant. You might go from a 1:1 about someone's career growth straight into a budget discussion, then a technical design review. All in one hour.

The first 90 days: what to focus on

Don't try to change everything. Don't try to prove you deserve the role. Just focus on these three things:

1. Build relationships through real 1:1s

Your first priority is to understand each person on your team — what they care about, what frustrates them, where they want to go. Don't use 1:1s for status updates. You have standups for that.

Ask open questions: "What's the most frustrating thing about your work right now?" or "If you could change one thing about how the team operates, what would it be?" Then shut up and listen.

2. Learn the organizational context

As an IC, you could afford to ignore politics and focus on shipping. As a manager, you need to understand the landscape: who makes decisions, what your skip-level cares about, which teams you depend on, where the budget pressure is coming from.

This isn't politics for politics' sake. It's knowing where the currents run so you can steer your team in directions that actually get supported.

3. Don't make big changes yet

Resist the temptation to restructure the team, introduce new processes, or overhaul the sprint methodology in your first month. You don't have enough context yet. Things that look broken often have reasons you haven't discovered. Observe first. Change later, when you actually understand what needs fixing.

The five most common mistakes

Based on what I've seen across dozens of transitions:

Continuing to be an IC with a different title

If you're still writing code every day, you're not managing. Full stop. Some new managers do this because it's comfortable. Others do it because they don't trust their team. Either way, the result is the same: your reports don't grow, and you burn out trying to do two jobs.

Avoiding difficult conversations

Someone's underperforming. You can see it. You keep hoping it'll fix itself. It won't. The longer you wait, the harder the conversation gets, and the more resentment builds among the team members who are picking up the slack.

Trying to be liked instead of respected

You want your team to like you. That's human. But your job isn't to be their friend — it's to create an environment where they do their best work. Sometimes that means saying no. Sometimes it means giving feedback that's uncomfortable. The managers I respect most are the ones who were honest with me, not the ones who agreed with everything I said.

Over-engineering processes

New managers love introducing frameworks, templates, and tools. It gives them a sense of control. But process should solve a specific problem, not fill a void. Before you add any process, ask: "What specific problem does this fix, and is that problem actually hurting us?"

Not asking for help

You feel like you should know what you're doing. You don't, and that's fine. Find a mentor — another manager you respect, someone at a different company, or a coach who's been through this. The learning curve is steep and you don't need to do it alone.

If you're navigating this transition right now — or deciding whether to make it — a 30-minute session can give you the clarity to avoid the mistakes most new managers make on their own.

The skills that transfer (and the ones that don't)

Good news: many of your engineering skills remain valuable. Systems thinking, debugging complex problems, pattern recognition — all of that applies to organizational challenges too. When your team has a recurring problem, you can approach it the way you'd approach a system design: identify the root cause, test solutions, iterate.

What doesn't transfer: the perfectionism. In engineering, you can spend an extra day getting something right. In management, most decisions need to be made with 70% information. Waiting for 100% means you're always too late.

Managing former peers

This is the hardest part for most new managers. Yesterday you were equals. Today you're making decisions about their work, their performance reviews, potentially their promotions.

Address it directly in your first 1:1 with each person. Something like: "I know this is awkward. Our relationship is going to change, and I want to be upfront about that. My job is to help you succeed and to help the team succeed. I'm going to ask for your feedback on how I'm doing, and I expect you to be honest with me."

Then actually ask for feedback. And actually listen when you get it.

When to consider going back

Not everyone who tries management wants to stay. That's not failure — it's information. If after 6-12 months you find that you genuinely miss the craft of engineering more than you enjoy the work of developing people, the IC track is a perfectly valid path. Some of the most impactful people I've worked with are staff and principal engineers who tried management and returned with a much deeper understanding of how organizations work.

The bottom line

The transition from engineer to engineering manager is not a promotion in the traditional sense. It's a career change. You're giving up the thing you were good at to start over in something you've never done before. That takes courage, and it takes humility.

The managers who thrive are the ones who embrace being beginners again. They ask for help. They make mistakes openly. They focus on learning rather than proving. And they give themselves grace during the months when everything feels harder than it should.

If you're in the middle of this transition — or considering it — you don't have to figure it out alone.