2

One of my colleagues that I manage keeps on making mistakes with the work that he helps me deliver.

I have tried to help him the following way:

  • Writing care user acceptance criteria
  • If he has to implement a functionality, giving him a design for how it should look. The design is done by a designer.

Despite this, he seems to be making the same mistakes over and over again, with some I am wondering why he has made the mistake i.e. a typical task would be to implement a functionality based on the mock up. When I end up reviewing his work the functionality does not look the same leading to the client being pissed off since what they had agreed to is not the same in reality. The problem is not a coding problem, but that he didn't follow the design closely. At times, to rectify the situation I have to go in and fix his code so that it looks the same, but since I am in charge of delivering the project it irritates me from doing his work.

What is the best way to handle this?

|improve this question
  • 3
    When discussing why he changed the function, did he have a explanation? Perhaps he feels he "improved" it but failed to understand that it must be done exactly as discussed. He may not even know he's doing wrong and may thing your suggestions are only that. – Dan Aug 12 '16 at 12:30
  • 1
    Wait, why is his work being presented directly to the client for them to get pissed off? Isn't there any kind of review or internal "gate" in place before it goes to the client? – Masked Man Aug 12 '16 at 17:36
  • 2
    Welcome to the planet earth. If he was perfect he would be your boss. Part of business is making effective use of defective people. – Socrates Aug 12 '16 at 18:19
  • Is this a remote worker? Because if you had him sitting next to the designer, or next to QA, instead of giving him direct access to the client (which is actually your job), you probably wouldn't be having this problem. Working remotely is hard, precisely because the feedback loop is so much longer, so instead of taking 10 seconds to correct something by taking a quick glance next to you, you probably need to run the code yourself, then send out a formal email spelling out the problem in its entirety, and then you need to wait for an answer back which may only come back on the next workday. – Stephan Branczyk Aug 14 '16 at 14:11
  • So if what I am saying is correct, until he produces quality work, you should ask him to produce a screenshot of his work and place it side by side with the actual mockup, and then have him explain what remaining work he has to do in his daily reports to you. As another possible fix, you could try hiring an intern at the same location of that developer and have him be the QA for him. QA is actually very important, but it doesn't sound like you have anyone dedicated to that role. – Stephan Branczyk Aug 14 '16 at 14:26
11

Make sure he is aware this is a serious issue.

Some of us are not so comfortable giving criticism. It's easy to avoid discussing a serious problem or downplay it. But if this is the case, it helps neither him nor you.

If you have not already, have a chat with him in which you explain that this is a serious, systematic issue. Don't just point out individual mistakes; make sure he knows that this is an ongoing pattern which is unacceptable.

This doesn't have to be all negative; you can offer him support and make it clear that you want to work together constructively so that he can achieve success. But the basic message that there is a serious problem has to be communicated. Otherwise you won't get anywhere.

Formally review his work against clear requirements.

Make sure he knows exactly what the requirements are for a task (it sounds like you have already been working on this), and also follow up with a review against requirements.

If he was supposed to implement a particular design, review his implementation against the design and note any inconsistencies. If they do not match, he has failed the review and he must go back and fix the issues.

Avoid cleaning up after him.

If at all possible, do not fix his code yourself. Instead, send it back to him to correct it.

Perhaps at some point you must do this, because it is critical to delivery. But if so, make sure this is highlighted to him as a problem.

Meet with him regularly to assess performance over time and set clear, measurable goals.

Make sure he knows what success looks like in the long term, and work with him to achieve that.

But at some point, if the problem persists, you may have to make the difficult decision that he has to be let go. If so, any ongoing measurement of his performance will support this process.

|improve this answer
  • 9
    It is important to never clean up after an incompetent. Send it back to him with comments on how to fix. Make him feel the pain of fixing. If necessary, sit with him and guide him, but never touch the keyboard. You enable an incompetent if you clean up after him. People wonder how these people stay employed, it is because others clean up their work. IT is important that he knows his job is on the line if he can;t fix this stuff and the work never improves. – HLGEM Aug 12 '16 at 13:24
  • @HLGEM - It's comments like those that make me lobby StackExchange for a "+100" button. I wish I could force a few people I've worked with to read that aloud at the start of every workday. – Wesley Long Aug 12 '16 at 15:51
  • @WesleyLong True that! – cst1992 Aug 13 '16 at 13:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.