Feedback Fallacy
Inspired by Justin Rosenstein, I wrote about blunt feedback six months ago. I still stand behind that post and I do consider it a worthwhile read. However, there's stuff in that post that I should revisit.
In the aforementioned post I wrote "I can elevate my co-workers by sharing feedback with them." This feedback can be blunt or negative if it has to. It can be something that elicits a defensive response from a colleague.
A month later Harvard Business Review published Marcus Buckingham and Ashley Goodall's article "The Feedback Fallacy". The piece made me consider if everything I thought about feedback was wrong. Does my feedback actually elevate my colleagues or does it bring them down instead?
Here's Buckingham and Goodall's argument in a nutshell: Blunt feedback is bad. It smothers learning. Also, organizations are way too obsessed with this kind of unhealthy, unproductive feedback.
Why is blunt feedback bad feedback? Here are the three systematic errors we make when we tell our colleagues that their communication isn't assertive enough or that they lack strategic thinking.
First, we think we are a source of truth. Too often we treat feedback as objective statements especially if we collect it from multiple reviewers. In reality, our perception of good versus bad is highly subjective and we all have our false assumptions and unconscious biases. The feedback we give tells more about us than the work we try to review.
Second, negative feedback triggers our lizard brains. Hearing negative feedback makes us raise our guard while positive feedback opens us up for learning and the possibility of change. You should try to keep your colleagues out of the "fight or flight" mode—not push them towards it.
Third, you can't codify excellence unless you're trying to replace machines with humans. When you pursue excellence in creative fields, you are navigating uncharted territory. You can't model creative excellence, and because of that you're never really sure if your colleague is "on the right track" whether you like her work or not.
Buckingham and Goodall aren't proposing us to steer away from instructions and responses to mess-ups. System failures should be investigated. Teams help new members navigate unfamiliar programming languages and frameworks. But these kinds of feedback situations are more about putting out fires and getting up to speed rather than professional and personal growth.
Want to help your colleagues learn? Here are two tips from Buckingham and Goodall:
- Acknowledge that your feedback is subjective: instead of telling your teammate not to do something, use a pattern such as "when you do X, I feel Y."
- Point out moments of greatness: Direct the focus of your feedback away from mistakes. Look for positive outcomes and help your colleagues notice them also.
If the majority of the feedback you give your colleagues are reactions to mistakes, you're not helping your colleagues grow. Often your colleagues don't even need you to tell them that they messed up (they probably know it themselves already). Instead, look into your colleagues work and tell them what's so great about it.