How do I provide clear goals for a PIP when the developer's mistakes are ambiguous and varied?

Question

Context: I recently joined a software development company as a manager where previously my team of developers did not have a formal manager. The oversight given to the developers was unsupportive at best, and a number of performance issues and interpersonal conflicts have arisen in some of my developers.

I have identified that one of my developers is underperforming, and the mistakes they make are taking significant time from other developers to identify and correct. Worse, it is creating a hostile work environment, with multiple developers coming to me privately to express clear frustration or downright anger at the impact these mistakes are having. The feedback I have received is that the senior developer is regularly making small mistakes that would be expected of a junior developer. Or that they are being "lazy" about checking for mistakes. They don't seem to be making the same mistakes over and over, but they are regularly making mistakes in excess of the rest of the team. Senior company management that has not been hands on seems to agree with this assessment.

The mistakes this developer are making are real, and have significant consequences, but many mistakes are seemingly minor. It is my hope that their behavior and mistakes can be corrected if given some real hands-on management and guidance. To do this, I want to follow the best practices of an effective Performance Improvement Plan. To do this I need to give the developer clear and measurable goals to achieve. As I try to define these objectives, I'm finding myself coming up with objectives that could be summed up as "stop making small mistakes" or "make smarter design decisions" - these goals are not clear, and there are not specific actions the developer can immediately take to begin improving.

I can give the developer examples of specific issues that have happened that are now resolved. But as they've expressed to me, these issues are resolved in their mind, and there is no specific action they need to take. Indeed, the same problems are not occurring repeatedly, it's just a lot of different mistakes.

For large impact mistakes, I have identified that some of the problems could have had a lessened impact if there were better processes in place. For instance, when given a small/simple feature that may take a few weeks to implement, a technical design doc could be written in which the developer explains their approach. This would give the tech lead a chance to identify fundamental problems to the approach before days or weeks are spent implementing the flawed approach. But this does not actually address the underlying issue that the senior developer familiar with the codebase is making a flawed approach from the start.

Other more minor issues are things like not properly merging git branches and causing code to be overwritten until other developers find the missing code, track down where it went, and correct the mistake. The goal I can give here is to "ensure that git branches are properly merged using the process documented on our wiki". Again, this goal boils down to "stop making mistakes" - they need to learn and grow, not just stop making mistakes.

I want to help this developer, not fire them. This is not a case of building evidence against them, it is finding ways to support them.

Answer 1

Everybody can make mistakes. You need processes to stop those mistakes causing problems for other team members.

Apart from the obvious thing of taking more care, there's

• Using checklists for procedures that are easy to get wrong.
• Using tools that reduce your the chance of getting it wrong.
• Peer reviewing things before they are committed.
• Testing software before it's committed.

Put better processes in place, then assess this developer against whether or not they are following them.

Answer 2

The key sentence in your description is:

Worse, it is creating a hostile work environment, with multiple developers coming to me privately to express clear frustration or downright anger at the impact these mistakes are having.

Effectively the other staff are saying to you "you are the manager, so do your job, and fix this situation".

What to do? You also say:

I want to help this developer, not fire them

As a manager, you have to accept that this person's poor work is your responsibility, and sometimes staff won't allow themselves to be helped. Obviously, firing them is a last resort, but you have to make clear that their performance is unacceptable, and they are taking a path that could ultimately lead to their dismissal, if their work doesn't improve.

So I think you need to have a serious chat with this employee, and say it straight: you are not happy with their work, and give some specific examples. You may or may not choose to mention that the other staff are unhappy at clearing up the mistakes; on the one hand, it shows that you aren't the only person who is unhappy, but on the other hand it could make the relationship between this staff member and their co-workers much worse, so it is difficult to say what the correct approach would be.

Of course, the staff member will probably push back against the criticism, and give all sorts of reasons why it isn't their fault, but you have to stand by your judgement; their work output is your responsibility, so you must decide whether it is of an acceptable standard or not - and you have to grasp this nettle, otherwise the other team-members may start looking for jobs elsewhere, which would make the situation much worse.

