Giving critical feedback is an unpleasant situation for many new team leads. Let’s consider Robert. Not too long ago, Robert was “one of us”, a developer in the trenches who was producing high-quality code, and still found the time to help other developers solve hard problems. Now, he is supposed to do this thing called “managing”, but he does not see himself as a manager or as a boss. He sees himself more like what some people adequately call “programmer plus plus”: Still “one of the guys”, just with some extra 20%-or-so responsibility on top.

Since Robert has this mindset, the idea of telling others what to do, how to do something, or how to behave, feels presumptuous to him. Isn’t that exactly what he wanted to avoid? Becoming this stupid big boss who terrorizes his subordinates with pointless advice and keeps them from doing real work?

The case

However, there are times when you have to act, and this is even true for programmers-plus-plus. Let us assume there have been repeated complaints about Jared, a backend developer. His colleagues are becoming impatient with him, because he is sloppy sometimes. Robert has to talk to Jared about it. In the spirit of his programmer plus plus mindset, he offers his point of view:

Robert: “Jared, do you remember the cronjob you implemented where all users whose balance was close to zero were to be notified by email?”

Jared: “Yes.”

Robert: “Somehow, the email notification part was entirely missing, so the task had to be reopened once QA caught it.”

Jared: “Yeah, I know. I don’t know, I think I simply moved too quickly there. We were close to the sprint end, and I wanted to finish this task and another one before that. That’s how I made the mistake.”

Robert: “I see. And last week you checked in a database query that did an unnecessary join and took ten times as long as it should have. That one was not caught until it went live.”

Jared: “Yes. I should have paid more attention.”

Robert: “So, what do you think how Steven from QA feels when he has to check your feature twice or even more often, as in the cronjob case? Do you think he likes it, or …?” (pauses uncomfortably)

Jared: “I guess he is not super happy about it.”

Robert: “So, do you think there is maybe something that we can do about this?”

Jared: (thinks silently)

Robert: “Like, I don’t know, before you push some code, check if all the specification is met?”

Jared: “Yes, I should probably do that.”

Robert: “And, for database queries, check the tables you reference and make sure they are really used?”

Jared: “Yes, that also.”

Robert: “All right.”

Was that a good feedback session? Well, it had good elements, but there are certainly some issues with it. Let us go over the good things first.

Robert had a pretty good structure in place. He used concrete examples and checked back to make sure Jared knew what he was referring to. He illustrated the consequences of Jared’s behaviour. He tried to come to an agreement on how to improve the situation. All of these steps are helpful and should be part of a good feedback conversation.

Conflict avoidance

The problem is that Robert is in conflict avoidance mode. He feels uncomfortable, he does not want to be the manager who tells somebody off, he does not want to upset Jared, and he fears giving critical feedback might harm their relationship.

There are multiple signs of this:

Robert does most of the talking. When he goes through the part of the conversation that should actually be hard for Jared, he makes it hard for himself by doing all the conversation work and letting Jared get away with cheap answers like “Yes, I should probably do that.”.

Also, instead of making Jared think through the effects of his behaviour on others, Robert practically puts them in his mouth: “Do you think he likes it, or …?” With that, the direction is set, and Jared does not have a lot of active reflection left to do.

“We” instead of “you”: When he is working towards an agreement to improve the situation, Robert’s words are: “So, do you think there is maybe something that we can do about this?” There are two weakening elements: The first is the “maybe”, the second is the “we” instead of “you”.

Robert wants to avoid blaming somebody, so the “we” instead of “you” suggests that he somehow has a part in Jared’s mistakes. This is a noble intention in principle, but it sends the wrong signals. It takes the responsibility off Jared’s shoulders, and implies that Robert does not trust Jared to improve and master the situation.

As a communication trainer once advised me: “It’s their problem to solve. Not yours. Don’t try to solve their problem for them.” Which brings us to the last point:

Robert makes the suggestions: When Jared does not come up with suggestions right away, Robert cannot stand the awkward silence and starts making suggestions himself. By doing that, he a) plays a part that should be played by Jared, and b) forces his solution on his employee, risking low acceptance and buy-in on the other side. Prescribing the exact steps instead of setting the goals is a good definition of micromanagement.

Round two

Let us see how Robert could use the above reflection to travel back in time and better steer the conversation:

Robert: “Jared, do you remember the cronjob you implemented where all users whose balance was close to zero were to be notified by email?”

Jared: “Yes.”

Robert: “Somehow, the email notification part was entirely missing, so the task had to be reopened once QA caught it.”

Jared: “Yeah, I know. I don’t know, I think I simply moved too quickly there. We were close to the sprint end, and I wanted to finish this task and another one before that. That’s how I made the mistake.”

Robert: “Can you tell me what happened when you pushed your changes?”

Jared: “Steven tested the feature and caught the bug. Then, the ticket came back to me.”

Robert: “How do you think Steven feels about such situations?”

Jared: “What do you mean, exactly?”

Robert: “Well, tickets going back and forth, what does that mean for Steven?”

Jared: “It means more work for him.”

Robert: (lets this sink in)

Jared: (getting a little uncomfortable) “Probably he’s not thrilled about it.”

Robert: (after another short pause) “Last week you checked in a database query that did an unnecessary join and took ten times as long as it should have. That one was not caught until it went live.”

Jared: “Yes. I should have paid more attention.”

Robert: “What do you suggest to avoid these issues in the future?”

Jared: (smiles uncomfortably) “I’m not sure, I mean, mistakes happen, right? There will always be mistakes. That’s why we have QA, don’t we?”

Robert: “So you think it’s fine to pass on work that meets only half the specification?”

Jared: “No, that’s not what I mean… I mean… Yes, I should have another look at the specification, before I pass it on.”

Robert: “Sounds good. What about database queries?”

Jared: “For database queries, I should also double check.”

Robert: “Do you feel confident that you will catch all issues if you double check?”

Jared: “Yes. I feel pretty confident with SQL, if I put in the required attention. For cases when I’m unsure, I can ask Pedro to also have a look. A second pair of eyes should help.”

Robert: “All right. Let’s do it like that, and talk about how it’s going in four weeks.”

This conversation might have been a bit more uncomfortable for Jared, and of course it is not pure fun for Robert, either, but it is a lot more effective. Concretely:

• Robert did less talking than in the first dialogue. He leaves certain uneasy parts for Jared, e.g., describing how his sloppiness resulted in more work for QA.
• Robert asks what Jared suggests to improve the situation. It’s “you”, not “we”, making it clear that Robert expects - and trusts - him to come up with a solution.
• When Jared questions the need to change something (“There will always be mistakes.”), Robert sticks to his point by asking another question.
• Furthermore, he pushes Jared to really come up with effective solutions. “Do you feel confident that you will catch all issues if you double check?” Prompted thus, Jared comes up with another suggestion (asking a colleague to have a look).

Conclusion

It is little conversations like this that can go a long way towards fixing issues on the team before they blow up. Nobody has to yell, nobody loses face, and both can be friends again after they leave the room. Note, however, that being friends with everyone should not be a manager’s top priority. Finally, it should be very clear to Jared that Robert will follow up on the topic (“Let’s talk about how it’s going in four weeks.”). This is an act of caring: Taking the time to follow up sends the message that Jared’s development is important to Robert. A good manager is a coach, and a good coach pushes his people.

Time investment

This post took me about 3 hours to write, plus finding suitable images on Pixabay or Unsplash.

Want to learn more about giving feedback? Check this out: