This conversation happens across every engineering org, eventually. One of my managers comes to me — sometimes directly, sometimes as a way of thinking out loud — and the question underneath everything is: my best engineer wants to try management. What do I tell them?
I always ask first how the manager is thinking about it, because their instinct tells me something. Some are quietly relieved — the engineer is expressing ambition, this feels like a good sign, let’s figure out the path forward. Others are quietly worried about losing their best technical contributor and are looking for permission to defer the question. Neither instinct, on its own, leads to a good answer for the engineer.
What I’ve found is that the conversation most managers have with engineers who want to move into management is too short and too encouraging. Not because they mean to shortchange the person — they usually want to help — but because having the real version of this conversation requires saying something most leadership conversations avoid: management will take things from you that you may not expect, and not all of them come back.
This was earlier in my career, when I was still managing engineers directly. I managed a senior engineer at Capital One — technically excellent, about eight years as an individual contributor and genuinely good at it. He came to me and said he wanted to try management. I thought carefully about what to tell him, and I decided to be direct about what I actually knew, rather than just encouraging him.
I told him that the first thing management would take from him was time with code. Not forever, and not entirely, but the deep focus work — the hours in a problem, the satisfaction of writing something clean and shipping it — that would shrink considerably. He said he understood that. Most people say that. But understanding it intellectually and experiencing it are different things, and I wanted him to know I wasn’t going to dress it up.
He made the transition, and he became a strong manager. But the transition period was harder than he’d expected — what surprised him most wasn’t the meetings or the administrative overhead, but how much his self-concept had been tied to being technically excellent. When he stopped being the person with the answers, when he was responsible for people who knew things he didn’t, there was a real period of disorientation. He would have benefited from hearing the warning more explicitly before he went in.
Now, when my managers come to me with this question about their engineers, I tell them to separate two questions the engineer is often conflating. The first is: does this person want more impact and influence? Because that’s often achievable as a senior IC — as a staff or principal engineer, someone’s reach can be enormous without managing anyone. If the engineer’s real answer is impact and influence, management is one path but not the only one.
The second question is: does this person actually want to be responsible for people? That’s a different thing. It means caring about someone’s career trajectory the way a good mentor cares, and doing that for five or eight or ten people simultaneously, not just when it’s convenient. It means that your satisfaction at work becomes partly a function of their satisfaction and growth. Some engineers find that genuinely energising. Others find it draining in ways they didn’t anticipate.
The one thing I tell my managers not to do is let their team’s needs shape the answer. If your best engineer would thrive as a manager and wants to try it, help them do it — even if losing them as an IC is painful in the short term. That’s the job: developing people, not optimising for your team’s immediate technical capacity. That calculus looks different when you’re thinking across multiple teams and a longer time horizon, but the principle holds at every level of leadership.
If the engineer isn’t sure, the best thing I’ve found is to give them a real taste before you make permanent reporting line changes — but it has to be the right kind of taste. Coordination and mentoring don’t qualify; a strong senior engineer is already doing both. The things that reveal whether management is right for someone are the things that cross into accountability for people outcomes. Have them own the onboarding of a new hire from start to finish — not just the technical ramp-up, but the whole arc of getting that person productive and confident. Ask them to draft a performance assessment for a teammate, with you reviewing it together after. Put them in a cross-team alignment meeting where they have to represent their team’s position and make tradeoffs without you in the room. Those situations surface the gap between wanting influence and being comfortable with the weight that comes with it.
The leap from engineer to manager is real, and it’s worth describing honestly. The people who make it well are usually the ones whose manager described the leap honestly before they took it — that’s the conversation worth having.