Providing constructive feedback for someone who interprets it as personal criticism

Question

I am a fairly green manager of a small team of 6 software developers. In addition to managing, my responsibilities include providing technical direction, making overall architectural and implementation decisions, and some regular writing day-to-day code.

As part of our development process, we have another developer on the team review code before sending it off for QA and subsequent release. This serves as a quick sanity check, but also enables developers to share knowledge, both general and about areas of our code base they may have more experience with. Everyone on the team has said that this process is valuable, myself included.

One of our less experienced developers tends to get angry when his code is critiqued, particularly when I am reviewing it. This developer has asked for additional feedback, specifically during these code reviews. Yet when that feedback is provided, the response from the developer is anywhere from being calmly disappointed to outright anger. Usually I am calmly thanked for the feedback, only to find out a week later that this developer has been angry about that feedback without raising the issue. The most recent occurrence, the developer accused me of pointing out flaws in code as some sort of a game that I get a kick out of, claiming that the issues I called attention to were trivial. (On this latest feedback, the issues pointed out were minor in comparison to prior code reviews, where most things pointed out were critical problems. This is a good thing as the developer has been learning and improving over time. Even still, the things pointed out were unacceptable as-is and needed to be fixed prior to release.)

During code reviews, I see myself as a peer to the other developers. (In fact, we have always called them peer code reviews. Anyone on the team can review anyone else's code. While I review an awful lot of code, it's because I am often available to do so in between meetings and what not.) This developer has told me that he seems my approval of his code as mandatory, even though that is not policy and it has been said numerous times that he can have anyone on the team review his code.

This particularly developer is a bit volatile and has been known to outburst at folks from time to time. His productivity depends largely on his mood for the particular week. He takes any feedback personally, even if it is minor feedback with clear solutions provided. He has perceived complicated social situations and conspiracies between individuals in the office that to my knowledge do not exist.

I see my management role as a supporting role of the team, doing whatever I can to enable them to be successful in what they do. The situation is the same company-wide. We encourage employees to talk to whomever they want (no need to go through the "chain of command"), we provide all the training you can eat, and almost everyone is receptive to feedback, positive or negative. I look at things objectively and strive to provide clear solutions to clear problems. This developer seemingly looks at things from an interpersonal perspective and is focused on determining everyone's underlying motivations rather than focusing on the work at hand.

I hope that provides enough information to set the scene. If not, please ask for clarification. My questions:

• How can I provide feedback to this developer in a way that allows it to be perceived by this person for what it truly is... feedback, not a personal attack?
• I can certainly lower my expectations but I believe this is a disservice to the developer an the company. Am I correct on this? (No other developers on the team, past or present, have had a similar problem.)
• My manager has also worked to deal with this developer directly and hasn't been able to offer much advice. He has told me to spend the majority of my time on my best employees. While I think this advice applies, I truly want to help this one developer as I believe he is capable of good work if he had a different perspective. I understand that it's hard to get the whole picture from this post, but is the situation hopeless? Should I lower expectations for this one developer, do the bare minimum for him, and spend more time mentoring other developers?

Answer 1

As always, interaction with individuals will vary based on the individual and you. I'm providing suggestions based on my experience on both ends of the communication.

How can I provide feedback to this developer in a way that allows it to be perceived by this person for what it truly is... feedback, not a personal attack?

It sounds as though you're not communicating in your review. You say these three things need to be fixed, but I don't hear any indication that you ask the developer if they agree. Peer reviews go both ways - you point out things that should be fixed, but there's often reasons that developers do things the way they do them. Often these are good reasons that entrenched developers just haven't been exposed to. I also hear a lot of things that are "wrong".

So, make sure you're explaining why something is wrong. Certain individuals (programmers especially) abhor blindly following direction, even for their own good. Make sure you're giving them opportunity to offer their opinion - ask for it explicitly. Without this sort of back and forth, telling someone how to write their code can be perceived as micromanagement. It usually is micromanagement. Finally, point out good things too. You mention that the developer has gotten better, but unless you communicate that, they may perceive you poorly.

Oh, and especially for beginners, it is important to explain the benefit of the code review process. It's not just a dump-on-the-n00b-fest. It's there to cut down on bugs that are annoying and expensive to fix later in the process.

I can certainly lower my expectations but I believe this is a disservice to the developer an the company.

It depends. If their role is a lower responsibility role, then your expectations should match that role.

But you should definitely adjust your interactions with this individual. People are different. What works for one might not work for another.

I understand that it's hard to get the whole picture from this post, but is the situation hopeless?

It could be. If the employee is off lowering morale of the team by being angry about reasonable processes all the time, that's no good. If the employee has a mental issue where they blow up perceived slights into conspiracies, that's no good.

