The Case for Becoming an Engineering Manager

The Case for Becoming a Manager

I read an article recently arguing that senior engineers shouldn't become managers. Observations are mostly right. The conclusion is still wrong. I made the switch last year and here's what I learned.

The question of whether experienced engineers should move into management has been on my mind for a while. Not as an abstract career question, but as something I’ve lived through. I made the switch last year and I’ve been turning over what I learned from that decision ever since. I kept putting off writing about it because the topic is genuinely complicated and I wasn’t sure I had a clean take.

Then I read “Don’t become an Engineering Manager” by Anton Zaides, and it gave me the push I needed. The arguments were sharp: the tech landscape is moving too fast to step away from hands-on work, the management ladder is flattening, and the pay is often lower than what a Staff engineer can command elsewhere. I agree with most of the observations. But the article frames management as a ladder optimization, which track has better odds, where’s the ceiling lower. I think that framing leads you to the wrong answer. The more interesting question is which skills you want to be building. When you look at it that way, the conclusion changes.

Why I switched

For most of my career I was an individual contributor. I loved writing code. I thought that was all I wanted to do.

What eventually pulled me toward management wasn’t dissatisfaction with IC work. It was impact. No matter how good you get, your output as an individual has a ceiling. I’d already bumped into that once when I moved from engineering into developer advocacy, and management was the next version of the same realization. If I could enable a team to do their best work, the collective output would be far greater than anything I’d produce on my own.

When a leadership gap opened up on the content team I’d been closest to, I saw my window. I pitched myself for the role before I felt ready for it. I didn’t know much about management, but I had a genuine connection to what the team was building and enough conviction to figure out the rest on the job.

That was enough to get started. It was not enough to be good at the job on day one. But even in this first year, it’s been one of the most rewarding chapters of my career.

Management is a skill decision, not a title decision

The conversation around engineering management almost always focuses on what you give up. Less time writing code. Less freedom to choose how you spend your day. A step off a technical track where demand and compensation are both high. All true.

What rarely gets discussed is what you gain. Not in title or authority, but in a set of skills that most engineers never build because nothing forces them to.

The most valuable thing management has taught me is how to communicate with precision when someone else’s work depends on it. When you’re an IC, unclear communication slows you down. When you’re a manager, unclear communication breaks your team. That difference in consequences makes you learn faster than you would any other way.

I’ll give you a specific example. A few months into the role, I was briefing a team member on a content project. I had the whole thing mapped out in my head: the structure, the angle, the audience it needed to reach. I started writing it all down, basically handing over a blueprint. And then I caught myself. I was about to do the thing I’d always done as an IC, solve the problem my way, except now I was asking someone else to execute my solution instead of finding their own.

So I pulled back. I shared the goal instead. Here’s who the piece is for, here’s what it needs to accomplish, here’s why it matters right now. And what came back was different from what I would have built. It was better in places I hadn’t considered, because the writer brought their own perspective to a problem I’d only described the shape of.

Here’s the thing: I wouldn’t have noticed that habit as an IC. When your own thinking is muddled as an individual contributor, you just iterate until it works. Nobody else has to interpret your intent. Management removed that escape hatch. If my team doesn’t understand what I’m after, I can’t quietly fix it myself. I have to actually get better at sharing the why, not just the what.

And that forced improvement surprised me by showing up everywhere else. It changed how I write, specifically. Running a content team while also writing a newsletter means I’m constantly testing whether I can articulate what I actually mean, not just what sounds right in my head. A year ago I would have drafted something, felt good about it, and moved on. Now I catch myself asking: would someone else know what to do with this? That question didn’t exist for me before management put it there.

Goals vs. tasks

There’s a distinction I think about constantly now that I never had language for as an IC: the difference between giving someone a task and sharing a goal.

Theo from t3.gg recently shared an example that captures this perfectly. He was testing whether an AI coding agent could build a competitive chess engine from scratch. His prompt: “Build a program with no dependencies that can beat Stockfish level 17.” Straightforward. The model worked for 30 minutes and came back with something that won consistently. But when he looked at what it actually built, the agent had downloaded Stockfish and used it to play against itself. Task completed. Goal completely missed.

Once he reframed the prompt to specify intent (”build your own chess engine from scratch, the goal is to evaluate whether you can implement an engine that competes”), the model understood. The difference wasn’t complexity. It was clarity about what success actually meant.

That content project I mentioned earlier? Same dynamic. When I almost handed over the blueprint instead of the goal, I was about to do exactly what that prompt did: describe implementation instead of intent. In both cases, with people and with AI, the fix is the same: share what you’re trying to achieve and why, then trust the other side to find the path.

That self-correction loop is a management skill. Noticing when the output is wrong and asking what you could have communicated differently, instead of just blaming the execution. And right now it’s becoming increasingly relevant beyond management. Every developer is increasingly managing AI agents. The better you are at articulating intent and separating the goal from the implementation path, the better those agents perform. I didn’t expect that when I made the switch. But it’s one of the things I value most about it.

The part nobody prepares you for

The skills are one thing. The identity shift is another.

My situation was a bit unusual. I became the manager of people I’d been working alongside, some of them on the same team. These were colleagues I had close relationships with. We’d shared frustrations, swapped opinions, been peers in every sense of the word.

That changes when you become their manager. Not because you want it to, but because the role creates lines that didn’t exist before. Conversations you used to be part of are now conversations you should probably step back from. Dynamics shift in ways that are subtle but real. And if you’re anything like me, you don’t love hierarchy. You resist it. I still do the work. I write. I do social listening. I show up as a team member as much as a leader, because that’s the only version of this role I’m interested in doing.

But I’d be dishonest if I said the transition was seamless. I’ve already had to make one of the hardest decisions a manager faces, and it changed how I carry the role. There’s a weight to it now that I didn’t fully appreciate from the outside. The relationships haven’t broken, but they’ve evolved. Navigating that, being someone your team trusts enough to follow while staying close enough to the work that you’re not manag