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.