When Good Engineers Become Managers: What Nobody Tells Them (And How to Help Them Succeed)
The Promotion That Seems Obvious (But Often Isn't)
Picture this scenario. A senior network engineer is exceptional. They have deep technical expertise and solve complex problems nobody else can. The team respects their knowledge, and stakeholders trust their judgment.
A management position opens up. Everyone assumes they'll get it.
They get promoted.
Six months later, they're struggling. The team is frustrated. Projects are stalling, and a star engineer is drowning in a role they weren't prepared for.
What happened?
Someone got promoted based on their technical skills into a role that requires completely different skills. Without training, without support, and without an honest conversation about what management actually involves.
This happens constantly in IT and network engineering.
The best technical people get promoted into management because it seems logical. They're the best at the work - surely they'll be the best at leading people who do the work?
Except that's not how it works.
Having been through this transition and spent time in the broader network engineering management community, patterns emerge around what happens when good engineers become managers - and more importantly, what actually helps them succeed.
Here's what those patterns look like.
Why We Promote Engineers Into Management (And Why It's Complicated)
The Logic That Gets Us Here
Why it seems obvious:
They know the technical work better than anyone
The team already respects them
They've been around longest and understand the environment
They seem like natural leaders
It's how high performance gets rewarded
The problem with this logic:
Technical excellence and leadership effectiveness are different skill sets. Sometimes they overlap, and often they don't.
What organizations are actually rewarding:
Technical skill. Deep expertise. Problem-solving ability.
What the new role actually requires:
Communication, delegation, coaching, political navigation, people management. strategic thinking and emotional intelligence.
The uncomfortable truth:
Promoting the best engineer into management often means losing the best engineer and gaining a mediocre manager. Both the individual and the organization suffer, but that doesn't mean engineers shouldn't become managers. It means organizations need to be more thoughtful about who, when, and how.
The Peter Principle in Network Engineering
The Peter Principle: People get promoted to their level of incompetence.
In network engineering, it looks like this:
Junior Engineer → Good (promoted) Network Engineer → Good (promoted) Senior Network Engineer → Excellent (promoted) Network Engineering Manager → Struggling
The skills that created success at the Senior Engineer level - deep technical expertise, problem-solving, individual contribution - don't necessarily translate to management.
But here's the nuance:
The Peter Principle isn't inevitable. With the right support, development, and honest guidance, excellent engineers can become excellent managers.
The question is whether organizations provide that support or just throw people in the deep end and hope they swim.
The transition from engineer to manager is something worth understanding deeply before making the jump, as explored in From Network Engineer to Network Engineering Manager - the skills that make a great engineer don't automatically transfer.
What Actually Happens When Engineers Become Managers
Predictable patterns emerge in this transition. Understanding them helps both the manager making the transition and the leader supporting them.
Phase 1: The Honeymoon (Months 1-2)
What it looks like:
Excitement. The team is supportive, and everyone's giving the benefit of the doubt. Problems haven't fully surfaced yet.
What's happening underneath:
The new manager is still doing technical work because it's comfortable. They haven't fully let go of their engineer identity, and they're avoiding hard management conversations because they're new.
The warning signs:
Spending more time troubleshooting than managing
Solving problems for the team instead of coaching them
Avoiding performance conversations
Treating the role like "senior engineer with a title."
Phase 2: The Reality Check (Months 2-4)
What it looks like:
The realization that management is different from what was expected. Meetings consume time, people issues are harder than technical issues, and feeling less competent than before the promotion.
What's happening:
The skills that created previous success aren't the ones needed now. The discomfort of being a beginner again sets in, and imposter syndrome kicks in hard.
The warning signs:
Frustration that "soft skills" matter as much as technical knowledge
Missing technical work and resenting management overhead
Micromanaging because delegation feels like losing control
Making decisions by technical instinct rather than team input
Phase 3: The Crisis Point (Months 4-6)
What it looks like:
This is where things can go really wrong - or really right. Either the new manager is finding their footing, or they're struggling significantly.
What goes wrong:
The team gets frustrated with micromanagement, and projects stall because everything routes through the new manager. Technical debt accumulates because it's not being managed strategically. Relationships strain.
What can go right:
Management instincts start developing, and learning to let go begins. Trust builds through consistency, and a leadership identity starts forming.
The fork in the road:
With support, new managers grow through this phase. Without it, they either fail, quit, or worse - stay and create a dysfunctional team environment.
Phase 4: Growth or Stagnation (Month 6+)
If they've gotten support and developed:
Management skills are being built while technical credibility remains intact. Finding the balance between doing and leading. Developing the team rather than just directing them.
If they haven't:
Either cynicism about management sets in ("this isn't what I signed up for"), or they revert to being a technical individual contributor with a management title - or worse, actively damage team culture.
The Mistakes They Almost Always Make
These mistakes are predictable and almost universal in the engineer-to-manager transition:
Mistake 1: Solving Problems Instead of Coaching
What it looks like:
A team member comes to their new manager with a technical problem. The manager immediately dives in and solves it, team member gets their answer and leaves. Problem solved.
Why it happens:
Technical problem-solving is the new manager's superpower. It feels good. It's satisfying, and it's what they're best at.
Why it's a problem:
The engineer didn't learn anything. They'll be back with the same type of problem next week, and the new manager becomes a crutch rather than a developer of talent. They're working IN the team instead of ON the team.
What should happen instead:
"What have you tried so far?" "What's your hypothesis about the cause?" "What resources do you have available?" "Walk me through your troubleshooting approach."
Guide them to the answer rather than providing it.
The harder reality:
Watching someone struggle through a problem you could solve in five minutes is uncomfortable. That discomfort is the job now.
Mistake 2: The "I'll Just Do It Myself" Trap
What it looks like:
A project deadline is approaching, and a team member is struggling. The new manager takes over the work because it's faster, and they know they'll do it right.
Why it happens:
Efficiency. Quality control. Impatience. The project matters, and watching it struggle is painful.
Why it's a problem:
The engineer didn't grow, and they've learned that when things get hard, the manager takes over. The manager is now doing two jobs, and the team learns to become helpless.
The hard truth:
Sometimes the team's work will be slower and less perfect. That's the price of development. Short-term pain (imperfect work) for long-term gain (capable team).
Mistake 3: Confusing Technical Leadership with People Leadership
What it looks like:
Leading every technical discussion, correcting engineers in meetings, always having the technical answer, and positioning as the "senior technical person" rather than the "people leader."
Why it happens:
Technical authority is comfortable. It's familiar. It's where confidence lives.
Why it's a problem:
Team members stop contributing ideas, engineers feel their expertise isn't valued, the new manager becomes a bottleneck, and development of the team's technical skills stagnates.
What should happen instead:
Let team members lead technical discussions. Ask questions rather than provide answers. Champion the team's ideas rather than promoting personal ones. Build the team's credibility, not just the manager's own.
Mistake 4: Avoiding Difficult Conversations
What it looks like:
A team member is underperforming. The new manager hints at the issue but never directly addresses it. Hopes the problem will resolve itself. Addresses symptoms (missed deadline) but not causes (lack of skills or effort).
Why it happens:
Engineers solve technical problems; people problems are harder and more uncomfortable, and conflict feels dangerous to relationships built over time.
Why it's a problem:
Underperformance spreads. The rest of the team notices and resents it. The underperforming engineer doesn't get the feedback they need to improve, and small problems become big problems.
What needs to happen:
"I want to talk about [specific behavior/performance issue]. I'm seeing [specific examples], and I'm concerned about [impact]. What's your perspective? Here's what I need to see going forward."
Specific and direct. Early and kind but clear.
Avoiding difficult conversations makes team problems worse over time, something connected to the burnout dynamics explored in Both Sides of the Desk: Burnout - unaddressed issues compound just like technical debt.
Mistake 5: Not Learning Management as a Discipline
What it looks like:
Staying technically current but not developing management skills. Not seeking mentorship. Not reflecting on leadership approach. Not soliciting feedback on management style.
Why it happens:
Technical learning is familiar; management learning feels soft and ambiguous.
Why it's a problem:
Early plateaus happen. The same instincts that created problems (solving vs. coaching, doing vs. delegating) never get corrected.
What should happen:
Treat management skills like technical skills. Study them deliberately, and seek feedback regularly. Find mentors who've made the transition. Reflect on what's working and what isn't.
Mistake 6: Measuring Success by Technical Output
What it looks like:
Feeling productive when doing technical work. Feeling unproductive in meetings, having 1-on-1s, or doing administrative work.
Why it happens:
Technical output is tangible. Management impact is hard to measure and often invisible.
Why it's a problem:
Management work (1-on-1s, career development conversations, team communication) gets deprioritized in favor of technical work. The team suffers from lack of management attention.
The mindset shift needed:
Your output is now your team's output. If the team delivers more, learns faster, collaborates better, and retains good people - that's management success. Even if you didn't touch a single configuration.
The Skills That Transfer (And The Ones That Don't)
What Transfers Well
Problem-solving framework:
The structured troubleshooting approach engineers develop - gather data, form hypothesis, test, iterate - applies directly to organizational problems. The process is the same even when the problems are human instead of technical.
Technical credibility:
Team members respect managers who understand the work. You can't fake this. It helps make better decisions, ask better questions, and maintain respect through technical transitions.
Attention to detail:
The precision that matters in network engineering also matters in management - in communication, in project planning, in performance management.
Systems thinking:
Engineers who understand how complex systems interact are often naturally good at understanding how organizational systems interact.
Direct communication:
Good engineers communicate clearly about technical issues. That directness (when adapted slightly for people management) translates well to management communication.
What Doesn't Transfer Without Deliberate Development
Individual contribution to team enablement:
Doing excellent work yourself is completely different from enabling others to do excellent work. This requires a fundamental mindset shift.
Technical problem-solving to human problem-solving:
People don't behave like network protocols. They're emotional, political, inconsistent. Technical troubleshooting approaches don't work on human challenges.
Execution to strategy:
Engineers execute well-defined tasks. Managers define what tasks should be executed and why. Completely different cognitive challenge.
Technical authority to organizational influence:
Technical expertise creates authority in technical discussions. Management requires influencing people across the organization without always having formal authority.
Certainty to ambiguity:
Network engineering has right answers. Management rarely does. Tolerating ambiguity and making decisions without complete information is a skill that needs deliberate development.
How to Actually Help Them Succeed
This is where most organizations fall short - identifying what goes wrong without providing a framework for what actually helps.
Before the Promotion
Have the honest conversation:
"I'm considering you for this management role. Before we discuss it, I want to make sure you understand what you're choosing. It involves less technical work and more people work. Your success metric changes completely, and the first year is genuinely hard. Is this something you want, or does it feel like the expected next step?"
Why this matters:
Not every excellent engineer wants to manage people. Some want technical advancement without people responsibility. Forcing them into management loses a great engineer AND creates a bad manager.
Discuss the dual path:
Does the organization have a technical leadership path (principal engineer, architect, technical fellow) that doesn't require managing people? If so, make that a real option - not a consolation prize.
Set expectations honestly:
"The first six months are hard, and you'll feel less competent than you did as an engineer. You'll make mistakes. You'll probably miss the technical work, and that's all expected. The question is whether you're genuinely interested in developing leadership skills or just interested in the title and compensation."
During the Transition
Provide a manager mentor:
Not just their direct manager. A peer manager or senior leader who's made the same technical-to-management transition. Someone they can talk to candidly about what they're experiencing.
Why this works:
"I felt the same way at month three" from someone who's been there, is more valuable than any management framework or book.
Regular check-ins focused on management development:
1-on-1s with a new manager shouldn't be exclusively about project status. They should include management development:
"How are your 1-on-1s going with your team?" "What people challenges are you navigating?" "Where are you struggling with delegation?" "What feedback have you gotten from your team members?"
Protect their authority:
When new managers make decisions you might have done differently, resist the urge to overrule them in front of their team. Private coaching preserves their credibility while still providing guidance.
Set management-specific performance expectations:
Performance reviews for new managers should be heavily weighted toward:
Team development and engagement
Project delivery through the team (not by the manager)
Talent development and retention
Communication and stakeholder management
NOT just technical output. If reviews remain 80% technical metrics, the wrong behaviors get reinforced.
Setting the right expectations from the beginning is critical to success, something explored in 5 Things I Wish I Knew Before Becoming a Manager - what success looks like completely changes when you become a manager.
The Conversations That Actually Help
When they're solving problems for the team:
"I noticed you jumped in and solved that issue directly. What was your thinking? What would have happened if you'd coached them through it instead?"
Not accusatory. Curious. Helping them reflect on instincts rather than criticizing actions.
When they're avoiding a difficult conversation:
"How is [situation] going? I'm noticing some signals that might need to be addressed."
Give them the opening. Help them articulate the issue. Then: "What conversation might be needed here? How would you approach it?"
When they're struggling with delegation:
"You mentioned working late on that project. What's creating the pull to handle it yourself rather than delegating?"
Help them identify the specific fear (they'll do it wrong, it's faster to do it myself, I enjoy doing it) and address that fear directly.
When they succeed at a management challenge:
"The way you handled that team situation was really effective. That's exactly what good management looks like."
Make management wins visible. New managers are used to technical wins being obvious. Management wins are often invisible without someone pointing them out.
What Not to Do
Don't rescue them from every difficult situation:
If a team member pushes back on a decision, don't immediately step in. Let them navigate it. Be available for coaching afterward, but let them manage in the moment.
Don't let them retreat into technical work:
If a new manager is spending most of their time doing individual contributor work, address it directly: "The team needs your leadership more than your technical output right now. What's driving you back into the technical work?"
Don't let them fail silently:
Some leaders take a "sink or swim" approach. If someone is visibly struggling at month four, intervene with support. Don't wait until month eight when significant damage has been done.
The Question of Reversal: When It's Not Working
Sometimes the honest answer is that management isn't the right fit - right now or possibly ever.
How to recognize this:
Six or more months in, and team dynamics are getting worse, not better
The person is visibly unhappy and clearly missing their previous role
Genuine support has been provided but management skills aren't developing
Repeatedly reverting to individual contributor behavior regardless of coaching
The conversation:
"I want to have an honest conversation about how things are going. I'm observing [specific concerns]. How are you feeling about the role? Is this what you expected? Is it what you want?"
The options:
Continue with more focused development (if there's genuine growth and commitment)
Transition to a technical leadership role (if one exists)
Return to individual contributor (if that's best for everyone)
The hard truth:
Option 3 feels like failure. It shouldn't. Some of the best engineers make mediocre managers. Recognizing that early and acting on it honestly is better for the individual, the team, and the organization.
What to avoid: keeping someone in management because of sunk cost thinking or because reversing feels embarrassing. Sunk cost fallacy in personnel decisions is expensive for everyone involved.
How to Know If Someone Is Ready
Not every good engineer should become a manager. Here's what to look for:
Green Lights
They naturally develop others:
They explain things clearly to junior team members. They share knowledge freely. They help people grow without being asked.
They think about the team, not just the task:
"How does this affect everyone else?" is a question that comes naturally to them.
They navigate organizational dynamics effectively:
They understand that stakeholders matter. They build relationships across teams. They communicate effectively with non-technical people.
They're comfortable with ambiguity:
They make decisions without perfect information. They don't need complete certainty before acting.
They explicitly want it for the right reasons:
They've expressed genuine interest in leadership and developing people - not because it's the "next step" but because they're genuinely interested in the work of management.
Yellow Lights (Address Before Promoting)
They struggle to let others do things their own way:
Strong technical opinions combined with perfectionism can make delegation extremely difficult.
They prefer technical depth over breadth:
Some engineers want to go deeper on technical topics, not broader on organizational ones. Management forces breadth.
They're conflict-averse:
Avoiding difficult conversations is extremely costly in management. This needs to be a real development area before promotion happens.
They measure themselves primarily by technical output:
If identity is tightly tied to technical contribution, the transition will be very disorienting.
Red Lights
They want the title, not the job:
Interest in management because of status or compensation, not because of genuine interest in leadership.
They don't respect people who aren't technically strong:
Management requires working effectively with people at all levels. Technical elitism makes that very hard.
They're not curious about people:
Interest in why people behave the way they do is fundamental to effective people management.
They've had consistent interpersonal conflicts:
Past behavior predicts future behavior. Unresolved interpersonal challenges don't disappear with a title change.
What This Looks Like in Practice
The engineer-to-manager transition done well looks like this:
Month 1-2: New manager is learning the environment, building relationships, still doing some technical work while beginning to shift toward people leadership. Feels somewhat uncomfortable but engaged.
Month 3-4: Clearly shifting toward management mode. Asking more questions than providing answers. Having difficult conversations even when uncomfortable. Making some mistakes but learning from them with support.
Month 5-6: Finding their leadership identity. Team is responding positively. Technical credibility intact while management credibility is building. Still learning but clearly developing.
Month 6-12: Real growth visible. Team is developing. Delivery is improving. New manager is advocating for their team, navigating organizational dynamics, and finding genuine satisfaction in the people side of the role.
The difference between this outcome and the struggling outcome:
Preparation. Honest conversation about what the role involves. Support through the difficult phases. Development focused on management skills, not just technical ones. A mentor who's been through the same transition. Performance expectations that reward management behavior, not just technical output.
The Bottom Line: It's Not Automatic
Great engineers can become great managers.
But it requires:
Honest conversation about what management actually involves before the promotion
Genuine desire to lead people, not just technical projects
Support and mentorship through the transition
Development of completely new skill sets
Patience with the discomfort of being a beginner again
Leaders who coach through mistakes instead of rescuing or abandoning
What organizations get wrong:
Promoting on technical merit alone and assuming the transition happens naturally. Providing no structured support. Measuring management performance with technical metrics. Not having the honest conversation about fit before the promotion happens.
What good looks like:
Engineers who become managers and discover they genuinely enjoy developing people. Who find that enabling a team to do excellent work is more satisfying than individual technical excellence. Who maintain technical credibility while building real people leadership skills.
For engineers considering management:
Know what you're choosing. It's a different job, not just a better job. The skills that created engineering success won't automatically transfer. But with genuine effort, deliberate development, and good support, those skills can be built.
For leaders developing new managers:
Creating conditions for success is the job. That means honest conversations before the promotion, genuine support during the transition, appropriate challenge throughout, and the courage to address it directly when something isn't working.
For organizations:
Build real technical leadership paths so management isn't the only advancement option. Invest in management development with the same seriousness as technical development. Treat the engineer-to-manager transition for what it is - a genuine career change that requires preparation, support, and ongoing development.
The best outcome is an excellent engineer who becomes an excellent manager. The worst outcome is losing a great engineer and creating a struggling manager who's miserable in the role.
The difference between those outcomes is usually the quality of preparation and support they receive.
Continue the Conversation
Related Topics:
From Network Engineer to Network Engineering Manager - Understanding the transition before making it
5 Things I Wish I Knew Before Becoming a Manager - Honest lessons from the engineer-to-manager transition
Both Sides of the Desk: Burnout - Why new managers burn out and how to prevent it
Team Development:
Inheriting Someone Else's Network - Managing what others built
Changing Culture as a New Manager - Building team culture deliberately
What I Look for When Hiring Network Engineers - Building the team you'll eventually develop
📧 Making the engineering to management transition or developing someone who is? Subscribe to my monthly newsletter for practical perspectives on technical leadership, management development, and navigating the transition from doing to leading. First Tuesday of every month. Sign up here
Have you made the transition from engineer to manager? What was hardest? What do you wish someone had told you? If you've helped someone make this transition, what worked? Share in the comments or connect with me on LinkedIn.