I just published a post drawing out communication lessons specifically for software developers, derived from a podcast episode. There's a lot of great stuff in there, so go check it out, but today I want to draw out one particular lesson in more detail.
When you give feedback, include information about the priorities and weights of your feedback.
The problem with flat feedback
One of the biggest challenges with traditional, or what I'll call "flat" feedback is that it doesn't make any distinctions between feedback that is "hey, here's something you might want to think about, but it's no big deal" and "this is really important for you to address".
We often try to mitigate this via nuance - we'll hint at what's more important, we'll try to use tone of voice, but this suffers from multiple drawbacks.
The first drawback is it relies on the perception of the listener to understand our nuances. Someone who is more "tone deaf" may miss the nuance entirely. I have a relative who cannot hear feedback that has any degrees of nuance at all. Things that are politely phrased but that most people would understand as "this is really bothering me, you should stop" will be completely ignored. It takes 100% explicit statement to get through to her.
The second drawback is that nuance works even more poorly in writing. If we're marking up a document, communicating feedback by email, or (as in the original post) reviewing someone's proposed changes, all of our feedback will be interpreted in the same way.
As a result, our "flat" feedback will either be ignored (as in the case of my tone-deaf relative) or all assigned equal value, leading to someone having no idea how to prioritize the changes we've suggested.
Weighting feedback
Instead of the "flat" approach, I suggest explicitly weighting and prioritizing your feedback. This can be very verbose - "Hey, this piece of feedback is super important, you need to address it" as compared to "This is just a minor nitpick, feel free to ignore it"
This works fine when giving small amounts of feedback. If you're going to be giving much more (like marking up a document), it makes sense to set up a system.
In the podcast my original post was inspired from, the panelist recommended a concept called a 'feedback ladder' where pieces of feedback were assigned a weight of 'mountain', 'boulder', 'pebble', and 'sand'.
Each item of feedback had to be labeled as one of those, and it gave immediate information to the recipient of how important it was. Mountain was something that was huge and required a conversation, boulder being something still significant that needed to be addressed, pebble being a much smaller request, and sand being essentially "take it or leave it".
This system allows for large amounts of in-context feedback without any ambiguity. The recipient knows exactly how important you consider each item, and can then very easily prioritize what is most important and needs to be addressed.
Simple, explicit, and it will make the process of giving and receiving feedback so much smoother.
