5 Common Mistakes Made by New Engineering Leads

Practical advice for engineering leaders

Becoming a lead can feel quite overwhelming. You are suddenly expected to organize projects, review code, perform quarterly planning, handle interpersonal conflicts, provide feedback, plan career growth, create offsite content, make a vision, schedule retrospectives, fire people, hire people, rotate people, keep on top of support, hold reading groups, and be responsible for what feels like everything. The first six months tend to involve a lot of flailing and overcorrecting.

You will make mistakes when growing into this new role, but that’s how you learn. Reading this post won’t make you immune to these common pitfalls, but it will help you identify destructive paths and recover quicker. Experience is the best teacher, so consider re-reading this post after a couple of years and a couple of mistakes.

When doing research for this post, I reached out to engineering leaders from C-suite down to new engineering managers, and I condensed everyone’s findings down to the following five mistakes:

1. not writing down feedback,
2. under-delegating (micromanaging),
3. over-delegating (trusting but not verifying),
4. getting tunnel vision, and
5. spending more time on low performers than on high performers.

Each of these mistakes turns into a nasty mess that takes significantly more time to clean up than if you had just done things correctly the first time. If you find yourself struggling as a lead, see if any of these five mistakes apply to you, and read on to learn what you need to do differently in the future.

If you like this post, please 👏 , subscribe, follow me, or connect on LinkedIn to let me know I’m on the right track!

Mistake #1: Not writing down feedback

My situation:

I had an employee who was underperforming by getting distracted, going down a rabbit hole, and failing to deliver their work on time. It was bad enough that I couldn’t trust them on any important projects. I was a fantastic lead and made sure that we talked about the issues in every one of our 1:1s. I was giving fresh feedback and guidance every week — what a great lead!

I finally reached a breaking point and talked to HR about exiting them. The first question they asked me was if I had a written history of the feedback and if the employee had acknowledged that this was a serious issue that needed addressing. And, of course, my response was, “Uhhh… no… but we’ve talked about it a ton.”

What proceeded was a messy situation in which HR/my lead needed to figure out if the issue was an “Elliot problem” or a “them problem.” I spent hours poring over old project plans and emails, looking for any written evidence showing that the employee and I were on the same page. All I had were some scattered notes showing project tasks getting reassigned to more reliable engineers.

Of course, it turns out that the employee and I were not on the same page. What I had thought were serious conversations were being taken as suggestions for improvement. I had softened the message to the point that it got lost. Going through the performance improvement plan and the firing was a harrowing experience for all involved, and I spent multiple sleepless nights stressing over whether I had done the right thing.

Why does this happen?

New leads are often wary about writing down feedback as they are worried that it will be taken incorrectly. In a conversation, the lead can ask questions, talk around nuance, and get on the same page faster. Drafting up the feedback afterward feels like beating a dead horse: the employee already agreed to address the feedback — why beat them down with a written email?

Only providing verbal feedback becomes the path of least resistance, making it difficult to break out of the habit. When you reach your breaking point, you’ll have nothing to show for months of poor performance except scattered project plans with red Xs. Navigating this situation takes far more time than it would have taken to write a simple email.

Maybe if you had written down the feedback, the person would have realized the seriousness of the situation and adjusted their behavior.

Solution: Write your feedback down.

It’s that simple. The dividends this pays off are huge.

• Your employees grow faster when they have a written guide on what to improve and why.
• Your annual performance reviews become much easier because you have a rich history of written feedback.
• Dealing with low performers becomes smoother, and transitions out of the company are less stressful.
• The more you write down your feedback, the easier it is to do so.

The best version of yourself would write an email to the person summarizing what you want them to improve and when you plan on following up to see if the feedback has been addressed. You make this a semi-routine part of 1:1s which becomes how you operate. Your team sees you as their catalyst for growth.

Mistake #2: Under-delegating (micromanaging)

My situation:

