Recently a friend of mine commented on Facebook that he thought my blog had too many pictures and wacky captions, and that it was becoming a distraction from the main articles. I asked other friends what they about this, and the general consensus seemed to be that most agreed with him. So I decided to cut back on the number of photos per post.
This was actually a relief to me, since I had been spending more time searching through stock photos and coming up with captions than actually writing the posts. I was glad to be able to reduce that time and focus on the core mission of the blog.
Shortly after, I saw this friend in person, and he was apologetic. This surprised me, until I realized that from his perspective, he had insulted his friend’s passion project. But from my perspective, he had done me a big favor by helping me improve something that was important to me.
This highlights two very different ways of viewing feedback. Some people look to feedback for validation. They want to know that they or what they created are great. From this perspective, only praise is valuable, and any criticism is an insult.
Others look to feedback as learning how to make their project better. From this perspective, criticism is far more valuable than praise.
When you’re giving feedback, you should understand which context the person requesting feedback is operating in. Do they really want candid advice on how to improve? Or do they just want you to tell them they did a great job? Figuring this out can avoid an awkward social situation on one hand, or save a friend from future frustration and failure on the other.
But when taking feedback, I prefer to operate under the context of looking to learn what needs to be improved. (This is, after all, a blog about self-improvement.)
Here our usual attitude should be reversed. Normally, we’re happy when we’re praised and upset when people point out our flaws. But when we’re looking for feedback, we want to know what’s wrong, so we should seek out people who will find the problems in our work. And if someone only gives you praise, you should find a different person to give you feedback, because exclusive praise is worse than useless when it comes to learning how to improve.
I’m in a small writing group dedicated to exchanging feedback, which has stayed together for eleven years so far. One secret to our success is that we meet by phone, so we don’t have to deal with Los Angeles traffic. But more importantly, we all share this perspective of looking to improve our work, and recognizing that when others point out problems, it’s coming from a place of respect, helpfulness, and genuine desire to make each other’s writing be the best it can be.
I’ve learned some things about taking feedback from spending such a long time with a successful writing group.
The most important rule is to never argue with feedback. Arguing shuts people down, stops them from being helpful, and prevents you from receiving any value from the feedback.
If someone’s feedback is truly worthless, you can always politely write it down and then ignore it. But even if your initial instinct is to dismiss it, you really should give it more consideration. If someone “doesn’t get it,” that’s probably a flaw in the writing rather than the reader. Perhaps that’s a sign that you need to make “it” clearer. Or outside of the context of writing, maybe you need to clarify the use case for your invention. Or find a way to broaden the appeal.
I like to separate feedback into the categories of reductive and additive feedback. (Those are categories I made up, so don’t bother googling them.) Reductive feedback is saying something should be removed, or doesn’t work, or is confusing. Additive feedback is saying something should be added, or changed to something specific.
I’ve found that reductive feedback is almost always correct. If people say something doesn’t work, it’s because it doesn’t work.
Additive feedback may or may not be correct. You should certainly consider the suggestion. But frequently, you’ll realize that what’s being suggested is flawed in itself. In these cases, you shouldn’t just dismiss the feedback entirely. Often, additive feedback is really reductive feedback in disguise. People see an underlying problem, and then suggest a solution to it. You realize the solution has its own problems that make it not viable. So you need to ask clarifying questions to understand what the underlying issue is that they’re reacting to, so you can figure out a different fix to it.
One of my old screenwriting professors once told a story: He had written a script about a guy traveling around the country on a motorcycle. Then a studio executive insisted the guy needed to have a dog with him. The writer reminded the executive that he spent the entire story on a motorcycle, which would make it kind of hard to bring a dog along. Should it be some tiny dog that he could carry in a bag? The executive said it should be a German shepherd. The writer asked if he should have a sidecar for his motorcycle to carry the dog. The executive said that would be silly. But he should still have a dog along somehow.
Ultimately, the movie never got made, and all the writer got out of it was a story about a studio executive making a ridiculous demand. And perhaps the executive truly was a mental three-year-old who was obsessed with doggies and had somehow Forrest Gumped his way into a high-powered job despite being grossly incompetent. But more likely, there was a flaw in the script that he was reacting to. Maybe the main character needed someone to care about, or something to make him more sympathetic. If the writer had asked questions to clarify what problem the executive had issues with, he could have gained more insight into how to improve his script, and ended up with a sale and a movie made, which I’m sure he would have preferred to a funny story.
One note here about asking clarifying questions is that you shouldn’t use that as a stealth means of arguing. Remember, the goal is to learn how to improve your project, not to prove that your critic is wrong. A good rule of thumb is that if you could preface a question with “Oh yeah, well…” then it’s not really a question; it’s an argument. By stealth-arguing, you’re only cheating yourself.
Remember, feedback is a tool that you can use to improve your work or yourself. In order to get that value out of it, you need to avoid using it as a means for seeking validation. Instead, you can seek validation by enjoying your work, recognizing your own continual improvement, meeting your own standards, or succeeding with your end product. Or come up with your own means for seeking validation. Just don’t mix it with learning what flaws need to be corrected.
Leave a Reply