31

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.

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Apr 8 at 0:52

8 Answers 8

44

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.

7
  • 19
    Better processes are always good, but they will struggle to be more than a safety net for occasional errors. Low quality work from an underperforming employee is more fundamental than can be addressed by processes. Indeed, a senior employee as described in the question should be pushing to implement processes that help avoid errors made by others, not floundering in the absence of processes to rescue their own work. Apr 6 at 13:14
  • 8
    True but these checklists and processes provide clearer metrics of what they need to improve. Their improvement plan goes from "make less mistakes" to more measurable things like "don't introduce changes which break tests", "no incidents of skipping points on check list", "< 5 defects raised on any pull-requests". Indeed these are daily feedback on what they are doing wrong and what they need to improve. Apr 6 at 14:15
  • 3
    OK, and certainly automated tests that cause builds to break if they fail are an example of a good process that will help everyone, fair enough. But the risk with this proposal is that the employee will optimise only for the metrics. They break a test? What if they just delete it (yes, I've seen this done)? Everything on the check list is checked? That's a start, but what is really needed is to think about the work that's being done. How big is the checklist going to be, and will it slow down everyone else as a result? <5 defects? Well, what if there's just one really bad one, is that OK? etc. Apr 6 at 14:48
  • 5
    @BittermanAndy While I agree that some people don't get better with more process, proper code review should catch things like deleting tests for no good reason. If proper code review is happening then the devs who are doing the complaining would be able to catch the errors before they go out. Some things will always slip through but it should be significantly less. In terms of time taken, ideally checklists become habit and you do the steps as you are working and it's not noticeable. Generally the things in a checklist like this are things everyone should always be doing anyway.
    – rooby
    Apr 7 at 2:03
  • 11
    Code reviews is what I thought of when reading the question. All developers should have their code reviewed, regardless of seniority. There never comes a time that a developer doesn't "need" their code reviewed anymore. These then become measurable metrics for use in KPIs. At a minimum, how much time does it take a developer to complete each task adjusting for their expected skill level? If they have the right attitude, they will gradually become more careful about their code.
    – CJ Dennis
    Apr 7 at 4:58
27

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.

8
  • 4
    Good answer. While providing specific examples is necessary to demonstrate that there is a problem, the real problem is that their work isn't good enough. Over-focusing on specifics is a distraction. The goal is not to say "don't make any more off-by-one errors... don't make any more spelling mistakes... don't forget to check for null", which could go on forever; the goal is to say "I have noticed errors X, Y, and Z from you recently. There are too many of these errors and they form a pattern of low quality. You need to improve the quality of your work. I will help, but you need to improve." Apr 6 at 12:33
  • 6
    Note that in some jurisdictions, you can't just fire an employee because they make mistakes, you can't even vaguely threaten them. Telling them that other employeers are mad at them, could constitute "constructive dismissal" if the employee quits due to feeling stressed because of it. So in such situations, having a clear PIP is important, because it gives specific guidance on how the employee can improve. It's also in some jurisdictions, a legal requirement. We don't know what jurisdiction the OP is in, however, this answer does not answer the question posed. Apr 6 at 16:42
  • 3
    This answer does very clearly answer the question: when an employee's mistakes are varied and wide-ranging, they need to be told that their work needs to improve (at a high level, not focusing on isolated individual mistakes), or else they are on a path that could lead to dismissal. That is exactly what a PIP is and does. Nothing here says "do not use a PIP, just fire them", not unless I am greatly misunderstanding the answer. Apr 6 at 16:51
  • 4
    ...that said, I agree that telling someone "your colleagues are unhappy with your mistakes" isn't appropriate. Those colleagues are indeed implicitly telling the manager "do your job", and rightly so, but their happiness or not isn't what defines whether the employee is performing or not. Apr 6 at 16:56
  • 4
    Instead of saying "your colleagues are unhappy", focus on why ... "these mistakes cost a lot of time for the team to fix when they should be working on their own tasks"
    – Dragonel
    Apr 7 at 8:58
26

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.

5
  • 2
    I like this answer. The best way to make the impact of their mistakes clear to them, is to have them resolve it. If they only ever hear "you made a mistake, x fixed it" they won't have a clear idea of the impact. They'll just think it was a minor mistake and don't see the impact of it. If they have to spend a lot of time fixing their mistake, the impact becomes much clearer.
    – Dnomyar96
    Apr 7 at 6:02
  • This is exactly what I was going to say. There's often no impetus to change if you don't feel the cost of your actions. It's called "accountability".
    – FreeMan
    Apr 7 at 16:05
  • 1
    I wonder whether the org used to have more of a "move fast and break things" culture where a more slapdash attitude to quality was encouraged. Maybe it was even rewarded. This answer is good because it makes explicit that quality, production impact, and impact on other team members are considered important, and aren't just lip service.
    – Adam Burke
    Apr 8 at 3:37
  • 6
    This answer seems very difficult to actually enact. Figuring out who caused a problem (in order to assign them the correction task) is tantamount to figuring out which code is the source of the problem, and for many debugging problems that is 95% of the effort. The actual fix is almost always clear and quick once the exact source of the problem is known. Apr 8 at 14:45
  • @DanielWagner There isn't a perfect solution, IMO. It is true that sometimes it can be most of the work just to debug and identify the problem. But, not always. And even when it is, this still makes it obvious to the offending dev that they have caused an issue which can provide a metric which is not "ambiguous and varied" which the poster was seeking. Apr 13 at 20:15
18

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.)

