Eighteen months ago, I was a senior engineer writing code 6-7 hours a day, reviewing PRs, and occasionally mentoring junior devs. Today, I manage a team of 8 engineers and I write maybe 2 hours of code per week on a good week. Some days I don't open my IDE at all. This transition has been the most challenging and rewarding thing I've done in my career, and it was absolutely nothing like I expected.

I want to be transparent about what actually changes when you make this move, because the blog posts I read before making the switch painted a pretty sanitized picture. The reality is messier, harder, and — in ways I didn't anticipate — more fulfilling.

The Identity Crisis Nobody Warns You About

For 7 years, my identity was wrapped up in being a good engineer. I took pride in writing clean code, in being the person who could debug the gnarliest production issues, in the satisfaction of shipping features. When I became a manager, all of that vanished almost overnight.

My first month as a manager, I spent 80% of my time in meetings. 1:1s, sprint planning, stakeholder syncs, hiring discussions, cross-team alignments. I'd end the day feeling like I'd accomplished absolutely nothing because I hadn't produced any tangible output. No code committed. No PRs merged. No bugs fixed. Just... talking.

It took me about 3 months to recalibrate what "output" means for a manager. Your output isn't code anymore. It's the team's output. It's removing blockers so your engineers can be more productive. It's making decisions that save the team from going down a dead-end path. It's having the hard conversation with the engineer who's underperforming before it becomes a bigger problem. The impact is real, but it's indirect, and that's a genuinely difficult adjustment if you've spent your career measuring your worth in commits.

People Problems Are Harder Than Technical Problems

When I was an IC, the hardest problem I might face was debugging a race condition in our distributed system. It was frustrating, but the problem was logical. It had a root cause, and once I found it, I could fix it deterministically. People problems are nothing like that.

Within my first 6 months as a manager, I dealt with: two engineers who couldn't stand each other and were passive-aggressive in code reviews, a high performer who was threatening to quit over compensation, a junior engineer who was struggling but too afraid to ask for help, and a reorganization that moved half my team to a different project. There's no stack trace for interpersonal conflict.

The skill that's helped me most isn't any management framework or book (though "The Manager's Path" by Camille Fournier is genuinely excellent). It's learning to listen without immediately jumping to solutions. As engineers, we're trained to hear a problem and fix it. But when someone comes to you frustrated about their career growth or team dynamics, often they don't want you to fix it — they want to feel heard. Learning to sit with someone's frustration without trying to solve it was the hardest skill I've had to develop.

The Technical Skills You Still Need (and the Ones You Don't)

One fear I had was becoming technically irrelevant. There's this stereotype of the manager who hasn't written code in 5 years and makes out-of-touch technical decisions. I was terrified of becoming that person.

Here's what I've found after 18 months: you don't need to be the best coder on your team. In fact, you shouldn't be. If you are, you've either hired wrong or you're spending too much time coding. But you absolutely need to stay technical enough to understand the problems your team is solving, evaluate trade-offs in their proposals, and call BS when someone's estimate feels off.

I stay technical by reviewing architecture docs, sitting in on design discussions (without dominating them), and doing occasional code reviews on complex changes. I also spend about 2 hours a week reading technical blogs and papers in our domain. I'm not as sharp as I was as a full-time IC, and that's okay. My job isn't to be the sharpest engineer anymore. It's to make sure the team has the sharpest engineers and that they're empowered to do their best work.

How to Know If Management Is Right for You

Honestly? You won't know until you try it. But there are some signals that helped me decide. If you genuinely enjoy mentoring people and you get satisfaction from other people's growth — not just your own — that's a strong signal. If you find yourself naturally thinking about team dynamics, process improvements, and how to unblock people, you might be wired for management.

On the flip side, if your primary joy comes from solving technical problems yourself, if you hate meetings, or if the idea of having difficult performance conversations makes you physically uncomfortable, the IC track might be a better fit. And there's nothing wrong with that. Senior and staff IC roles carry just as much impact and often pay comparably.

A few practical steps if you're considering the switch:

• Try tech leading first. Most companies have tech lead or team lead roles that let you dip your toes into people management without fully leaving the IC track. It's the best possible trial run.
• Talk to managers honestly. Not the sanitized "leadership is so rewarding" talk. Ask them what they miss, what surprised them, what their worst day looks like. Get the unfiltered version.
• Know that it's reversible. Going back to IC is more common than people think. I've seen several managers return to the IC track, and their management experience actually made them better engineers because they understood team dynamics and organizational context in ways they didn't before.
• Prepare for the interview. Engineering management interviews are very different from IC interviews. They focus on scenarios, leadership philosophy, and how you've handled specific people situations. Practice these with mock interviews to get comfortable articulating your management approach.

What I'd Do Differently

If I could restart this transition, I'd do two things differently. First, I'd let go of coding sooner. I spent the first few months trying to be both a manager and a senior IC, and I did both poorly. My reports felt like I was micromanaging their code, and I was too distracted by pull requests to give my full attention to people issues.

Second, I'd find a management mentor from day one. I spent months figuring out things by trial and error that an experienced manager could have warned me about in a 30-minute coffee chat. Things like how to run an effective 1:1, how to deliver critical feedback without crushing someone's confidence, and how to push back on unreasonable demands from leadership without burning political capital.

Management isn't better or worse than being an IC. It's a different job with a different skill set and different rewards. The best decision I made wasn't becoming a manager — it was going in with my eyes open about what the role actually entails.