Answer 3

Reflect/assign all the corrections for the deficient work back to the developer - i.e. if they lose some code, they need to go find it, not the developer who discovers the problem.

The work items/stories/defects/etc. are assigned to them until the work is unblocked. And the master story is marked blocked by their work item - or some similar process. This makes it clearly visible they are the cause of the delay. (And this is repeated as necessary if the subsequent work is not done right, too.)

This will do a few things:

1. Surface the problem in very clear and concrete terms for the offending dev;
2. Quantify the cost/impact of the errors;
3. Reduce the stress/impact on those being blocked and doing the extra work because of the ineffective dev's incompetence;
4. Make it clear/obvious to the compensating devs that management understands the issue is not them and their jobs are not on the line;
5. Allow for very clear and measurable metrics for their poor performance.

This last one is where you can get quantifiable metrics for a PIP. You could measure the number of items/features they block; the # of stories they have to take over; or you could re-open the original ones and measure the # of those; could measure delays they cause to the schedule; or - whatever (you know your business and I don't.)

BTW, I assume it really does not need to be said (but I will anyway), you should not reduce their other assignments, either (unless you want to use that as a metric). They need to understand the cost of getting it all done, because someone is doing it.

Answer 4

A senior developer making inconsistent, junior-level mistakes sounds like a developer who is not paying very much attention. They not engaged with the work/product as much as they should be, and they’re mailing it in/getting sloppy. In all likelihood, assuming they deserved that “senior” designation once upon a time, they know it, they just don’t really care. One common cause for a developer not caring about the quality of their work is that they don’t think management cares about the quality of their work. No one has been paying much attention to this team, you say—so they’ve been able to get away with it. If no one cares that you do good work, it becomes easy to not bother producing good work.

There is therefore a strong chance that there will be improvement merely from making it clear that you have noticed the problems and care enough to see them addressed. There’s every chance that the developer knows they could do better, so just knowing that someone is checking could be enough.

One flip side to this situation may also be that the developer doesn’t feel their efforts were appreciated, e.g. even when they did good work, no one was paying attention and they weren’t receiving bonuses/raises/promotions as they felt they should. Obviously, they are now underperforming, so they have no business expecting those things, but it would be worthwhile to go into the meeting prepared to answer those kinds of complaints.

The metric I’d seek to use is just a reduction in rejected pull requests. Make it clear that the expectation is not “zero”—mistakes happen to everyone, and there are some entirely legitimate reasons why a pull request might be rejected that aren’t “mistakes” in the first place—but fewer than are currently happening. This also allows the developers’ peers a sort of say in the matter: they’re the ones judging pull requests. They get to decide if something is a clear, junior-level mistake or not. If they approve something that turns out to be a problem, then that’s not the kind of mistake that has raised these concerns and therefore not relevant to the PIP.

(It’s not necessarily clear from your question, but you do perform code reviews on PRs, right? If not, implement that straightaway. A sloppy developer can do a lot less damage with code reviews in place.)

Answer 5

WARNING: In many legislations a formal PIP has a very specific legal meaning: if the employee doesn't meet the performance metrics, they will be terminated. Hence you should NOT create a formal PIP without review and approval by your food chain, HR, and legal and make sure you understand the process, the rules and documentation requirements. That tends to be a lot of work, so I would ONLY engage in a formal PIP if everything else has failed and the chances of success are basically zero.

Back to the actual question:

1. Articulate the problem. You already did this in your question. Frequent mistakes, extra work for other people that complain about it, etc
2. Quantify the problem. Measure the amount of complaints, number of related bug fixes (in Jira for example), time spent on fixes. Invent a new task ID that people can charge time against, if you have to.
3. Baseline and benchmark: Apply the metrics to the employee and, if possible, to some peers. There ought to be a significant gap between.
4. Set a target: that target should be representative of the gap measured in step 3

There is a very significant difference between a formal PIP and regular coaching/mentoring: For a formal PIP the metrics need to be designed to convince a court or a jury. Whether they are actually useful for the employee is secondary.

