In our last lesson, we established the fundamental mindset shift required to move from an individual contributor to a manager. We discussed how it's a change of profession, not just a promotion, where your success is measured by the output and growth of your team, not your personal technical contributions.
Today, we will build on that foundation by exploring the common pitfalls that new engineering managers often encounter during this transition. This is a crucial topic because your strong technical background, which has been your greatest asset, can sometimes become a liability if not managed correctly. Our goal is for you to be able to recognize and describe these common traps, especially the temptation to remain overly involved in technical work, so you can navigate your new role more effectively from the start.
The Expert's Trap: Staying in the Technical Weeds
The most common pitfall for new managers promoted from a senior technical role is the failure to let go of the hands-on work. It's a natural and understandable impulse. You are confident in your technical abilities; it's the comfort zone where you've built your reputation and derived your sense of accomplishment. The new responsibilities of management can feel ambiguous and unsettling, making the predictable, concrete nature of coding or system design very appealing.
However, as we discussed, your role has changed. Your primary job is no longer to be the best engineer on the team but to make the entire team successful. Clinging to technical tasks directly undermines this new objective.
The article "The 5 Common Mistakes Of New Engineering Managers" provides an excellent analysis of this issue. Please read the first section, which lays out precisely why continuing to do too much technical work is a mistake.
The 5 Common Mistakes Of New Engineering Managers — Leadership Garden
This article from the Leadership Garden blog is a great resource for new managers. For now, we will focus on the very first mistake it identifies, which is often the most difficult to overcome.
Please read the section titled Still doing much technical work. As you read, pay close attention to the five reasons why this behavior is a bad idea—it hinders your growth, you can't do both jobs well, you block your team's growth, you become a bottleneck, and you can't scale the team.
The article makes a powerful point: "If it’s usually your code that gets them over the finish line, you’re missing the point. You aren’t providing growth and scaling for the team, you’re providing some extra value as an engineer." This perfectly captures the conflict between your old role and your new one.
In our previous lesson, we touched upon how management duties will consume your time. Let's revisit that point with more focus. The "3 Things I Wish I Knew" video explains the practical reality of how little time you will have for coding, especially as your team grows to the size you'll be managing.
3 Things I Wish I Knew Before Becoming An Engineering Manager
The presenter, a Principal Software Engineering Manager, offers a candid perspective on the time commitment of management.
Please watch the final segment of the video, where he discusses the time available for coding. Pay particular attention to the part from team size, where he explains that once your team reaches about five or six people, the time you have for coding essentially vanishes due to the demands of one-on-ones, coordination, and unplanned team issues.
The key insight here is that the choice isn't between "managing" and "coding." It's between fully committing to your management responsibilities or neglecting them in favor of coding. With a team of 3-5 people, there simply won't be enough hours in the day to do both jobs well.
From Helpful to Harmful: The Path to Micromanagement
When a manager's over-involvement in technical work goes unchecked, it can easily slide into a more destructive pattern: micromanagement. Micromanagement isn't just about being "hands-on"; it's about an excessive, detailed control over the work of others that stifles autonomy, creativity, and motivation.
Here are some common signs that a manager might be micromanaging.
Micromanagement often comes from a good place—a desire for high quality or a fear of failure. But its effects are consistently negative. To see this in action, the next video shares a powerful and memorable story about the impact of being micromanaged.
A Guide To Managing Technical Teams
In this video from the "Modern Software Engineering" channel, the presenter uses a personal story to show how micromanagement can kill initiative.
Please watch the section from the sailing story. Notice how the micromanagement led him to think, "somebody should tidy that rope up, but I'm not going to do it because Joe didn't tell me to." This is the exact opposite of the ownership and proactivity you want to cultivate in your team.
The story of "Joe the sailor" is a perfect illustration of how micromanaging someone who is capable of doing the work disempowers them and turns the manager into a bottleneck. As the video concludes, the goal is to focus on outcomes (Was the rope tidy?) rather than the specific mechanism (Was it tidied in your one preferred way?). As someone who has mentored junior engineers, you've likely seen that allowing people space to find their own way is essential for their learning and growth.
Other Common Traps for New Leaders
While staying too deep in the technical details is a major hurdle, there are a few other pitfalls that are closely related. A new manager's journey is often marked by an identity crisis, a new communication dynamic, and the constant challenge of delegation.
This next article, "Where New Engineering Managers Fail," offers a personal and relatable account of these challenges, along with practical ways to overcome them.
Where New Engineering Managers Fail - by Suresh Choudhary
This blog post from "Diary of an Engineering Manager" provides a concise and honest look at three core struggles for new managers.
Please read the first three sections of the article: Not Accepting Yourself Too Much Telling Struggling to Let Go Focus on the "How I Escaped This Trap" portions, as they provide the kind of practical, actionable advice you're looking for.
Let's briefly connect these points:
- Identity Crisis: The feeling of being an "imposter" is real. You may feel uncomfortable giving direct feedback to former peers. However, as the article states, "If you don’t accept yourself in the new role, neither will the people around you." Your team needs a leader, not just a friend.
- Telling vs. Listening: As a senior engineer, you were valued for having the answers. As a manager, you are valued for asking the right questions to help your team find the answers. This shift prevents your team from disengaging and places the responsibility for problem-solving where it belongs.
- Letting Go of Tasks: This brings us full circle. Resisting the urge to do a task yourself because you can do it "better or faster" is critical. Every task you hold onto is a learning opportunity you've taken away from a team member.
These pitfalls are all interconnected, often stemming from the same root cause: the difficulty of transitioning from an expert doer to an empowering leader.
Conclusion
In this lesson, we have identified several common pitfalls for new engineering managers. The central challenge is resisting the powerful temptation to remain overly involved in the technical work that brought you success in your previous role.
Here are the key takeaways:
- Let Go of Technical Work: Your primary role is to lead, not to code. Continuing to be a primary technical contributor will hinder your own growth as a manager and stifle your team's development.
- Beware of Micromanagement: Over-involvement can quickly become micromanagement, which demotivates your team, kills initiative, and makes you a bottleneck. Focus on outcomes, not methods.
- Embrace Your New Identity: Accept your new role as a leader. This will give you the confidence to have difficult conversations, listen more than you tell, and delegate effectively.
- Delegation is Growth: Every task you delegate is an opportunity for a team member to learn and grow. Your goal is to multiply your team's impact, not just add your own.
Recognizing these traps is the first and most important step to avoiding them. Now that we have a clear idea of what not to do, our next lesson will focus on what you should be doing. We will begin to define the core responsibilities of your new role, such as planning work and conducting effective one-on-one meetings—the very activities that will fill the time you once spent on hands-on technical tasks.