Top Mistakes of New Managers and Leads

Dev Leader Weekly 106

Aug 23, 2025

TL; DR:

You won't get it perfect, and that's okay!
Your expectations change from a pure IC role.
Join the live stream on Monday, August 25th at 7:00 PM Pacific (or watch the recording)!

The Biggest Mistakes And How to Avoid Them

Stepping into engineering management or a more formal leadership role is both exciting and intimidating. One day, you’re writing code, reviewing pull requests, and shipping features. The next day, you’re responsible for people -- their careers, growth, and ability to deliver as a team.

Of course, the details will depend on the specifics of your role... but the point is: it's going to be a different world.

It’s a tough transition, and nobody gets it perfect. In fact, my biggest growth moments came not from my successes, but from my mistakes. Today, I’ll share some of mine and the ones I see most often in new team leads and engineering managers, so you can spot them early.

Mistake #1: Ignoring Your High Performers

When I first became a manager, I thought it made sense to focus on the folks who were struggling. They needed the most support, right?

Meanwhile, my strongest engineers seemed to be crushing it on their own. So I thought:

“They don’t really need me. I’ll stay out of their way.”

In hindsight, this was a huge mistake.

Your top performers may not need help with tasks, but they absolutely benefit from:

Career guidance and sponsorship
Stretch opportunities that align with their strengths
Coaching to expand their influence
Support in mapping their goals to organizational priorities

Neglecting them risks stagnation, disengagement, or even losing them. Some of my best former reports are now directors, and I wish I had spent more time early on helping them align their growth to bigger opportunities.

Actionable Tip: Don't skip the scheduled dedicated 1:1s with your high performers. Use that time to:

Ask what excites them about their work right now
Explore what skills they want to grow
Brainstorm upcoming projects that could stretch them

Don’t wait until they come to you -- be proactive. If they are already being vocal... LISTEN!

Mistake #2: Defaulting Back to Coding

As a new manager, it feels natural to jump into the code when problems arise. After all, coding is what got you here. But if your go-to solution for every fire is:

“I’ll just fix it myself.”

…you’re becoming a bottleneck.

Management is about scalability. If only you can fix critical problems, your team is fragile. If every design decision requires your input, your team can’t move without you. That doesn’t scale.

Yes, it’s okay to roll up your sleeves during critical incidents. But if you’re doing it constantly, it means you haven’t built resilience in your team.

There's plenty of caveats for this one, and I don't want to suggest that it's wrong or bad to be coding as a manager. In fact, with a team lead position or as a manager with a smaller team, I'd absolutely expect you'd have your hands in the code base still.

The meta point here is that you do not scale your impact as a lead by coding more.

Actionable Tip: When you feel the urge to dive into the code, pause and ask:

Can I pair someone else on the team with me so they gain the context?
Is this a documentation gap we can close after the fact?
Does this signal that we need better cross-training or system ownership?
Is there a gap in skills or people? Are we spread too thin?

Treat your involvement as a signal of what to fix for next time -- not that your involvement is a bad thing.

Mistake #3: Becoming the Bottleneck

New managers often don’t realize they are slowing their team down. If you hold all the context, approvals, and decision-making power, your team stalls whenever you’re not around.

That’s not leadership. That’s fragility.

Great managers make themselves less essential in the day-to-day by:

Sharing context widely
Documenting priorities and decisions
Building a culture of autonomy and ownership
Developing other leaders on the team

It sounds counterintuitive, but your job is to work yourself out of being the single point of failure. The more resilient and independent your team becomes, the more you can focus on higher-leverage problems.

If your idea of job security is being the bottleneck, you might find that you're not getting the most out of your career.

Actionable Tip: Ask yourself: If I left for two weeks, what would break?
Then use that answer as your roadmap for knowledge sharing, documentation, or developing backup owners.

Mistake #4: Measuring Impact the Old Way

As an Individual Contributor (IC), your impact was measured by the code you shipped or the features you delivered. As a manager, your impact comes from enabling others. That shift is uncomfortable.

As a team lead, you may not have all of the same responsibilities as a manager (as I mentioned though, this will vary greatly from situation to situation). However, your impact and expectations are truly no longer measured the same way as they once were.

You might feel insecure if you don’t have commits to point to in your performance review. But the truth is:

Your code output isn't the focal point now
Your team’s effectiveness is a much greater representation of your impact
Your success comes from amplifying others

This is where many new managers stumble. They cling to coding because it’s tangible. But if you don’t let go, you rob yourself of the growth that comes with management.

Actionable Tip: Reframe your impact in terms of:

Team velocity and quality
Reduced single points of failure
Career progression of your reports
Alignment between engineering work and business outcomes

Write these down and revisit them regularly. It helps shift your mindset away from individual output.

Mistake #5: Forgetting Healthy Conflict

Strong engineering managers don’t just keep the peace -- they enable productive tension. Between product managers pushing for more and engineers pushing for sustainability, there should be back-and-forth.

If you avoid conflict entirely or let product dictate scope without pushback, you’re setting your team up for burnout. On the flip side, if engineering always says “no,” your team becomes a blocker.

And another curveball? It's not just about hyper-optimizing the most output in terms of deliverables. You need to balance that with engaging work for your team, learning opportunities, career growth opportunities... and of course, the urgency and criticality of the work.

Actionable Tip: Practice saying:

“We can deliver X in the timeframe, but Y and Z will have to move out. Is that an acceptable trade-off?”

You might find yourself having this kind of conversation more with product managers as well as your own manager too. This creates clarity, sets boundaries, and models healthy conflict.

Remember, different stakeholders may have different things that they value and are focused on driving. That's okay. Have a discussion about it instead of full-on resisting, avoiding, or full-on caving to everything.

Remember... You Won’t Get It Perfect

The reality is, you will make mistakes as a new manager. I did. Everyone does. We live to see another day. I promise!

The key is:

Reflect on those mistakes
Share them (so others learn sooner)
Adjust quickly
... repeat.

Your role isn’t about being flawless. It’s about enabling your team to thrive, even when you stumble.

So if you’re stepping into management or a more formal leadership position:

Don’t neglect your high performers
Don’t cling to coding as your only value
Don’t become the bottleneck
Redefine how you measure impact
And embrace healthy conflict

Do those things, and you’ll be far ahead of where I was when I started.

Dev Leader Weekly