It happened again this week.
A senior data engineer posted on Reddit asking for advice on growing beyond coding. Dozens of replies said the same thing. "Go be a manager."
Nobody asked if this person was good with people. Nobody asked if they wanted to spend their days in one-on-ones instead of editors. Nobody mentioned that the skills that make you a great engineer have almost zero overlap with the skills that make you a great engineering manager.
They just heard "I want to grow" and defaulted to the only upward path most people can picture.
I've been on both sides of this. I've been the engineer who wanted more and heard "management" as the answer. And I've spent 15 years leading teams across North America, Europe, and Asia, leading orgs as small as 3 and as large as 30, learning what management actually demands from the person doing it.
The advice isn't just lazy. It's dangerous. Because it sends capable engineers into a role they didn't choose, weren't prepared for, and will quietly fail at while everyone around them wonders what went wrong.
What Management Actually Is
Here's what nobody tells you before you take the title.
Management is being a shield. When your team succeeds, that success is theirs. When there's failure, that failure is yours. That shift alone breaks most new managers because they spent their entire career owning their wins. Now the wins belong to someone else and the losses belong to you.
It's absorbing ambiguity so your team doesn't have to. Sitting in a meeting where leadership changes the priority for the third time this quarter and walking back to your team with clarity and guidance instead of confusion.
It's making decisions with 40% of the information you want. Not because you're reckless. Because you know how to put the guardrails up. The decision doesn't have to be perfect. It has to be safe enough to move forward and reversible enough to correct when you learn more.
It's knowing when to be the person your engineers come to and when to point them to somebody else. You can't have a hero complex. You can't be everywhere. Sometimes an engineer comes to you with a problem and the right move is to send them to the person who actually has the context, even if that means they stay stuck a little longer. That's okay. They'll grow from it in ways they never would if you solved it for them.
It's the 10 PM security alert where you have to decide whether to wake up your team or handle it yourself. I've never once forwarded that alert. Not because I'm a hero. Because I've worked for leaders who did, and I watched what it did to their team's trust.
It's realizing that the thing you were best at ... building, debugging, shipping ... is no longer your job. Your job is making other people better at it. And some days that feels like watching someone else drive your car while you sit in the passenger seat trying not to grab the wheel.
The One-on-One Test
Here's the simplest filter I've found for whether someone should pursue management.
Do you like one-on-ones?
Not tolerate them. Not "I can do them if I have to." Do you actually look forward to sitting across from someone and figuring out what they need, what's blocking them, what's going on underneath the surface that they haven't said yet?
Because that's most of the job. Not the strategy. Not the architecture decisions. Not the stakeholder alignment. One-on-ones. Week after week. With every person on your team. Listening for the thing they're not saying. Asking the question they didn't expect. Following up on the conversation from two weeks ago that they assumed you forgot about.
I sit down with every person on my team and ask where they want to be in 10 years. That question, and the dozens of conversations that follow it, is where management actually lives. If that sounds energizing, you might be wired for this. If that sounds exhausting, listen to that signal.
The Chose-It Test
The best managers I've worked with chose management. They looked at the role with clear eyes, understood what they were trading, and decided the trade was worth it. They wanted to develop people more than they wanted to write code. They got more energy from watching someone else succeed than from shipping something themselves.
The worst managers I've worked with defaulted into it. They hit senior, looked around, saw management as the only path up, and took the title. They didn't choose to lead people. They chose to not stay where they were. And their teams felt the difference immediately.
The same flatness that comes from staying in a role you've outgrown can push you into the wrong next role if you're not careful. Leaving isn't the hard part. Leaving in the right direction is.
What Nobody Tells You About Year One
Most engineering managers fail in year one. Not visibly. Not in a "they got fired" way. In the quiet way where the team slowly stops trusting them and nobody can articulate why.
My year one was different because I didn't have the luxury of a slow transition. I went from IC at one company to manager at another. New org, new team, new expectations. No ramp period where I gradually took on leadership responsibilities. Day one I had people looking to me for direction and I had no idea what I was doing.
I'd led project teams before. But that was execution. Coordinating work. Making sure things shipped. Management was something else entirely. It was personal. It was sitting across from someone and realizing that the next conversation wasn't about the sprint. It was about their career, their frustration, their growth.
Two things saved me early. The first was Julie Zhuo's "The Making of a Manager." That book laid the initial foundation, especially around how to do one-on-ones the right way. I'd never had to run one-on-ones before. Suddenly they were most of my job. The second was Radical Candor, which became the framework I've built my entire management approach on. Care personally. Challenge directly. Those four words have shaped more conversations than any technical framework I've ever learned.
But here's the part that makes my path atypical. I never fully left the craft. I'm heavy on the people side. I can sit in a one-on-one and hear what someone isn't saying. But I'm also heavy on the execution side. When the site goes down at 2 AM and the team gets called in, I don't want to be the person checking in on Slack. I want to be the person in the terminal helping lead the team through it.
The best directors, senior directors, and VPs I've worked with have that same versatility. They can flex into the people conversation or the technical crisis depending on what the moment demands. The ones who can only do one or the other eventually hit a ceiling where the thing they can't do becomes the thing the role requires most.
The Paths Nobody Mentions
Here's what frustrates me most about the "just go into management" advice. It assumes management is the only way to grow beyond code. It's not even close.
Solutions architecture. You're designing systems at a higher altitude without managing humans. You're the person who sees how services connect, where the dependencies live, where the architecture will break at scale. Your impact is through design decisions, not people decisions.
Technical program management. You're the person who makes complex, multi-team initiatives actually land. You're managing the work without managing the people. Dependencies, timelines, risks, communication. Your impact is through coordination and clarity.
Product ownership. You're the bridge between engineering and the business. You're defining what gets built and why, shaping priorities, translating customer problems into technical direction. Your impact is through decisions about what's worth building, not how to build it.
Every one of these paths lets you grow beyond code without giving up your keyboard entirely. Every one of them rewards a different set of strengths. And none of them get mentioned in the Reddit thread because the tech industry has spent 30 years building a single ladder and calling it the only way up.
If you're not sure management is for you, maybe try pulling out your fingernails first. If that sounds preferable to running a Monday morning standup with eight engineers who all think the sprint plan is wrong, you have your answer.
The Real Question
The answer I landed on wasn't "management is better" or "IC is better." It was understanding what actually gives me energy.
My greatest accomplishment isn't the code I've written. It's where I've replaced myself. Every person I've developed who can now do what I used to do. That's my impact. And it's not a one-time thing. It's how healthy teams grow. Your org can only scale as far as the number of leaders you've developed. Every time you replace yourself, you create capacity for the next layer. That realization is what made management the right choice for me.
But that's me. And the mistake the Reddit commenters made, the mistake most of the industry makes, is assuming their answer is everyone's answer.
Some people are craft experts. They're the best at what they do. They can build anything. Teaching others to do it isn't where they get energy. That's not a weakness. That's clarity.
Some people are people leaders. They get more satisfaction watching someone else succeed than doing the work themselves. That's not a promotion. That's a different calling.
If someone on your team says "I want to grow," don't hand them the management ladder by default. Ask them what energizes them. Ask them what kind of impact they want to have. Ask them whether they want to build the thing or build the team that builds the thing.
The answer might be management. But if you don't ask the question, you're not giving advice. You're just pointing at the only door you know.