Similar to How to deal with a bad coworker but my case is not about behaviour but rather about incompetence.

Context: Our team is charged of designing and developping reports for the finance department.

I am wondering how to deal with all impacted stakesholders regarding this situation at work where a coworker has done a significant amount of very poor quality work and now I have to use his work to produce reports for our colleagues. That coworker is still in our team but he is not in charge of these reports anymore. The other departments are aware that the work was previously done by my coworker and that he did a poor job.

Now this is a great opportunity to show that I can greatly improve this tool but since this is a very large amount of work it will take some time and for now there are issues of formating, data integrity, the overall process and the amount of time it takes to both maintain and produce the reports.

How can I appropriately deal with this situation so that the other teams know the issues I am currently facing but cannot fix right now are not the result of my own incompetence but rather of my coworker's.

TLDR: How can I make sure that poor quality work from a coworker does not impact my reputation without going around and telling everyone he did a poor job ?

  • 4
    You said, "The other departments are aware that the work was previously done by my coworker and that he did a poor job." Any improvements made will be a positive reflection on you and you shouldn't be held responsible for the mess unless the code doesn't get fixed for a very long period of time an everyone forgets the source of the problem.
    – user8365
    Jun 24, 2014 at 12:21

4 Answers 4


Talk to your team lead. Go over the format of the reports your colleague designed, the issues with each format, the changes you want to make. Make sure that your team lead is aware that changing the format of the reports will take time. By time the meeting is over, you and the team lead should have worked out an action plan including deadlines to fix the report formats and in what way. And this action plan should include deadlines.

As long as you and the team lead agree on what is to be changed, the team lead could assign other people to work with you to fix the problem.

I would not obsess about other people not knowing that the poor quality of the work is yours. Because anyone who thinks that you did the poor quality work, only to knowledgeably go over each issue that contributes to the work being of poor quality - that individual would have to have a lively imagination :)

I suggest that you talk to the team leader ASAP. Because the buck just stopped at your desk. Discussing the poor format of the reports now, before they are actually produced, is optimal in terms of preserving your professional credibility and the good will you get as a result of having that credibilty. Don't wait until the puppy in your arms poops and stinks up the place before you start saying that the puppy is not yours.


I would encourage you to go to your team lead, ask for a private meeting, and lay out exactly what the issues are, and what impact they will have. Lay out how the issues limit your productivity and development options, and what you could do to mitigate these issues, what you could do to correct these issues, and what time requirements each option would have.

Your team lead should then take this to the project manager (privately, of course), and you should be prepared to make this presentation again to the both of them.

Then let them decide what to do.

DO NOT trash your teammate's work in front of others in your team or other groups. If your team lead and project manager are responsible, they will adjust your and others' workloads to compensate.

Eventually, everyone will figure it out, and if what you says is correct, you will have built some serious credibility up with your teammates.


Badly designed inhouse reports are fairly common in corporate IT, so don't exaggerate this problem. It's only if the reports present misleading views of their subject matter (finance in your case) that bad reports present an urgent problem. For example, an aged accounts receivables report that didn't include accounts over six months past due would seriously mislead your collections people and possibly damage your business. That would have to be fixed quickly.

On the other hand, poor presentation isn't quite such a serious problem.

Here's what you do, in conjunction with your team lead, to improve things for these users.

Announce to your users a "continuous improvement" project to make their reports more user-friendly.

Ask your users which reports are the highest priority to upgrade.

Ask for commitments from your users, in one-on-one time and possibly in meetings, to review the improved reports as you create them.

Finally, generate improved report programs one by one, starting with the highest priority reports. Review the new reports in detail with your users each reporting cycle. Keep generating the old reports as well until the users tell you the new ones are better.

This way you'll turn this situation around. You'll convert it into an opportunity to serve your users really well and give them exactly what they need.


By doing your job.

As a report writer your job is to provide an accurate document that displays the data in a manner that is understandable by your target audience. If there are bugs and problems with the original code that prevent you from doing that then report those bugs through what ever mechanism you have for doing so. If the problem is that the data is inaccurate again that is a bug and should be reported through your bug tracking process.

If the problem is the structure of the data itself that is a problem for you and the DBA to deal with. You need to be able to write your report to display the data as your customer is expecting it. For a poorly designed program that may mean a lot of extra work for you. But it is your responsibility to get that report out. How to get that done is probably for your case is probably a better question for Programmers or Stack Overflow.

  • Point taken but I believe you left out of the equation the fact that I do not have enough time each month to do a complete rework of it but I still have to deliver it. It would probably need a few weeks of full-time work to make it clean and robust and I can spend about a day each month on it.
    – ApplePie
    Jun 23, 2014 at 21:58
  • 2
    I did not say do rework. I said do your job which is to generate the reports. You do not have to fix your colleagues crap to do that. Jun 24, 2014 at 2:48

You must log in to answer this question.

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