How to provide constructive feedback on a colleague to the manager?

Question

Background :

I work as a senior engineer in a software project (~3 years old). Recently, a new engineer was added to work with me for a couple of months to help resolve some of the issues (bug fixes) and enhance the tool. This addition was because of the work load and a schedule rush.

While I was happy to train him and help him come up to speed, I see that he is rushing into doing things to wind up his tasks quickly at the expense of compromising our work quality. Given the state of our project, I prefer permanent solutions to workarounds, good, formatted, refactored code to temporary code patches as I will have to deal with the incurred technical debt later. Though, he is good in trouble shooting issues, I believe not enough time is being spent in learning the tool features (high level) and comprehending existing code.

I informally review his code changes and at most times, find that they require more effort or optimization before his tasks can be considered complete. (the review comments, rework done etc., are not documented, hence my leads are not aware of the extra work that I have to put in to close his tasks).

Question :

My manager seems to be very pleased by the fact that he is completing more tasks despite being new to the team but I think code quality and not the number of tasks, is a valid metric to measure a developer's work. I am trying to train him in building code correctly. I have asked him not to rush and to improve his work quality but I don't see much improvement. How can I communicate this to my management as a feedback without sounding as 'a jerk who is jealous of the new team member's performance'?

EDIT : He is not faster than me. As he is new (learning phase), he is being assigned simpler tasks while I work on critical, complex tasks. So it is not the case where I feel threatened. But I am concerned that he is not using this time period effectively to learn things as he seems focused on claiming completion. This would become a problem to me when he gets assigned bigger or complex tasks soon as I wouldn't be able to accommodate helping him with his tasks in my schedule.

Answer 1

This is unfortunately an issue of job portrayal. The best way to get substandard work is to advertise that the position is a stopgap to deal with a temporary situation. As a start, I'd clarify that the emergency stage is over. He's still going to be working some issues on the team, and that gives everyone the opportunity to start following some standard best practices from here on out, so the emergency situation doesn't arise again. This does a lot of work--it acknowledges his contributions while making it clear that the work was substandard, while allowing him to save face for having a perfectly valid reason to do shoddy work. It also places the blame for the emergency on shoddy work he didn't do. This will all establish that moving forward things are different and allow him to reset. Most importantly, it gives you the opportunity to mentor him on building code correctly.

If you can do this without speaking with his boss, that's great. If you do need to bring him in the loop, I'd give the same narrative to the boss.

Don't overreact to a perception that you're being devalued due to his performance. Then you're giving credit to the idea. It's normal in all parts of the organization to get rock stars who can do wonderful things until the whole project blows up because of work quality. Take the leadership role here and it's likely everyone will simply let you have it.

Answer 2

Here is your problem:

review comments, rework done etc., are not documented, hence my leads are not aware of the extra work I have to put in to close his tasks

Fix that. You probably didn't think it was going to be a continuing thing. If you're using work items, and he checks in against the work item, do your checkins against the same one. Consider using a code review tool that creates some sort of artifact of what needs to be done (a plain text document in which you write notes, if nothing else. Or if you make the changes, a diff showing what you had to to do.) If you can, instead of fixing the problems, assign him the task of fixing them. (Probably that is the only approach that might get him to do it right the first time.)

Keeping track of the rework and cleanup you do will give you a chance to see if there is any improvement over time. Maybe at first you had to make changes to 100% of his "completed" work. But now it's 75%. While that's frustrating, it's an improvement.

Then if you want to go to your boss, you have data. "I have to edit over 80% of his work to clean up technical debt - I'm not talking about formatting or commenting either, I mean not validating the parameters that are passed, no error handling, not considering the possibility someone might cancel a transaction, and so on. It was 100% at first and I've discussed every one of my changes with him and asked him to do a more complete job, but I've seen only this marginal improvement." Then you pass over your summary of what you've had to clean up. Then you pause and say "I know on the surface it looks like he's super fast compared to me, but that's because he whips through the easy part doing a careless job, plus I am spending time fixing all this. Like I said, I've shown him all this and asked him to write code that meets our standard, but I've had no effect." Then, you pause. Ideally you don't need to carry on and say "can you talk to him about it?" But if your boss just shrugs when you pause, then ask directly.

Important aspects of this approach:

• it is data backed
• it is about you - "I have to fix a,b, and c most times he says a task is done"
• it's factual - don't say "Every" if it's "Most"
• it explicitly acknowledges that the new guy looks faster than you, and explains why that's not true
• it asks the boss to do something specific (if the boss doesn't spontaneously volunteer to do it)

What it does not do is just go to the boss and randomly whine about the new guy. "It's not fair" and "he's not as great as you think" are dangerous phrases, even when they're true.

Answer 3

If you have no actual authority over him then when approaching the manager I would give both his good and bad points. Starting with the good. He is a good troubleshooter, he gets things done quickly.

Then I would move on to the bad points, his work is a bit sloppy and he's not producing code of a high enough standard in such and such an area.

This is the best approach in my experience. It gives a solid truthful estimation of how things can be improved rather than a rant because he's not indenting his code properly.