The day I officially became a manager, I still wrote code. The day after that, I still wrote code. For weeks, I kept writing code, attending the same standups, reviewing the same PRs, and fitting “management stuff” into the gaps. It took me an embarrassingly long time to realise that I hadn’t actually changed what I was doing. I’d just added a new title to the old job.

That’s the trap, and nearly everyone falls into it.

It’s Not a Promotion

The framing matters. When organisations talk about someone “moving into management,” the language implies upward motion, a promotion, a reward for good IC work. But management isn’t above engineering on some hierarchy of importance. It’s a different job entirely. The skills that made you an excellent engineer, deep focus, individual output, solving hard technical problems, are not the skills that will make you an effective manager. Some of them will actively work against you.

Addy Osmani describes this as a mindset shift from “me” to “we.” As an IC, your value was measured by what you personally produced. As a manager, your value is measured by what your team produces, and the uncomfortable truth is that the best thing you can produce is often nothing visible at all. Your output becomes other people’s output. Your best days are the ones where you unblocked someone, had a conversation that shifted someone’s thinking, or made a decision that saved the team weeks of wasted effort. None of that shows up in a commit log.

The Productivity Trap

The hardest part of this transition, for me, was redefining what a productive day looked like. As an IC, I had clear signals, code shipped, bugs fixed, PRs merged. As a manager, I’d finish a day of back-to-back one-on-ones, a planning session, and a difficult conversation with a struggling team member, and feel like I’d accomplished nothing. The absence of tangible output felt like failure.

Jean Hsu’s advice for this transition resonated with me: keep a daily impact log. Write down what you did and what effect it had. Not because anyone’s going to read it, but because it retrains your brain to recognise that a conversation that helped someone get unstuck is output. A decision that prevented a bad architectural choice is output. It just doesn’t feel like it when you’re used to measuring yourself in lines of code.

Will Larson describes a related trap he calls “snacking”, gravitating toward small, easy, visible tasks because they give you the dopamine hit of completion. Reviewing a PR feels productive. Fixing a minor bug feels productive. But if you’re doing those things instead of having the difficult conversation about team structure or addressing the performance issue you’ve been avoiding, you’re optimising for your own comfort at the expense of your team.

The Pull Back to the Keyboard

The pull never fully goes away. I still feel it after 25 years. There’s something deeply satisfying about solving a well-defined technical problem, and management problems are almost never well-defined. They’re ambiguous, they involve emotions, and the feedback loops are measured in weeks or months rather than minutes.

Fournier captures this tension perfectly in The Manager’s Path. She describes the imagined life of a manager, strategic thinking, mentoring, shaping the future, versus the reality: calendar full of meetings, constant context-switching, and the nagging feeling that you’re not doing anything “real.” The engineers on your team are building things. You’re… talking about things being built.

The temptation is to keep one foot in the technical world. And to some extent, that’s healthy, I’ll cover staying technical in a later article. But there’s a difference between staying informed and staying in the critical path. If you’re still the person who has to approve every design decision, review every PR, or debug every production issue, you haven’t actually transitioned. You’re doing two jobs badly instead of one job well.

Finding New Sources of Satisfaction

The shift that eventually clicked for me was realising that the satisfaction of management is different, not lesser. Watching someone you’ve mentored get promoted. Seeing a team that was struggling start to gel and ship consistently. Having an engineer tell you that a conversation you had six months ago changed how they think about their career. These moments are deeply rewarding, they’re just slower and less frequent than the instant gratification of shipping code.

Liz Wiseman’s work on Multipliers versus Diminishers helped frame this for me. A Multiplier is a leader who amplifies the capabilities of everyone around them, who makes people smarter and more capable just by how they lead. A Diminisher is someone who, despite their own intelligence, suppresses the intelligence of others. The question isn’t “how much did I produce today?” It’s “did I make my team more capable today?”

That reframe was genuinely liberating. It meant that a day spent entirely in one-on-ones could be the most productive day of my week, if those conversations moved people forward.

Not Everyone Should Make This Transition

One of the things I’ve advocated for at every organisation I’ve worked in is creating strong IC tracks that go as high as management tracks. Jesse Anderson makes the point clearly: don’t force promotions into management. Ask people what they actually want. Some of the best engineers I’ve worked with would have been miserable managers, and pushing them into that role would have been a loss for everyone.

If you’re in the early stages of this transition and finding that you genuinely hate it, not just that it’s uncomfortable, because discomfort is normal, that’s worth paying attention to. Going back to an IC role isn’t a failure. It’s self-awareness. The industry needs excellent senior engineers as much as it needs excellent managers, and pretending otherwise does a disservice to both paths.

The Ongoing Negotiation

Becoming a manager isn’t a one-time event. It’s an ongoing negotiation between who you were and who you’re becoming. The IC identity doesn’t disappear, it becomes part of your foundation, informing how you think about problems and giving you credibility with your team. But it can’t be the whole of your identity any more.

The managers I respect most are the ones who’ve made peace with this tension rather than trying to resolve it. They miss writing code sometimes. They find management frustrating sometimes. And they’ve found enough meaning in the new work to keep choosing it, day after day, even when the old work calls to them.

That’s not a crisis. That’s just what growth feels like.