The hardest part of my job is not technical — it’s communication, specifically: giving feedback. I fail at this over and over, and I see other people having trouble as well. In fact, I fear that giving effective feedback is so hard that people are too scared to do it. That’s a loss, because giving feedback, in my view, is an essential mechanism to improve. And I like to believe that everybody wants to improve.
So, it’s time to finally figure this feedback thing out once and for all.
In October 2012 I bought a book called “Nonviolent Communication,” but I never read it. The funny thing is that I have recommended the book to at least three people, purely based on the title. Some people are so obviously violent in their communication that it was hard not to recommend this book, regardless of my utter ignorance about its contents.
But then, about two months ago I started to read. This is what I concluded:
Judgement is a silent killer
I connected the dots after a call with a client, in which I shared feedback based on our cooperation thus far — all intended as very constructive. However, I made a mistake: I slipped in one piece of judgement, and that ended up being the only thing being heard by the client.
What did I say? I mentioned I felt that certain issues with a team were exaggerated. I did explain this was a natural result of the way things were communicated between our organizations (there was a lot of “escalation communication” going on) and that this was the real issue to be addressed, but already during the call I sensed that that part wasn’t heard at all. And indeed, after receiving a summary email about the call, it appeared they primarily heard “exaggerated,” the rest was just noise.
Whenever there’s judgement in your communication, people will fail to hear anything else.
So, my lesson learned is to avoid any type of judgement in communication. Terms like:
- bad, sucks, terrible
- not capable
- just (e.g. “just 5 tests”)
Are all out. All judgmental. After using a judgmental word, you’re stuck, and the path the constructive conversation is blocked.
So, what should we do instead?
Here’s the essence of Nonviolent Communication summarized in 4 points: the NVC way of structuring a piece of feedback:
- Observation: what do you observe, without evaluation (=judgement).
- Feelings: the fuzzy stuff — how does the observation make you feel?
- Needs: what are your needs regarding these observations and feelings?
- Request: what do you want from the other person.
In essence, that’s it. Saved you from reading a 200 page book! (Not really — read the book.)
Let’s apply this in a developer context.
Let’s say you feel that one of your fellow developers is too careless with code and doesn’t care about quality at all. So, you share feedback YOLO-style:
Hey Joe, your code is of terrible quality. Do you not care at all?
Pretty concisely formulated! Pats on back Yet, somehow it doesn’t have the desired effect. Joe is angry and stops speaking to you. Worse: nothing improves at all.
What went wrong?
There are two pieces of judgement in there:
- “Terrible quality” is a judgement, not an observation. What specifically do you observe about the code that resulted in this judgement? Perhaps not all edge cases are taken into account, as displayed by limited or no unit tests — that’s an objective observation. Perhaps indentation doesn’t follow the guidelines — another observation (but not: “your code is poorly indented,” because poorly is another evaluation.)
- “Not care” is also a judgement. You don’t know if Joe doesn’t care, that’s just your guess. Perhaps Joe is doing his very best, but just has never been made aware of all issues (because he never received good feedback before). Suggestion: leave this part out altogether.
So, how to do this NVC-style?
Let’s say the real issue is about lack of unit coverage with sufficient eye for edge cases.
Let’s start with the observation:
Hey Joe, I see that your code’s test cases do not cover all edge cases that need to be covered, specifically: A, B and C.
Moving on to associated feelings — just because we developers love to talk about those:
This makes me feel fearful that the code does not work as specified.
Moving on to needs:
This is because I have the need for important code (such as this) to be fully unit tested to ensure it works today and will not break in the future.
And a request:
Could you please add additional unit tests that cover all mentioned edge cases?
Do you think Joe get angry when you tell him this? I doubt it. Will he improve? Well, that’s up to Joe.
Easier said than done, though. This stuff is hard. Really damn hard. Not judging is hard. Surfacing your associated feelings and needs is hard. I’m trying daily, and still get things wrong all the time. Yet, I believe this is important stuff. So important that I’m convinced the world would be a significantly better place if everybody communicated this way.
Interested? I do recommend you read the NVC book. If you don’t feel like reading, watching the workshops also helps, many versions have been posted on YouTube. I should warn you, though. About 10 minutes in, Marshall pulls out a guitar and sings. Later he’s playing puppets. It supports the purpose, but prepare yourself.
I’ll end this with an inspirational quote, because, you know, we’re talking about soft stuff like feelings and needs anyway, so why go all the way and attempt to inspire:
“The ability to observe without evaluating is the highest form of intelligence.” — Jiddu Krishnamurti