Promoted to team lead, putting one of my teammates on PIP, help!
January 25, 2022 9:00 PM   Subscribe

I'm a software developer who just got promoted to team lead of my small team (my first real lead position). One of our developers is not performing as well as we need. What (non-suck) metrics can I use to try and get the performance I need? How can I minimize negative karma when this hasn't been managed ideally up until now?

1) The main problem is that they are a net negative in productivity on the team. They seem nice and they seem to be trying but when I started working with this developer 9 months ago they were already at the point that the team was actively avoiding giving them any critical or difficult tasks. Even with the simplest task and least amount of time pressure, stuff is either not done, badly done, or done only because other teammates essentially did the work--taking more time to try and explain it and coach this developer through doing it, vs. just doing it.

The problem with this is that I have no idea how to quantify this. None this developer's behavior is strictly bad, it's simply the extent of it and net effect. I don't know how to quantitatively differentiate between this developer (net negative) and a developer who doesn't produce much individual code but is everyone else's go-to for help and is a positive multiplier on the team.

Ideas for metrics that can help here?

2) This problem has obviously been ongoing for a long time and everyone knows about it (even people external to the team have commented), but I don't think anyone has spoken directly to this developer about it before now (including me, even though I have been on the same team for months as a peer).

I think they themselves know that they aren't as productive as the rest of the team, they do seem to visibly be trying (just--ineffectively), but given a year+ of multiple team leads simply accepting this and shuffling work so that others could do it, actually being put on a PIP may be a bit of a shock.

Also, I'm not sure if this is going to be more of a "paid interviewing plan" because I'm not sure if the developer can achieve the performance needed under any circumstances. I don't want to give them false hope, but a PIP is probably better than the other option available, which is essentially "don't let the door hit you".

And there's a pandemic.

How can I allow for the option of real hope, if it exists, while minimizing false hope? If there's no hope, I'd at least like them to understand that and take the opportunity to go interviewing.

Options for minimizing feelings of betrayal?

