One of the toughest parts of being an engineering manager is dealing with poor performance. When I started, I needed days to prepare for the hard conversations and calm down later. But over time, your skin grows thick, of course.
The story is almost always the same. When you bring someone, let’s say, an engineer, to the team, everyone is really excited. He comes across as a smart, eager developer passionate about the work. You hit it off right away during the interview and feel good about him being a great fit.
The first few months are good. The new guy takes the initiative, seems to love learning new things, and gets along great with everyone. But slowly, things start to change. At first, it’s just a deadline missed a few times. But hey, it’s software development. It’s highly unpredictable, especially given the amount of tech debt. So you don’t worry too much, and let a new developer know that you need to keep projects moving on track.
After a while, though, the missed deadlines start piling up. You try to understand why and see if there are any roadblocks you can remove as a manager, but he keeps saying he “underestimated the tasks.”Then, the tech lead tells you that the quality of the code of the new engineer turns out to be not as great, and the situation is not improving. The code he delivers is riddled with bugs. There are logical errors even though he should be familiar with the project and all the tools, given the amount of time spent reading the documentation. And when you give him bugs to fix, he drags his feet for days. Sending things back to the new guy becomes an ongoing frustration for everyone.
This situation is tearing you up. You like the new developer, who’s not that new at that point, as a person. You believe he’s capable of great work. But you realize he’s unreliable and difficult to work with, affecting the team’s performance and morale.
Impact on the Team
The truth is, you have to deal with low performers as soon as possible. The first reason is apparent — time goes by, the company pays for poor performance, and very little gets done. But what’s more important, poor performers are affecting the rest of the team, and the effects are not positive. The negative impact is even greater if you have multiple poor performers.
Over time, low performance starts to drag down team morale. People are getting frustrated having to always clean up someone else’s mistakes — they’re overwhelmed with their own tasks.
The vibe on the team suffers. People start to walk on eggshells around poor performers — they know that if you, as a manager, keep him on the team, you need him, so they try to avoid giving negative feedback.
One person’s poor performance reflects poorly on the team’s reputation when — his features are always late and buggy. And as a result, your reputation, because of your output as a manager, is the output of the team as a whole.
If this behavior continues unchecked, you might lose some amazing developers — they’ll go work in a place where everyone is a professional, and no one drags them down.
Attempts to Address Informally
As any good manager would do, the first thing you do is try to help. During one-on-ones, you start off on a positive note, talking about things he’s doing well while gently bringing up examples where he’s missing expectations. You suggest ideas to help him improve, like breaking tasks down into smaller steps.
Sometimes, you get lucky, and this informal nudging works, but in many cases, it doesn’t. My theory is that it works with self-reflective people who know about the problems but focus on something else, often happening in their personal lives. When you bring up the issues verbally, it becomes a wake-up call for them.
Unfortunately, a more common situation is when people get defensive, make excuses, blame others or the processes, refuse to take ownership of anything, insist it’s all out of their control, or change the subject altogether. Times go by, and nothing improves.
You begin to rely on good old Slack pings and interrogations. The usual response you get becomes the “I’m still working on it” response without elaborating. With each gentle nudge, the underperforming engineer shuts down or gets angry.
Eventually, you get fed up and realize that informal approaches are not working.
Putting Employee on PIP
When informal and gentle nudging fails, it’s time for serious measures. It’s better to do this sooner rather than later to reduce the damage to the team and the person you are unhappy about. I’ve seen that, in many cases, they do not even realize how serious the situation is.
The best tool to resolve this situation is a Personal Improvement Plan (PIP). The PIP outlines specific things the poor performer needs to improve to stay on the team, be it meeting deadlines, writing quality code, or staying focused in meetings. The important part of PIP is the deadline to show real improvement. Usually, it’s anywhere between 4 and 8 weeks.
I don’t want to get into too much detail on structuring PIP. You’ll find plenty of information if you ask Google or ChatGPT. Just make sure it’s short and describes current problems and a clear set of goals the employee must meet.
It’s important to say that PIP is not firing in advance, but even though it is hard, you must stress that you will let the person go if the problems aren’t resolved in a set period. Not stressing it enough is one of the most prominent mistakes managers make.
Of course, the points you make will be subjective. You will hear all sorts of excuses and blaming. The person you present the PIP to will likely disagree with you. Otherwise, he’d notice and fix these problems himself. It is your job as a manager to make the judgment — some of the pushback and the reasoning might be valid.
Beware, though, because some people are very good at talking and can persuade you that it’s not them who’s doing wrong even when it’s not true. The best tool to deal with this is to have a log of problems you brought up before, your reasoning for why they exist, and your previous attempts to fix them informally.
Meet weekly to go over the progress. Ask to bring code samples and metrics to make things as objective as possible. If there will be consistent improvement, the PIP will end and you can both move forward. But if the person still can’t or won’t get back on track, you’ll have to take further action, like demoting or letting go. PIP is the last resort, and the hope is that it will be the wake-up call.
The Hard Reality
Having tough conversations, bringing up issues people have, and letting them go if they are not resolved is the hardest part of being an engineering manager.
It’s easier to avoid confrontation by continuing to try to informally coach struggling team members. You want to believe they can improve if given enough chances. But allowing poor performance to drag on creates growing resentment among your top talent.
At some point, you have to make the call for the good of the whole team. Putting someone on a formal PIP gives clear expectations and a final opportunity to turn things around. But if that fails, as difficult as it is, you must be willing to demote or let go.
Part of leading is making the tough but necessary calls so the team can move forward. The hope is always that things won’t need to come to that.
Originally published on Medium.com