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 managing from a distance, is a balance I’m still figuring out.

Nobody talks about this part when they debate the IC-versus-manager decision. The articles focus on ladders and compensation and market demand. But the actual lived experience of management is more personal than any of that. It’s about who you become when the job stops being about your output and starts being about everyone else’s.

What about the practical concerns?

None of that personal growth erases the practical reality. And the practical arguments against management right now are real.

Companies are flattening. The path from EM to Director is more competitive than it was five years ago, with fewer Senior EM roles to bridge the gap. And Staff engineers often earn more than first-time EMs when you compare across companies. Zaides mentions his friend could have made 20-30% more staying IC and switching companies. That’s a real number. I knew when I made the switch that I wasn’t optimizing for compensation. I made the move anyway because I believed what I’d gain in skills and perspective would be worth more over time than the salary delta.

But those arguments assume management is a permanent track. Most people I’ve seen do it well don’t treat it that way. They step in, build the skills, and then decide what they want next with far better information than they had before. Some stay and grow into leadership. Some go back to IC work and find themselves significantly more effective for having done it.

That’s because management develops instincts that pure IC work never forces you to build: how to align across teams, how to communicate with stakeholders who don’t share your context, how to evaluate competing priorities when there’s no obvious right answer. A former manager returning to an IC role isn’t starting over. They’re bringing tools most ICs never pick up. And they’re starting their next negotiation from a higher basis point.

Then there’s the advice to wait a couple of years until things settle. I understand the impulse. But the industry isn’t going to pause and send you a signal when it’s safe to switch. Waiting means spending two more years building one type of skill while the set of skills management develops sits untouched. And from what I can see, the skills that management forces you to build are the ones with the rising premium right now.

Take the opportunity

I didn’t have a five-year plan that said “become a manager.” An opportunity appeared that aligned with something I’d been thinking about for a while. I wasn’t ready. I pitched myself anyway.

Conviction but not credentials. That’s what I walked into that conversation with. And it turned out to be enough, not because I was secretly qualified, but because the willingness to learn the parts I didn’t know mattered more than already knowing them.

If a management opportunity is in front of you, and the idea of enabling a team and getting sharper at communicating intent sounds like a genuine challenge you want to take on, take it. You won’t be great at it immediately. I wasn’t. But the things you’ll learn about describing outcomes instead of steps, about catching yourself when your instinct is to just fix it yourself, those stay with you regardless of where your career goes next.

I’m still early in this. I’m still learning how to pull back when I want to prescribe, how to trust the process when it’d be faster to just do it myself. But I’m a better communicator, a better writer, and a better collaborator than I was a year ago, and I don’t think any of that would have happened if I’d stayed on the IC track and waited for the “right time” to make the switch.

Thanks for reading!