(I do have other, more experienced people who are going to help me with all of this, I'm not entirely going it alone, but I want some neutral advice as well.)
posted by anonymous to Work & Money (19 answers total) 9 users marked this as a favorite
 
Even with the simplest task and least amount of time pressure, stuff is either not done, badly done, or done only because other teammates essentially did the work

Before the formal PIP, why not use your new status to address all of these things? At least clearly set a new standard before you tell him he’s not meeting the standard. Not as a generality, but each specific time something comes up, that very day, say “I noticed you missed/flubbed/didn’t independently complete [specific thing.] I need you to complete/fix/learn how to independently complete [specific thing.]” Mention you’re willing to help (if that’s true), mention other resources available, let him tell you what’s up and how he plans to address it.

If this continues for a few more weeks or he screws up something really badly, then you sit down and tell him he’s been making x,y, and z serious errors and in order to be successful in the job, he needs to improve them or you’ll consider it a performance issue. Then if it continues, do the PIP.

Go straight to the PIP if this will be a waste of time. But you should be really sure it’s time to let him go. Everyone knows what a PIP means, neither of you can come back from it.
posted by kapers at 9:35 PM on January 25 [16 favorites]


One more thought, because I had to do this when I inherited a mismanaged team: I was very transparent that the standard was changing from what they were used to.

I thought they deserved to know and to be given a chance to adapt. So I would say things like “I know in the past an 8 week backlog was acceptable, but that’s not the case anymore. We need to be caught up to 3 weeks by December, which will be no problem if you do [more efficient procedure.]”
posted by kapers at 9:44 PM on January 25 [16 favorites]


It's strange to me that you said "everyone knows" the person is a low performer, but for a year+, the person was never directly told this? There will likely be (justified) feelings of betrayal/being blindsided. As a new manager, it's worth considering that a company culture that does not give direct feedback, and where people are talking critically about colleagues behind their back without giving them a chance to improve, is at least part of the problem.

I agree with kapers above that messaging about *changing* standards will be more constructive than "there was always an unspoken standard, that you violated, and no one told you, until now, so you're fired!" Communicating those standards team-wide will also help the remaining team members put the firing/PIP (if it gets to that stage) in the correct context. Otherwise, they may also wonder, "when am I going to be fired/PIPed out of the blue?"
posted by rogerroger at 9:52 PM on January 25 [20 favorites]


I haven't been in this situation, but I'm going to plug the Ask A Manager blog, from which I have gotten a ton of useful advice.
posted by elizabot at 9:54 PM on January 25 [2 favorites]


I get the sense you've overfocusing on being able to justify your expectations, when that doesn't actually matter that much - the US is generally at-will employment, blah blah, you can fire people for whatever as long as you're not being discriminatory, and you have pretty wide latitude about what expectations you set for them. However, it is really important that you be extremely clear with them about what the expectations are - what you expect them to start doing (or stop doing) and when you need them to do it by.

I would start out by having a meeting with them where you lay out what behaviors you're not seeing from them (not completing work independently, taking too long to complete features, whatever), and tell them that these are part of the expectations for their role and ask what support they need from you to get these things done. Then give them a chance to talk, and listen - see if there are extenuating circumstances or misunderstandings or whatever. Then tell them you're giving them a week to think about whether this role is a good fit for them given these expectations. Assuming they come back and say yes, then that's a good segue into a PIP to demonstrate that they can meet the expectations that you guys have agreed to. And again, the PIP doesn't have to be "writes at least 3k lines of code", it can be "completes feature X in a high-quality way, on schedule, and having written all the code themselves" and you can be the solo judge of all those qualifiers.

It is scary for other people on the team when a coworker gets fired and to some extent that's unavoidable, but if you are clear with your expectations with people who are having perf trouble, you can say the same to other people on the team: "I'm sorry things didn't work out with X, but we agreed on a set of expectations and they weren't able to meet them - I try to be clear on expectations with everyone and I will tell you if I think there's an issue just like I tell you when you're doing a good job on things".
posted by inkyz at 10:02 PM on January 25 [2 favorites]


It sounds like you (this group, maybe broader) could benefit from some more regular check-in on performance and expectations. You don't have to make a big self-eval and 360 Thing out of it.

People who are doing great should be regularly assured (in writing too) that you see that. People who have a specific weakness should be informed. And people who are overall not doing the job should for sure be communicated with, not carried and talked about. Start doing this across the board, and take it from there.

Start from today, not history, and 110% do not let any hint of "everybody thinks..." creep into your communication. I know none of that history is intentional, but dropping it all retroactively on this person would be unfair and unnecessary.
posted by away for regrooving at 10:10 PM on January 25 [13 favorites]


Before a PIP, when you talk about performance, ask them about any resources or training or changes that might help. Ask again after they've thought about it. The flip side of not having been advised they're underperforming is they've never had an open conversational door to ask for these things; they would have had to broach it with "so I'm afraid I'm bad at my job and everybody knows it..." And then listen.

If it comes to a PIP, it doesn't sound like you currently expect this person can just start doing the job you need. They're not slacking, they're trying, it just isn't working. A PIP is a lot of pain if it's just the long road to firing. If the company needs it for butt-covering process, the human thing to do on your part is communicate simultaneously 1) you'd be happy to see them successful here 2) nobody could blame them for taking a different position, either.
posted by away for regrooving at 10:40 PM on January 25 [5 favorites]


You can't put someone on a PIP when nobody in the past year has told them there is a problem. That's shitty.

As the first step, talk to them, and ask them what they need to improve their task closure rate and the quality of their code.
posted by DarlingBri at 3:18 AM on January 26 [15 favorites]


In my experience of 20+ years of success in tech, PIP is just a formality for firing someone. Exceptions exist, but once you have a PIP on your record it is a significant red flag at that company. The fact that people work around this person is enough to tell me the fit isn’t there.

Acknowledge the problem honestly, and tell them they have the PIP time to find a new job. No hope necessary. It is dreadfully easy to find a new, paying job as a developer in most western countries. Maybe it’s not the exact job they want, but there’s a chance it’s a better fit than your current place.
posted by Geckwoistmeinauto at 4:13 AM on January 26 [4 favorites]


Yeah, it shouldn't have been allowed to get to this point but here you are! To me, a PIP is just a very clear laying out of expectations and making a plan for how a worker can meet them. I know that they are used in different ways at different companies, but I think if you approach your coworker in good faith, saying, "Look, we can't go on this way - how can we fix this?" there's nothing wrong with that, and in fact it's necessary.

