I had a teacher in high school who reviewed papers by putting check marks next to parts she liked and writing NO next to parts she didn’t like. She used red ink for both marks, but the all-caps, thrice-underlined, and sometimes-punctuated “NO!!!” really scared me.
The NOs were so aggressive that, if you stood behind the piece of paper (to watch a classmate react to the grade, of course), you could see that the teacher’s handwriting made parts of the paper convex. Those NOs changed the physical properties of paper, and that felt weird to me.
I believe that feedback is crucial to any process, especially one that affects many. I don’t resent my teacher for providing feedback; I do, however, wonder if she could have presented her comments in a more productive manner, or one that is more conducive to the success of the project. I always think of this when providing my NogginLabs team with feedback. If we are going to remain a major player in the custom e-learning game, then it’s everyone’s responsibility to aim for perfection. This goes for anyone who’s expected to provide feedback, regardless of the context. How can I convey a message that is both clear and helpful?
BEGIN BY REVIEWING WHAT NEEDS TO BE REVIEWED
I know this goes without saying, but you’d be surprised how many feedback sessions are sub-par on account of the reviewer not doing his or her job. Carefully examine what is presented to you within the confines of the project’s expectations. If our end goal is to create a set of robust business simulations for a company, then we must review with that context in mind. If you really like following rules, then this step was made for you.
WHEN IN THE FEEDBACK SESSION, STATE WHAT APPEALS TO YOU
This doesn’t have to mean you love it, but start with acknowledging what is most attractive. A simple, “This organization makes sense to me” in reference to a co-worker’s written document is a great place to start. Call out that the writer understood the mission of the project. If the writer didn’t understand the mission of the project, well, start somewhere else.
STATE WHAT WORKED FOR YOU AND WHAT DIDN’T WORK FOR YOU
This is an old trick used in comedy writing. I’m not a comedy writer, but I DO listen to a lot of podcasts. As you give your criticisms, provide the reasons behind them and suggest plan B:
The photos of the galloping horses aren’t really working for me. The text is referring to horses, yes, but the tone is light and funny and meant for gamification. Maybe we can add bright colors, or even create illustrated versions of the existing horse photos.
Or if you loved it:
The photos of the galloping horses are really working for me. I like that they evoke a sense of majesty and mystery…which is exactly the tone of this e-learning course.
The trick is to remain honest and direct while being thoughtful and patient. Don’t step on anybody’s toes as they attempt to get it just right, either. Your suggestions are just that—they should never be communicated as mandatory fixes; rather, comments that further clarify the objective of the project and how you can get there.
I’m only realizing now that this whole post could have been summarized as “Don’t be a jerk.” Keep that reminder in your back pocket, too.
Unlike the crater-deep “NOs” I received on my high school papers, feedback shouldn’t feel weird to you or your team. It should feel helpful and directive and deliberate: as though the feedback-er put just as much time into the project as the feedback-ee. Your team wants to bolster and encourage your process, just as you should bolster and encourage theirs. Feedback can be scary, sure; but isn’t the prospect of getting it all wrong upon completion just a little bit scarier?