Giving Feedback Without Much Context

03 November 2016

Situation: I noticed that one team had almost no discussions around their code changes before they were merged. Other teams did. They would make suggestions for improvement, point out flaws, and sometimes do several rounds of commenting and re-committing before code was actually merged. This was the point of code reviews, after all.

In this one team, this was not happening. Some developers outside of this team interpreted this the following way: “Sure, this is Edward’s team. He is the most experienced developer and does what he wants. The others just wave through whatever he pushes.”

I had no real way of knowing if that was true. Edward had a reputation of being kind of a lone wolf sometimes, so there might have been something to it. I decided to grab Edward and another developer on the team and ask for their view of things.

Incomplete context

This is an example of a situation where you would like to speak up, but you have very incomplete context. In any company with more than ten employees, this kind of situation is rather common, because you cannot have the full context of all the things happening around you. However, if you are truly concerned about something, or something is really bothering you, you still have the right, maybe even the obligation, to speak up. Leo Widrich of Buffer wrote about how he handles these situations:

“[…] it’s the fine balance between admitting [our lack of context] to ourselves and at the same time not letting it paralyze us to speak up and share what is nonetheless on our minds, even without having that full context.”

If you have a certain suspicion or apprehension, putting it out there will create an opportunity to clarify and get rid of it. This is way better than trying to suppress it, because, over time, it will probably not disappear, but harden.

Now, your concern might be entirely ungrounded and far from the truth. Therefore, if you are not careful in communicating it, it might cause hard feelings on the receiving end. However, there are two things you can do to make the other side more receptive and willing to listen:

Openly admit your lack of context
Find a non-accusatory way of describing your concern

As for the the first point - openly admitting your lack of context -, imagine you start a conversation like this:

You: “Hey guys, I am not very happy with how you just wave each other’s code changes through without really looking at them.”

Boom! Disaster guaranteed. No warning, no explanation where this is coming from, just an accusation right away. Your conversation partners have to be very mature and competent communicators in order to react to this opening in a productive way. If they are not, this conversation will go down the drain pretty fast.

Instead of barging in like that, let us start by admitting our lack of context using a phrase that Leo suggests:

You: “I know I don’t have the full context here, but it seems like you just wave each other’s code changes through without really looking at them.”

That’s still a pretty strong and general statement, but the humble introduction (“I know I don’t have the full context here”) makes it a bit better to digest for the receiving side.

No accusation

On to the second point: Our suspicion is still voiced much like a fact. Let us phrase this in a less accusatory way. For feedback in general, it is a good idea to start with your observations and perceptions. This way, you are not claiming to know the absolute truth, but you are only sharing your impression:

You: “I know I don’t have the full context here, but I have been comparing pull requests in other teams with the ones in your team. What strikes me is that other teams use the pull request tool to discuss a lot about alternative ways of doing things. They point out flaws, and subsequently update their pull requests accordingly. In your team’s pull requests, I do not see such discussions, and I was wondering what the reason might be.”

See that? No accusation or criticism at all. Just an observation. If you deliver this observation in a matter-of-fact tone, then all that people might blame your for is your curiosity. The opposite side will not take it badly, and the “issue” will quickly be resolved.

In the end, it turned out that Edward’s team did have discussions on their code changes just like any other team. They just had them face-to-face, verbally, instead of written down in the pull request tool. They did a lot of pair programming and continuously involved each other in their thoughts, so that the discussion and the suggestions were happening all the time. The issue was not really an issue. Easy.

P.S.: Jason Evanish pointed out that it might be better to let the other party talk first before sharing your observation. Something like: “Hey, I was wondering what your process is before you merge code into master.”

My objection to Jason is that they will probably know that something is bothering me, and be wary. Therefore, I might as well be open and direct. However, he has a point: The final version of how I suggested to open the conversation might still be received as criticism which could be avoided by letting the others talk first.

I think your relationship with your employees, the cultural background of the people involved, and the company culture all play a role. As always in communication, there is no one best way. With my colleagues, something like the final version above is usually entirely in order, and will not damage any relationships. However, if you have not been able to build a lot of rapport with somebody, you might want to be even more careful.

Thanks, Jason, for pointing it out.

Time investment

This little post took me about 2 hours.

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