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

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
5
down vote

favorite

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.

edited Jan 22 '16 at 14:53

asked Jan 21 '16 at 10:18

Monikka

1285

suggest improvementsÂ |Â

up vote
5
down vote

favorite

Background :

Question :

edited Jan 22 '16 at 14:53

asked Jan 21 '16 at 10:18

Monikka

1285

suggest improvementsÂ |Â

up vote
5
down vote

favorite

Background :

Question :

edited Jan 22 '16 at 14:53

asked Jan 21 '16 at 10:18

Monikka

1285

Background :

Question :

edited Jan 22 '16 at 14:53

asked Jan 21 '16 at 10:18

Monikka

1285

edited Jan 22 '16 at 14:53

asked Jan 21 '16 at 10:18

Monikka

1285

asked Jan 21 '16 at 10:18

Monikka

1285

asked Jan 21 '16 at 10:18

Monikka

1285

suggest improvementsÂ |Â

3 Answers
3

active

oldest

votes

up vote
5
down vote

accepted

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.

edited Jan 21 '16 at 13:01

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

suggest improvementsÂ |Â

up vote
4
down vote

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.

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

3

I would add, that you don't fix anything yourself, you send it back to him to fix after the review. People don't get better when they don't have to do the fix themselves. Just keep rejecting the code until it is right. In our office, it can't go to QA until the Code reviewer passes the code for 100% of our code. Suggest you implement the same.
â€“Â HLGEM
Jan 21 '16 at 15:18

This goes along with the advice to let never let someone close a support ticket if the problem re-occurs, even if months later. People are rewarded, often explicitly, for closing tickets and knocking items off a to-do list. Don't put the item back on as a new ticket/backlog item. "Fix it" isn't a new item. That aligns the metrics with the behavior and with the perception of performance.
â€“Â jimm101
Feb 4 '16 at 14:41

suggest improvementsÂ |Â

up vote
1
down vote

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.

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

suggest improvementsÂ |Â

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f60841%2fhow-to-provide-constructive-feedback-on-a-colleague-to-the-manager%23new-answer', 'question_page');

);

Post as a guest

Name

StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);

)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();

);
);

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

up vote
5
down vote

accepted

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.

edited Jan 21 '16 at 13:01

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

suggest improvementsÂ |Â

up vote
5
down vote

accepted

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.

edited Jan 21 '16 at 13:01

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

suggest improvementsÂ |Â

up vote
5
down vote

accepted

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.

edited Jan 21 '16 at 13:01

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

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.

edited Jan 21 '16 at 13:01

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

edited Jan 21 '16 at 13:01

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

answered Jan 21 '16 at 12:22

jimm101

11.6k72753

suggest improvementsÂ |Â

up vote
4
down vote

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

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.

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

3

I would add, that you don't fix anything yourself, you send it back to him to fix after the review. People don't get better when they don't have to do the fix themselves. Just keep rejecting the code until it is right. In our office, it can't go to QA until the Code reviewer passes the code for 100% of our code. Suggest you implement the same.
â€“Â HLGEM
Jan 21 '16 at 15:18

This goes along with the advice to let never let someone close a support ticket if the problem re-occurs, even if months later. People are rewarded, often explicitly, for closing tickets and knocking items off a to-do list. Don't put the item back on as a new ticket/backlog item. "Fix it" isn't a new item. That aligns the metrics with the behavior and with the perception of performance.
â€“Â jimm101
Feb 4 '16 at 14:41

suggest improvementsÂ |Â

up vote
4
down vote

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

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.

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

3

I would add, that you don't fix anything yourself, you send it back to him to fix after the review. People don't get better when they don't have to do the fix themselves. Just keep rejecting the code until it is right. In our office, it can't go to QA until the Code reviewer passes the code for 100% of our code. Suggest you implement the same.
â€“Â HLGEM
Jan 21 '16 at 15:18

This goes along with the advice to let never let someone close a support ticket if the problem re-occurs, even if months later. People are rewarded, often explicitly, for closing tickets and knocking items off a to-do list. Don't put the item back on as a new ticket/backlog item. "Fix it" isn't a new item. That aligns the metrics with the behavior and with the perception of performance.
â€“Â jimm101
Feb 4 '16 at 14:41

suggest improvementsÂ |Â

up vote
4
down vote

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

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.

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

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

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.

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

answered Jan 21 '16 at 12:52

Kate Gregory

104k40230331

3

I would add, that you don't fix anything yourself, you send it back to him to fix after the review. People don't get better when they don't have to do the fix themselves. Just keep rejecting the code until it is right. In our office, it can't go to QA until the Code reviewer passes the code for 100% of our code. Suggest you implement the same.
â€“Â HLGEM
Jan 21 '16 at 15:18

This goes along with the advice to let never let someone close a support ticket if the problem re-occurs, even if months later. People are rewarded, often explicitly, for closing tickets and knocking items off a to-do list. Don't put the item back on as a new ticket/backlog item. "Fix it" isn't a new item. That aligns the metrics with the behavior and with the perception of performance.
â€“Â jimm101
Feb 4 '16 at 14:41

suggest improvementsÂ |Â

3

I would add, that you don't fix anything yourself, you send it back to him to fix after the review. People don't get better when they don't have to do the fix themselves. Just keep rejecting the code until it is right. In our office, it can't go to QA until the Code reviewer passes the code for 100% of our code. Suggest you implement the same.
â€“Â HLGEM
Jan 21 '16 at 15:18

This goes along with the advice to let never let someone close a support ticket if the problem re-occurs, even if months later. People are rewarded, often explicitly, for closing tickets and knocking items off a to-do list. Don't put the item back on as a new ticket/backlog item. "Fix it" isn't a new item. That aligns the metrics with the behavior and with the perception of performance.
â€“Â jimm101
Feb 4 '16 at 14:41

I would add, that you don't fix anything yourself, you send it back to him to fix after the review. People don't get better when they don't have to do the fix themselves. Just keep rejecting the code until it is right. In our office, it can't go to QA until the Code reviewer passes the code for 100% of our code. Suggest you implement the same.
â€“Â HLGEM
Jan 21 '16 at 15:18

This goes along with the advice to let never let someone close a support ticket if the problem re-occurs, even if months later. People are rewarded, often explicitly, for closing tickets and knocking items off a to-do list. Don't put the item back on as a new ticket/backlog item. "Fix it" isn't a new item. That aligns the metrics with the behavior and with the perception of performance.
â€“Â jimm101
Feb 4 '16 at 14:41

suggest improvementsÂ |Â

up vote
1
down vote

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.

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

suggest improvementsÂ |Â

up vote
1
down vote

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.

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

suggest improvementsÂ |Â

up vote
1
down vote

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.

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

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.

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

answered Jan 21 '16 at 10:54

Kilisi

94.7k50216376

suggest improvementsÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky