My coworker (hired 1+ years ago) has made numerous mistakes in his work, recently requiring many extra hours from both of us to fix. The mistakes are frustrating but the worst part is my coworker does not own up to them. He attempts to hide them and fix them himself, until I discover them or our customers start complaining. It makes our team look bad because we don't have a good answer for why as system is down.

I am usually tasked with overseeing the fixing of the problem, and now am supposed to review his future work as well. He has already ignored that and started hiding information from me again. We are a very small team, so his errors are putting a lot of strain on me and making me mistrustful of him.

How can I approach my coworker and tell him professionally how I feel? Or should I go straight to my boss?

  • 5
    What sort of QA/code review processes do you have? Commented Mar 13, 2017 at 21:47
  • We you found a mistake of his in the past, what happened? Was he coached on how to prevent those mistakes in the future and allowed to help fix it, or was he called on the carpet while other more "competent" people cleaned up the mess? If it was the latter, can you blame him for trying to fix stuff on his own before other people find it?
    – ColleenV
    Commented Mar 13, 2017 at 22:00
  • @DanPichelman we have a very informal review process as we are a very small team (<4 people).
    – taffy
    Commented Mar 13, 2017 at 22:22
  • 1
    I think that singling him out might be part of the problem and you might be more successful if you come together as a team so he will be less embarrassed and more likely to accept some help. Some people are just too proud to admit that they can't do it by themselves.
    – ColleenV
    Commented Mar 13, 2017 at 22:47
  • 2
    If I could answer that question I'd be a millionaire.
    – Mel Reams
    Commented Mar 14, 2017 at 1:09

4 Answers 4


Well, this is tough. Nobody is perfect, but the real problem seems to be not that he is less than perfect, but that he causes even more problems by hiding faults.

You have to first sit down with him and make it absolutely clear that mistakes can happen, but hiding mistakes creates extra work totally unnecessarily, and that is not a mistake, but it is done deliberately. And that you cannot accept that.

And the next time you discover this after your discussion, you send an email to your manager that informs him about your coworker hiding the mistake, and what the consequences were.


As a troubleshooter I often come across this. The main thing is not to let it get personal.

Document the errors, document what went in to fixing them, document client complaints. Then pass the information impartially and professionally up the line. Unless it's your role to be having a word with the chap, leave it to the person who is supposed to.

I've given people a brief heads up out of professional respect, but that's it. If they don't take it to heart, hard luck. Just make sure your own back is covered when you're discussing others shortcomings.


In these situations I try to remember that I am their teammate, and part of my job is to make the team work as efficiently as possible. You mistrust your teammate, and obviously he mistrusts you, or he wouldn't try to hide the problem. The trust needs to be repaired both ways, not just yours for him.

My recommendation is to think about what you can do to help him, which helps everyone on the team and ultimately, your clients. I would schedule a postmortem with the team to go over what happened and to work together to find some ways that the whole team can prevent these sorts of errors in the future. You've already mentioned that it makes your team look bad, so really, all four of you are responsible for the problem, not just your teammate. Surely there was something someone on the team could have done that would have caught the problem before a customer did.

When he realizes that you are more focused on making sure the team's work is correct than on blaming him or making him "own up", he may come to you for help instead of hiding his mistakes. Going to your boss just reinforces that you don't respect or trust him, so I would advise against that until you've tried to repair the relationship.

Yes, it's unfair that the team may have to take on some of his work because he's not doing it well, but which situation is better? The one where he pretends nothing is wrong and keeps making mistakes and covering them up or the one where he comes to you for help and starts learning how you and the other folks on the team avoid these sorts of mistakes? Maybe the team could use this opportunity to talk about ways the whole team could work a little more efficiently or effectively.


You didn't mention what kind of "work" you are talking about, so I'm going to assume he is a coder. You can easily make him own up by using a code repository. I'm not sure why you aren't already using one, although if you are a very small group that might be the reason.

I'd personally recommend Subversion, since it's free and well tested and easy to use. Github is also a good choice, especially if you aren't a Windows/dot net shop.

With a code repository you can see exactly when a bug was created and who created it. It won't help for past offenses, but can help going forward. It will also help when you need to fix bugs inadvertently introduced since you have the old code to go back to. It also helps you possibly prevent future problems, as you can easily see all the changes he has made in order to just eyeball them before implementing.

  • This. In small teams, especially those for which have been ongoing for years, there may no source control and very little overview of code before it is released. Coders and scripters tend to be antagonistic towards anyone trying to impose 'red tape' which is why implementing source control as a result of a system failure can be much easier. Implementing and adhering to a proper change control process can help too. ITIL can be a good place to start.
    – Underverse
    Commented Jan 8, 2018 at 1:45

You must log in to answer this question.

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