I’ve helped enough people step into leadership to see the pattern of micromanagement play out again and again. In one particular example, the new lead struggled with time management. They always felt this sense of pressure from decisions hanging over their head, and no matter how many 1:1s and project syncs they tried to attend, there was never enough time. Prioritizing recruiting, a strategic vision and long-term growth were well beyond them. They always kept hoping that things would be different in the future but didn’t have a clear plan on how that would happen.

My diagnosis was that they didn’t trust people enough to delegate responsibilities. They had several senior engineers ready for more growth but needed to be given a chance to own the outcome.

Why does this happen?

Most new leads get their positions because of their decision-making skills that reliably lead to good outcomes. Being a leader is about letting go and allowing others to make decisions. They must transition from watching everything to looking ahead to the future. They will no longer be in every conversation and need to learn how to be effective in a new way. Many people struggle with letting go and never properly make the internal transition.

Solution: Delegate responsibilities while ensuring that there is an accountability structure.

Delegation is one of the cores of successful leadership. If you find yourself attending too many meetings, then you need to learn how to delegate. Tying back to mistake 1, the best way to do this is with a written plan. Write down the responsibilities you want to delegate, what good looks like, and how you will hold them accountable. It is much easier for someone to meet your expectations if you write them down!

Mistake #3: Over-delegating (trusting but not verifying)

Don’t give people vague and unbounded assignments. Instead, make their responsibilities clear and their results measurable.

My situation:

I got burned by over-delegating early in my career, and it was one lesson that I internalized and kept with me. I delegated ownership of a new and exciting project to one person on my team and gave them a second engineer to develop it with. This would be their only project for six months. Every week we had a 1:1 and talked through advancements in the project, the customer feedback, and how we were building things to address it. Everything seemed fine.

Months later, I was doing a 1:1 with the second engineer, and they asked me if they could get a “second engineer” on the project, as they were feeling overwhelmed as the only developer on the project. I was baffled, as there were two engineers on this project already. They told me that the first engineer hadn’t written more than 30 lines of code over the past three months. It turned out that the project lead had been coasting for months, hoping no one would notice.

Not all situations are going to be this dramatic. A more common scenario is a new technical lead over-engineering a project as they strive to create a “perfect” architecture. They need someone to rubber duck with, and that’s where “trust-but-verify” comes in.

Why did this happen?

As a new lead, you are often told that delegation is essential to scaling. I was determined to be the best lead I could, so I was always looking for opportunities to “level my people up” by giving them increased responsibilities. I felt like I was doing great because I was running a 12-person team divided into squads with team/project leads executing on independent swimlanes. By being too hands-off, I missed that several squads were deeply in the red.

Solution: Trust, but verify (taste the soup).

Like a head chef who “tastes the soup” made by the sous chef, you can delegate responsibility to someone else but still check the final results. It might take several hours to make the soup, but only five seconds to double-check the flavor. This metaphor applies to engineering delegation.

When you delegate out team responsibilities, include a framework for accountability. How will you check in on the status and results of the project? What types of decisions should be pushed up to you for signoff? How often do you review the contributions of all the engineers assigned to the project? Will you check in with the consumer of the project?

I often use the “tasting the soup” metaphor when discussing delegation. You don’t need to read every single support ticket for your team, but you could read 1/10. You don’t need to review every pull request, but you could review one per engineer per week. Quickly checking in on all your delegated responsibilities is perfect for an “end of day Friday” task.

Mistake #4: Getting tunnel vision

My situation:

My first team was responsible for writing end-to-end testing, and I was determined to do the best job possible. I worked hard at recruiting, intern programs, onboarding, project management, and career growth. I helped build the team from five people to 40. My feedback from the QA director was that we were killing it — burning through the testing backlog faster than anyone expected. Then, in a single meeting with the new engineering director, the entire team was disbanded, and all the code was deleted.

Why did this happen?

This was the hardest lesson I have ever learned: hard work and intent do not equate to business impact. I was so focused on doing excellent work on the problem I was given that I didn’t stop to consider if I was working on the right problem. All my time investing in the engineers didn’t make the problem we worked on more important. Your primary focus must be on the longevity and success of the business. Especially in smaller startups, you can’t afford to work on the wrong problem.