FOR METRICS - would it make sense to say something like, "For you to succeed in this position/for us to keep you on I need you to complete at least X tickets* independently each week/month (depending on how big your tickets are and how long tickets generally take to complete). 'Independently' doesn't mean you can't ask for help, but it does mean that I expect at least 90% of the time spent on getting the ticket to 'done'** to be your time - right now other developers are spending a lot of time working on your tickets." And then have a real talk with them about whether that seems attainable, and what tools you can provide to help them get there, and make sure they know that the level they're performing at currently is not going to be acceptable in the future.

Also I don't know if you've done any hiring lately but it is SO HARD right now to find even medium-competent developers, so if there's anything you can do to turn this person into a productive team member (even if they can't take on your most sophisticated work, can you assign them the quick bug fixes and other scutwork?) you should do it. Fixing this person will not be easy but it might well be easier than hiring and training someone new.



* or however you break up work
** or whatever your word is for when a task is out of a developer's hands - checked in, pushed, releasable, ready for QA
posted by mskyle at 4:21 AM on January 26 [5 favorites]


You are using gender-neutral pronouns to describe the developer, which is awesome if the gender of the person is completely irrelevant to the situation at hand. However, I'm just bringing it up in case this developer is a woman/femme/NB person in a cis-male dominated environment, which is not uncommon in software development. If that is the case, you would definitely want to ask them if their experience as a minority is affecting their ability to perform or learn from their peers. Same goes if there is any other difference in privilege level/background, such as ethnicity or their experience in education.
posted by guessthis at 4:48 AM on January 26 [12 favorites]


Agree with others, you need to set out very clearly what you expect them to be able to do from now on, and to what standard. Ask whether there are any barriers preventing or hampering them from meeting those expectations, and to the extent that you can or is reasonable to do so, find way to address them. In writing, confirm your expectations. You should also be clear about what will happen if they can't meet your expectations.

Then check whether they are meeting those expectations are not, and tell them either way. I would be checking this weekly. If they are meeting expectations, then excellent and keep checking in for a while until you are confident that they can meet expectations continuously without frequent checks. If they are not meeting the clear expectations, ask why not. Again, try to remove any reasonable barriers, but if it's not working out after some time then you need to either move them to another role (which can be a great solution if you can find or create one) or let them go.

This is exactly what a PIP is, when it works well. It is be a bit harsh to formally launch a PIP with no warning, but I think you should still set it up as I've outlined and state that if they don't make substantive progress you that's what you'll need to do. I would however, make sure that I had buy-in from my boss to address the performance issue. You do not want to do this and then find you are not allowed to take further action. Where I work, I would expect the process to take 6 months or more. Things will probably be quicker where you are. But, the time, effort and unpleasantness of the task are all reasons why people hope that things will improve by themselves. If they haven't by now, they won't.
posted by plonkee at 5:53 AM on January 26


First thing - any time I've had someone transferred to my team, I consider that a blank slate. It's deeply unfair IMO on both sides to start off on the PIP foot. There might be exceptions, but for the situation you describe - I think the day one conversation should be around setting goals and making it clear what is expected from someone on my team.

Your organization should have clear metrics around what a person should deliver as a developer at a certain level. So if you have, say, levels 1, 2, 3, etc. then it should be clear what's expected at each level.

So 1) I hope your organization has these metrics. If not, that's an organizational failure and management failure to this point. Not an individual failure.

Especially given 2 - if nobody has directly addressed this with the person, starting off on a PIP is bogus. So don't start there.

Start with goals. Start with what the expectation is going forward. See what they say when you tell them "this is the job, here's what we expect." Maybe they'll say "whoa, I can't deliver that." Maybe the clarity will help.

Also? You need to ask them what their blockers are and how you can help them achieve those goals.

And then - in the end - if this person just isn't cut out for the role, you tell them. You set the goals and you have regular 1:1s with them about their progress or lack thereof. Document, document, document before a PIP is in play.

I'd say, give them a their goals, give them some weeks to adjust. If they haven't improved within a quarter, then start the PIP proceedings. But "hi I'm your new manager, you're on a PIP" does not sit right with me at all.
posted by jzb at 9:01 AM on January 26 [12 favorites]