In my experience chances of success depend mostly on the attitude of the employee. Technical issues are easily fixed, behavioral problems can be worked on, but basic attitude/personality is very hard to change.

Answer 6

While you are asking to help improve said dev, I don't think that's really the high impact area to focus on for you/your company. It's commendable though that you want to help. I'd focus on understanding them and their behaviour, and making them aware of the situation. Have a blameless private talk to ask how they perceive their work going, what are the obstacles they see to be more productive and healthy at their work. Then if the conversion is not directed at any of the problematic aspects you wrote about here, bring them up phrasing the aspects, not the dev, as the pain points: "I saw X went bad in Y way, do you have an idea why and how to make X less likely to happen in the future" - stuff like that. Make them feel heard, identify pain points and find ways to alleviate them.

Now what I really think needs changing to improve productivity, is accepting the fact that mistakes happen, and acting upon it.

While it seems the dev in question is making them in excess, I'd still say the grievances and inefficiencies here are on the company, not the dev. As mistakes will always happen, there must be processes to catch them (early). Stuff like incorrect merges or losing code make it sound like there's virtually no tooling and review. And that's the problem, because then for every problem someone finds, there's like three more that go undetected until they bite the business. Kick off getting processes and tooling for peer review and automation (builds and tests) in place asap.

Same goes for design, you basically already stated the solution: Make anyone write down design proposals, that then get reviewed by others. What you consider a "flawed approach" is likely just a first iteration. Probably there's aspects gotten right and problems with it, that wouldn't have been seen without making that first design iteration. That's why you make these and talk about them before going ahead. Maybe your other devs are stellar and make great designs on their own, but I'd bet their designs would be better still with a round of feedback. Again, fix the processes, don't try fixing the dev.

Answer 7

First, I see some signs here that would make me concerned that the developer is not well or struggling personally. One way to support them (and the other employees) is to make sure they can do what they need to do for their health and wellbeing. Model this yourself; it makes a difference.

Otherwise, one thing that I haven't seen mentioned yet is looking for any bright spots in the developer's performance. If they do well with client communication, documentation, QA, etc, let them focus on it for a little while. Alternatively, ask if there are any areas they would like to explore or grow into.

Once their pride has healed and work isn't just a string of failures for them, it may be easier to face this problem they have writing quality code or see that they need to transition into a different role.

Answer 8

When the problems seem "ambiguous and varied" like this, it frequently means that what you're looking at is a symptom and not actually the problem. This seems to be especially true when it comes to software development.

A useful technique that I've found is sometimes called "the 5 whys". Once you've identified what you think is the cause of the problem, ask yourself why that cause happened. Then, ask yourself why that cause happened. Continue this process and you'll arrive at the actual root cause of the problem. You might not have exactly five iterations, but that seems to be the average.

Example: your production server crashed after upgrading to last night's build.

1. The application crashed because newly-added code tried to divide by zero.
2. The code divided by zero because a variable was uninitialized.
3. The variable was uninitialized because the function that was supposed to assign a value to it returned an error, which your sub-par developer never checked for.
4. Code without proper error handling was committed to trunk because it was not flagged by any automated tests.
5. Your automated tests did not flag the problem because your sub-par developer didn't write any tests for his new code.
6. The developer was able to commit code without proper unit tests because there was no code review to catch the problem.

Now you've got to the source of the problem. Programmers tend to get 2-3 steps into the process, figure out what code needs to change, and then call it "fixed" and move on. When you investigate not only the problem but what enabled that problem to exist in the first place, you'll find the actual root cause. If the last "why" in your list is still a technical reason like items 1-4, then keep digging. Trace it back to a broken/missing process, a human behavior, or a communication breakdown.

If you follow an exercise like this for your problematic developer's mistakes, I think you'll find that these mistakes aren't actually as varied as you think they are. Underneath it all, there's a specific knowledge gap, a missing process, a lack of understanding best practices, or something similar that's driving the bulk of your problems. Once you identify what that is, your way forward will be much more clear and your chances of achieving meaningful improvement will be much higher.