Solution: Use V-style brainstorming.

Since my initial failure, I have become hyper-focused on ensuring I work on the highest-value problems. When presented with a new problem to solve or a feature to write, I use a paradigm that I call “V-style” prioritization. This framework has been instrumental in helping me to avoid working on low-value problems.

1. Initial idea: This is the initial project idea that you are considering.
2. Identify the root: Take a step back and identify your root motivation for wanting to work on this problem.
3. Explore alternatives: Given your root motivation, what are 5–10 ways you could satisfy that motivation?
4. Select max: Given a spread of options, which is the cheapest, highest-impact option?

You are training your engineering brain not to hyper-focus on your original solution but to refocus on the outcome you want to accomplish. This technique is applied everywhere, but no more prevalently than with designers. Most designers follow a practice where they create 5–10 different designs for the same UI to ensure that they aren’t becoming hyper-focused on a single design (e.g., Crazy 8’s).

Next time you are presented with a problem, try V-style brainstorming and see if the most valuable option differs from your original idea.

Mistake #5: Spending more time on low performers than on high performers

New leads see low performers as their problem to fix, and they consume a significant amount of their time trying to turn these low performers into mid-tier performers. They will talk gratefully about their highest performers, commenting, “they are so great, I barely need to spend any time on them.” This is unfortunate as you will gain much more from empowering your most motivated employees.

#1 priority: Enable your high performers.

Sometimes new leads have imposter syndrome and worry that they can’t provide much value to their high performers. This is especially true if the high performer has more experience than the lead. Remember that high performers are best at “doing” their role; you were promoted because you are the best at enabling them. Universally, the following four techniques are appreciated by all high performers.

1. Removing roadblocks: maximize the time they spend building
2. Be a rubber duck: be the whetstone that sharpens a rough idea into a compelling strategy.
3. Help with interpersonal navigation: the best builders are often poor communicators. You can help them.
4. Surround them with great people: high performers love working with high performers.

#2 priority: Prevent low performers from negatively impacting high performers.

The focus is still on the upside maximization of your best team members. Your attention to low performers should be in service of accomplishing that. The best way to enable and grow your high performers is to stack your team with the best people.

This leaves you with the following steps.

1. Put recruiting first. Always be searching for the next engineer who will accelerate your team. Don’t let your investment in poor performers outweigh your investment in replacing them.
2. Take a couple of shots at improving low performers. Every once in a while, a low performer can be converted into a high performer with the right mentorship and feedback. Everyone deserves a chance. However, don’t let that distract you from the third point –
3. Cut ties quickly once you know there is limited upside. New leads are always too slow to fire people because they give low performers dozens of chances instead of two or three.

Note that there’s a reason why “(1) put recruiting first” is higher on the list than (2) or (3). You are much less likely to cling to low performers if you have an influx of new talent. In my experience, mid-tier performers are much easier to grow into high performers than low performers are to develop into mid-tier performers. Only once or twice in my life have I seen a low performer become a high performer.

To help you with step 3, I recommend reading Chapter 3 in the book Radical Candor, which explains how to let a low performer go empathetically.

Wrap-up

All new leads go through struggles where they lean too hard in one direction and not hard enough in others and pivot from micro-managing to under-managing. I don’t believe you can entirely avoid these mistakes, but it’s essential that you learn from them. As stated in the post, I’ve found the following five issues to be the most common among new leads:

1. not writing down feedback,
2. under-delegating (micromanaging),
3. over-delegating (trusting but not verifying),
4. getting tunnel vision, and
5. spending more time on low performers than on high performers.

Being a new lead can be overwhelming, and nothing you read will instantly transform your leadership. For each leadership book I read, I usually only walk away with one or two salient points that stick with me. Hopefully, from this post, you’ve taken away a couple of points that you will use to improve your leadership style.