4
  • 8
    An otherwise good, experienced developer making stupid mistakes could simply be a matter of time pressure, burn-out, lack of proper tools and processes (e.g. no reviews, no tests) etc.
    – Michael
    Apr 7 at 12:39
  • @Michael That’s certainly true, fair point. I read the question and the comments from peers as indicating that the environment is better than that, but (as my parenthetical started to get at) that isn’t necessarily a safe assumption. A very good answer could potentially be written about fixing the team, environment, and process before worrying about any individual performance, considering OP is new here and things have apparently been left to deteriorate for some time.
    – KRyan
    Apr 7 at 12:58
  • 2
    Sometimes, it's due to them not being good with all the tools. They might code well, but if the entire process is not built around git branches and they merge them once in a blue moon, mistakes will happen. If they are the only person who knows how to deploy a specific configuration (and also do that once in a blue moon), mistakes will happen. It may be a mixture of a structural issue (one person wearing too many hats, no code reviews, no devops nor laid out deploy procedures) and actual sloppiness.
    – Lodinn
    Apr 7 at 13:15
  • 1
    Yes, this is key. And I would add, ask the developer why he is not paying much attention. Could be he disagrees with the whole project, to being bored by not being challenged enough, or problems at home. He's a senior, he probably knows he's not paying as much attention as he used to and has a good idea on why. Apr 8 at 9:21
16

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.

9
  • 7
    A failed PIP does not place a requirement on the employer to fire the employee. Apr 6 at 16:47
  • 10
    A PIP has to recognise that the P might not I. If it does, great. If it doesn't, then what happens next must also be part of the P. Apr 6 at 16:59
  • 1
    "Baseline and benchmark: Apply the metrics to the employee and, if possible, to some peers" - that's very important. Not just show the mistakes of the developer, also show what is the expected level. Apr 7 at 5:40
  • 3
    A failed PIP could also reasonably lead to a change in job description, where the employee is reassigned to easier tasks. Identifying the areas in which the employee underperforms is useful for this; it makes it clear that the reassignment is not a form of constructive dismissal.
    – MSalters
    Apr 7 at 10:39
  • 3
    I've known 1 or 2 people who survived a pip, so the figure of "basically zero" seems too low. Apr 7 at 17:53
5

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.

1
  • 2
    +1, my first thought was that design decisions aren't things that should only be caught when weeks have already been spent. The same with merges, they should be straightforward or problems should be caught by test coverage. Undoubtedly this dev has room for improvement but it sounds like the set up is preparing them to fail. Apr 6 at 12:39
5

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.

5

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .