Feedback is a gift

This is the fourth in a series exploring the things I have learned from the open source way during my journey with Red Hat.

Think about some of the gifts you’ve received in the past year. Some of those gifts probably were wrapped beautifully and brought you great joy and surprise. Other gifts might not have been wrapped in pretty packaging. Some gifts, you might not have appreciated and returned or, dare I say it, perhaps re-gifted.

There are some interesting parallels between getting gifts and getting feedback from your colleagues or peers. Over the years, you may have received some feedback that has positively transformed your life. You also may be given some feedback that you would have rather not have received. Perhaps from time to time you have even “re-gifted” the feedback you have received.

I believe that feedback, both positive and negative and regardless of the wrapping or contents, is a gift. Why?

When someone gives you feedback, it is a sign that the person is engaged, a sign the person cares about you or the issue enough to take the time to comment.

In the open source software world, the people who give feedback by pointing out bugs in the software are the heroes. In the world of human resources or legal affairs, when I get feedback, it is often not exactly what I am hoping for, but I have found that if I stay open to the possibility that the feedback I am receiving will help the end product, it can be a great source for improvement.

In a recent post, opensource.com contributor Gunnar Hellekson highlighted a phrase used regularly by developers in the open source community: “patches welcome.” As he points out, this is sometimes meant in earnest and sometimes a bit passive-aggressively, but it essentially means that providing feedback is a good thing... but it is even better when it is backed up by code that helps resolve the issue in question.

So while all feedback is a gift, the best feedback is accompanied by some “source code,” with clear suggestions for improvement, specific requests, or even an offer to help or lead efforts toward a solution.

At Red Hat, we have an internal mailing list called memo-list that, since the early days of the company, has been a way for any employee to provide feedback and suggestions. When I first joined the company, I found the open forum, with frequent criticisms and suggestions, to be a “problem.” But over the years, I have observed that some of the ideas shared on memo-list have been true gifts, giving the company feedback that has changed the company for the better. Some feedback on memo-list is simple criticism, without accompanying source code providing a fix, but I would rather know that the concern is there than for people to keep their concerns to themselves. While I find the former ultimately more constructive and helpful, I have come to learn that both forms of feedback are gifts. The real problem would be if we weren’t receiving any gifts of feedback at all.

One of the best examples of the gift of feedback at Red Hat was in the creation of our mission a few years ago. The final product is this sentence (and here’s a video that explains it):

To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way.

But the statement didn’t start that way. A small group of people took a first shot at drafting it, then asked broadly for feedback from the entire company.

Some of the most important words (like “in” rather than “of” and “contributors” rather than “developers”) were suggestions made by thoughtful Red Hat employees who were able to not just point out what was wrong, but provide the source code to making it right again.

So here is the takeaway: Feedback is a gift. And the very best feedback will come with accompanying source code. And feedback on this post is welcome.