> > I'm not sure if the developer can achieve the performance needed under any circumstances.
> How can I allow for the option of real hope, if it exists, while minimizing false hope? If there's no hope,

Look, once you've decided to put the employee on a PIP, you are obligated to give them an actual chance to prove themselves. But here it sounds like you've already given up on this person and do not want them around anymore because they are not capable of doing the job. This is a situation where the employee needs to be given some severance pay and let go, not put through a charade of a PIP. Why make everyone jump through all these hoops when you know you're going to fire this person anyway - I mean it's kind to want them to have a paycheck for as long as possible, but wouldn't it be cheaper and easier and more respectful to send them away today with severance pay, instead of wasting everyone else's time and efforts trying to get this employee to do something everyone knows they can't??

But if you do insist on going through the PIP charade:

>The problem with this is that I have no idea how to quantify this.

You already have quantified it.

You said: "the team was actively avoiding giving them any critical or difficult tasks" --> you can quantify this as a goal for this employee to contribute on the same level as the rest of the team.

You said: "stuff is either not done, badly done, or done only because other teammates essentially did the work" --> you can quantify this as a goal for the employee to do all the work they take on, do all their work to the high standard set by the rest of the team, and participate in training so that they are able to perform their tasks independently.

There you go, that's four solid quantifiable goals for your employee in their performance improvement plan. Give them a reasonable amount of time to achieve these goals, probably 3 months? Make sure you provide them with the resources they need to improve, such as training (maybe put them through the new employee training programs?) and documentation (to guide them in how to do their job) and TIME for this employee to use both these resources. Out of the three months you give this employee, the first 6 weeks can have tons of extra time set aside for them during their workday for this training and step by step guidance in their work using documentation. The next six weeks you can start measuring whether they are able to increase their productivity and bring it up to the standard of the rest of the team.

And then in the end if they can't meet the standard you fire them.

> Options for minimizing feelings of betrayal?
> may be a bit of a shock


People are allowed to feel bad and shocked and betrayed. It's neither kind nor respectful to try to stop them from feeling this.
posted by MiraK at 9:23 AM on January 26 [3 favorites]


Are they failing to meet the standard that was clearly laid out for their performance, or are they just the slowest person on the team? Because ultimately, every team has a slowest person, if you fire them rather than fix the problem there will be a new slowest person.

I agree with those who say that you need to treat this as a fresh start and try to be a good manager. Why are they slow? Do they need more skills and expertise? Can you help get them those skills and expertise?
posted by corb at 11:03 AM on January 26 [5 favorites]


Read Managing to Change the World this weekend. It's written for non-profit managers but it's all about how to run high-performing teams and I think it will help a lot. It's co-written by the person who also writes the aforementioned Ask a Manager blog.

I've been in your exact situation and I know how you feel. It's both frustrating and scary. I think the best thing to do is to start out giving this person the benefit of the doubt that many of these issues were caused or worsened by bad/absent management and sort of do a reset. Some people need very clear goals and accountability and it sounds like this person may not have gotten that. So I would sit down with them and just be very clear about what you expect from them. In your weekly 1-1, set weekly goals, and check in with them about the goals you set last week.

If you notice something you want them to change, note it right away and be very clear that you want to support them in improving. For instance, if you hear they did something wrong and it needed to be redone, bring this up with them and 1. make sure they KNOW there were errors and 2. find out if they need support or training to get this right in the future.

You don't want this to be all about what they are doing wrong. Work hard to find things they are doing right, and celebrate that with them. Even if it's a small thing that you think is just part of their job. You want them to feel like they are making progress, that their boss is on their side and wants them to succeed.

Do this for 3-4 months. If you are working closely with them, meeting weekly and checking in on progress and it doesn't seem to be working, then think about a PIP. At that point, they will know what's going wrong and right, and it shouldn't be so much of a surprise. Don't feel like you CAN'T let them go - sometimes someone just isn't right for a job. But part of your job as manager is to set your team up for success, and it seems like it's worth it to give this person a shot.
posted by lunasol at 11:27 AM on January 26 [6 favorites]