But it could just as easily be that your employee has an unusual personality and you've been slow to recognize or adapt to that. It certainly seems premature to give up hope without knowing where the problem actually lies.

Answer 2

Criticism

There are many reasons people can get very defensive about criticism of any kind. It can be due to insecurity, past trauma, etc. Ultimately it can be helpful to understand what the touchy subject if you know this you can adjust your approach accordingly.

Nothing is Wrong, bad, terrible, worse, etc.

The key to giving criticism is to never put the person on the defensive. That means you should avoid negative words like wrong, bad, terrible, worse, etc. Which on that note avoiding better is also a good idea as it implies bad.

Bad example:

Hey Bob, I was reviewing this controller method you wrote. It's really not a good idea to have this directly call the database.

Why? You were good about pointing out the what, but you risk putting bob on the defensive and you didn't give him why. You basically said "You write terrible code" from Bob's point of view.

Okay example:

Hey Bob, I was reviewing this controller method you wrote. I think it would be better if we accessed the database through a separate repository to help prevent SQL Injection.

Why? Well now you did an excellent job of the what and why and you didn't directly accuse Bob of bad code. He still might get defensive, but at least you've mitigated it some.

Good example:

Hey Bob, I was reviewing this controller method. I'm worried it could be SQL Injected; do you think accessing the database through a separate repository would make sense to prevent that?

Why? For one thing you didn't even point out this is his code, he knows it is, but not pointing fingers (even when you are) really helps. In addition to this you didn't skip right into what is wrong with the code, you provided a concern then where that concern is. This means his mind is already considering the real issue and not immediately going on the defensive.

Honesty is the best policy

Being honest with someone is always a plus, often though you need to manage how the message is conveyed though. Some people love the straight to the point no nonsense approach where you just say "Your attitude this past week has been terrible, I know you've had a rough week, but let's get our heads back in the game okay?" I prefer this, no dancing around the issue at hand, I also know you say this to the wrong person and they're going to be really upset by it.

In this case this person goes on the defensive pretty easily, the direct approach isn't going to go well. Instead try to address the symptom and let him sort out the problem. (unless he asks directly) Say he's got a piece of code and it's running unreasonably slow because of a simple honest mistake.

When he asks for your approval take the time to look over everything per norm. Go through the code, explaining the things you like about it. "This extension you added here, that's going to come in handy later", "This query is really good work, should be easy to adapt if we ever need to pull additional data", etc.

When you hit that spot that has some code smell go "Hmmm... this works, did you consider making this a Switch case statement? I'm worried if we decide to add more values this could become cluttered."

In this case you didn't say "Hey Bob, these four else-ifs are a mess" you expressed it as a concern you're both working through and asking for his feedback. This can really help as you're not pointing fingers your collaborating. (even though you're effectively steering him to what you want, you're also providing him the why and helping him think through it as well)

Answer 3

Your text contained two telling phrases: "I see myself as a peer to the other developers" and "I see my management role as a supporting role of the team".

In other words, "I'm not a manager, I'm a team support worker"

This can be a nice relaxing job, but it isn't what you are being paid to do, and it means that your staff feel able to have a hissy-fit if they don't like what you are saying to them.

An important role of the manager is to set boundaries, and these emotional outbursts are not acceptable. Of course you should make code-reviews as non-confrontational as possible, but sooner or later you have to lay down the law, basically saying (in the nicest way possible) that you won't accept infantile behaviour - this is a serious workplace, and you're paid to do a serious job, so do it.

If this means you have to have a more distant relationship with your staff, then welcome to the real world - it is a really bad mistake to try and be friends with your staff, since sooner or later you will have to raise a disciplinary matter with them, and any semblance of friendship will crumble.

So you aren't their peer; you are their manager, and sometimes you need to remind them (and yourself) of that fact.

Answer 4

I would do some introspection. First of all code reviews can turn into nit-picky personal opinions on how things should be done. Before you comment or critique his code think of the severity of the issue. Is this a personal opinion, would the code be better but ultimately execute just the same, the code is wrong or this is critical.

With code reviews you have a limited amount of social currency before you're labeled in this developers mind of always nit picking and not adding value. The important thing is that code reviews add value. If you have a nitpick then label the comment as a nit pick.

More broadly then just code reviews. Not many people are going to be OK if you always give negative feedback, so give some positive feedback occasionally, especially in code reviews. "That's an interesting approach, I like that.", etc..

One more thing is maybe just start giving him a call with code review feedback, this developer could be stressed about how it looks to the team that you're picking apart his code so call him up talk through it. That way you can have more of a conversation and it's less high stakes than doing it in front of the whole team.