The Problem With Feedback - It's Hard to Listen To

December 05, 2022

Young man covering his ears and learning his head forward

Photo by @chairulfajar_ on Unsplash

The day is August 18th, 1969. A dwindling crowd remains after an endless night of music at a farm outside Bethel, New York. After a long and full lineup of music all weekend long, only one artist is left to play at Woodstock.

Jimi Hendrix and his band began playing somewhere around 8:30 that morning. They played some of his hits with added space room for improvisation and general jamming.

But what most people remember about this set wasn’t one of his hits. It was a rendition of the Star Spangled Banner.

In his version of the US national anthem, Hendrix utilized something known as feedback. Feedback is when some fraction of a signal from some output is fed back into part of the input of that signal. When it happens in a musical or audio setting, it often creates deafening shrieks and unpleasant sounds, sending hearers to cover their ears and yell at an unknown person, “turn it off!“.

When Hendrix used feedback, though, it was intentional, and it was part of the melody and part of the timbre. He used feedback as a tool rather than something he had to work around or avoid.

But it’s a delicate balance between using feedback to create music and creating a cacophony of screeches. Even when a guitarist uses feedback creatively, as a listener you still have to learn that it’s intended to sound that way. It’s still hard to listen to. There is always that inclination to wonder, “is this correct?” and start looking around to make sure the guitarist on stage or the AV guy in the back doesn’t look frustrated about what is happening.

The same is true for feedback in our workplaces, and on our teams. Feedback can be hard to listen to.

It’s Often Loud

Have you ever been in a packed room where everyone is talking? Everyone keeps getting louder and louder, trying to talk over everyone else. Before long, no one can hear anyone anymore, and people start to leave. Even if you went to see your favorite band play your favorite song, it wouldn’t sound good if the volume was too loud.

Feedback can be the same; it’s often hard to hear because it’s “loud.” Direct feedback - even when true - can be too much to hear. We’d rather put our hands over our ears and walk out the door.

If we want to hear the feedback, we might have to listen to it through ear muffs. Not full-blown noise-canceling headphones per se, but something to help turn down the volume.

Of course, we can’t put literal headphones in our next one-on-one or performance review. So how do we turn down the volume? How do we make it easier to listen to? Everyone is different, but here are a few strategies that have helped me:

  • Ask for written feedback instead of just having a conversation. While written feedback might not work for you, having a written set of feedback delivered an hour or so before any formal conversations helps me process it. I can respond more easily rather than react to it after reading it a few times. This is especially helpful for performance reviews or formal check-ins.
  • Be willing to say you need more time to before hearing feedback. If someone wants to offer you feedback about a meeting or situation before you are ready, say so. Not everyone will do this, but many ask, “Can I give you some feedback?” A valid answer to that question is, “Not right now.” Admitting I’m not ready to hear feedback gives me the time to compose myself (if needed) and process the situation on my own ahead of time.
  • Focus on hearing the feedback first and processing later. Instead of trying to react or respond in a conversation, I’ll focus on listening to what the other person has to say, writing it down, and processing it later. Even if I’m asked, “What do you think about that?” I’ll often say, “I’m not sure right now, but I’ll get back to you.”

It’s Often Out of Tune

If you listen to Hendrix’s Star Spangled Banner, the feedback pushes and pulls the notes out of tune. As the speakers blast more and more sound, the guitar strings start to vibrate from the speakers rather than from being plucked. New octaves and harmonic frequencies begin to emerge. And it can often sound unsettling. And then there is the intentional note bending and neck warping, making it all difficult for the untrained ear to listen to.

All this to say that feedback can be “off.” A detail about work you have accomplished might get overlooked or amplified more than you think is right, or someone might mischaracterize your intentions. In any case, you feel that you’re getting feedback this isn’t accurate or trustworthy.

When this happens, it is essential to remember that delivering feedback can be as challenging as receiving it. It is unlikely the person giving you feedback is intentionally misrepresenting something. When appropriate, ask if you can correct them or provide more context around a particular circumstance. Practice responding vs. reacting here too.

An additional tool is to find something to agree on before offering further context or correction. It’s sometimes referred to as the “yes, and” rule. By affirming something true about the feedback and adding to it, we welcome collaboration and working together towards the truth or the goal rather than trying to figure out who is right and wrong.

This tool is especially helpful for delivering feedback during code reviews. If we have feedback around an implementation that might be slow or could be improved in some way, start our feedback with a positive agreement (“This will work”) and then follow it up with our feedback (“and we could improve it this way”). By initially agreeing that that existing implementation works, we can move more towards feedback around building something better vs. getting caught in a battle about right vs. wrong.

There are times, however, when we do need to correct something that was clearly incorrect or when someone is disregarding important facts. In my experience, this happens less than it might seem. Learning how to leverage the “yes, and” rule can be helpful in tense moments when something is slightly out of tune to keep things on track.

Delivering Feedback is Hard to Master

Just like creating feedback on a guitar is difficult, delivering performance feedback is difficult to master. Even the most well-intending manager or colleague might say something the wrong way or at the wrong time for it to be helpful. This makes it difficult to receive as the other person isn’t perfect.

There are many posts on how to deliver feedback (including my own), but you can’t assume that everyone has read them. We can’t walk in expecting the feedback deliverer to be an expert - though it would be much easier if we could! Instead, we must remember everyone is working it out in real time.

It’s like going to see a high school garage band concert. We know what everyone is trying to do, and we hear the places there are pretty close, but we also recognize it’s still just high school. Their skills aren’t there yet.

Of course, if you are receiving feedback from someone who isn’t working to be kind, humble, and objective in their feedback, it can be frustrating. I’m not saying we excuse that behavior. But if someone is trying to do those things, let’s lean in rather than pull away. Work to see through the fumbled delivery if you can. Then be ready and willing to deliver feedback to the deliverer on how they could improve their delivery.

TL;DR: feedback is difficult to hear. And while I’m just a software engineer writing about my own experience, we can learn how to hear feedback better by being aware that it is often loud, somewhat out of tune, and difficult to deliver.

It will always be difficult to hear negative feedback, but we can learn to hear through the noise and even find the parts that will help us learn and grow.

Happy coding!

If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.

Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.