Is this the sort of job where you can chunk up their work into small deliverables--things that take maybe a week? They should buy into these units as reasonable goals; ideally they'll even be volunteering how much they can do.
In some situations the very act of breaking down someone's work this way makes it seem more manageable to them and will improve performance. But it also gives you both a framework to evaluate how things are going. If they deliver, you have a baseline to coach them from; if they don't then, in theory, there's an example they can clearly understand they're underperforming on.

Also: IME people who are struggling will do a lot to blame their problem on external factors. Maybe fairly, maybe not. But either way help them by helping them clear out potential obstacles. Go over meeting loads, other tasks, etc. and make sure they can devote their time to this.

Also make sure they have an idea how to get technical help while working--who should they ask questions? In addition to yourself, pick someone else and make sure they know coaching is at least temporarily part of their job too. I've seen struggling employees think that if they can avoid admitting to you they don't know how to do parts of the job they will win somehow, and they work on that instead of working on learning.

FWIW I don't find formal training like an external class especially helpful in these situations. That's more a long term development issue. I'd certainly support any training they want, but if you have the time to make internal help available that's going to be far more valuable.

Finally, I totally agree that you don't start with a PIP. If you're going to try and see if you can coach this person up to level, there's nothing you need to do that a PIP will help with. (If the person knew how to do the job and just didn't care, a PIP might make them care; otherwise it exists primarily to document why you're firing someone and give them a chance to leave first.)
posted by mark k at 12:04 PM on January 26


There's lots of good advice here, but unless I've completely misunderstood (or your company works differently to any tech company I've ever worked at or heard of!), it's good advice for your manager and you manager's manager, not you!

You're a tech lead, not a people manager. Planning a PIP process and managing the emotions involved is simply not your responsibility. It's your manager's, who is presumably also this developer's manager. Your manager should be following a playbook for this process, and will ideally have support from their manager (and likely HR). As a lead, you will be involved in the implementation of the technical/coaching aspects of the PIP.

I think it's probably a good sign that you're thinking about this problem in your new role. It shows you care. But it's not a good idea to continue thinking about a very hard people management problem (the hardest!), any more than it's a good idea to spend your time on a very hard product management problem. You've got plenty of stuff to work on as a new lead. As a developer who knows the code, it's stuff that no one except you can do. If you do it well you will be rewarded. PIPs aren't your job.

My advice is to read the chapter about being an effective technical lead in The Manager's Path by Camille Fournier, and follow your manager's instructions about the PIP in the meantime.

p.s. if the PIP is your responsibility then you are a manager, not a lead. I hope you got a raise!
posted by caek at 10:24 PM on January 26 [4 favorites]


I agree with caek- it is weird you are expected to deal with this as a lead. The lead should be looking forward and driving the boat, not making sure each person is rowing properly. Show them how to row better, sure. Not hold them to the standard.

I also recommend you learn your company’s PIP process. You should have a witness to your PIP (like someone from HR) and they should be able to give you guidance. Again, however, that means you are a manager.

I also strongly disagree with MiraK’s PIP plan. Those aren’t goals; they are an effect. In my experience, thinking up the goals is the hardest part- harder than informing them.

Giving them general goals of “don’t ask anyone for help” means they will turn in a shitty project.

In this case, I would list out about 10-15 things that you’d expect them to be able to accomplish solo. They should be small, concrete things.
- use regex to process strings
- Use postman to verify api’s
- break down the problem into smaller components.
These would be skills that anyone on your team could complete. A typical project would hit 3- 8 of them. Each time they get a project, they have to learn one method backwards and forwards. You pick the thing. Next time, they should be able to complete it on their own, or with minor questions. Make it clear up front what is going on. You are getting them up to speed with team standards. If they have trouble after this, then they know what is up, and a PIP likely won’t be needed. Or maybe you turn them around.

You could even code pay with them for a few days a week. Try to do it where others can’t watch. Do most of it the first time, but focus on one method. Have them explain it to you. Tell them what to Google. Watch them Google it. Watch them code, and when they do weird things, correct them.

You will see very very quickly if this can be saved. If they constantly lock up, or are dismissive, then you can’t really save them. It also won’t be a surprise to them. Ideal scenario is that they are missing the last 30% and you can help them unlock their skills.
posted by Monday at 2:32 AM on January 27


« Older Who invented smiley face fries or potato smiles?   |   What are some good iOS apps for trivia? Newer »

You are not logged in, either login or create an account to post comments