I have wandered around the internet looking for resources that speak to effective ways to give feedback. I have, in my journeys, once again realized what people mean by the word ‘abundance’ as well as what they mean by the difference between ‘information’ and ‘knowledge’. I don’t think that there is ‘one way’ to give good feedback. I think we are all different people, with different skills as communicators, and different ways of relating to each other. That’s cool. That’s life. But I try to leave alot of feedback. I’m going to detail some of the things that I try to do when I give feedback and hope that you will share some of yours.
Golden Rule – Everyone is working hard. Respect people’s work. Approach them from this position.
Obvious feedback
I’ll start with the easy one. Anything that has to do with spelling, obvious grammar (and no, i’m not talking about oxford commas) and clear errors – I commented on. Always. I try to backchannel if i can (send an email etc) or i’ll comment on the work in public with a ‘feel free to delete this comment’ message on my comment. I would far rather know that i had inadvertently added an ‘h’ to the word sit than have people read it over and over again. I’m always nice about it. Some of us have a harder time seeing these mistakes than others. 🙂
Help out with the obvious stuff… just be nice about it 🙂
General feedback
I think of general feedback as being the sense that someone gets from an idea. I like general feedback to be specific. I try to never say “i didn’t really understand your blog post” when that blog post is 1000 words long. I try to stick to things like “the second paragraph of your blog post was where i started to get confused about who the audience was.” Sometimes when I’m in a rush or really excited about an idea, i don’t necessarily say things as clearly as i might. That’s true for others as well.
Give general feedback, yes, but be as specific as you can be. Take the time to describe your reaction
Technical feedback
This is where debates can often begin and also where more starts to be required of the person providing the feedback. If I’m going to disagree with how a given concept is explained, how a word is used or how an algebraic problem is… uh… problematized, I try to explain myself as best i can. I explain what part of the field I come from, explain why my point is important to me. If i manage to handle this properly, it’s not usually an issue. Where I get into trouble, as always, is if i make the issue bigger than it is. If i feel like saying something like “this is a common mistake” or other silly things, I put my computer away and comment later.
If you are disagreeing on technical grounds, explain yourself. Offer a new solution.
Conceptual feedback
This is the most difficult kind of feedback and often the most important. We, many of us, come from very different schools of thought. The death of many projects, particularly interdisciplinary ones, in a lack of a common language. This can make it difficult to disagree on conceptual grounds in an efficient manner. While I can leave a comment on someone’s work attempting to explain a conceptual clash, it will involve a significant amount of work if I want that person to be able to hear me.
That’s not to say that I don’t do it, just that you are taking on a significant responsibility if your goal is to actually represent your opinion in a way that will help. Often what I prefer to do in these situations is write something about the issue, in a more generalized way, on my own blog. This will allow a new conceptual conversation to happen on my own turf and allow the old conversation to continue. Both conversations are valuable… i don’t like to get them confused.
Conceptual disagreement require serious thinking. Do it, if you have the time to commit. These are important conversations.
Anyone else?
Process feedback. Less focus on what they’re doing, more on how they’re doing it. This is especially necessary if their process is disruptive or harmful – for example, the person on a development team who just goes ahead and implements changes without discussion or notification. Process feedback has to focus less on the process itself, and more on the harm caused. It can be tricky to offer, is generally better done via backchannels, but may have to be escalated to a group level. At the very back edge of process feedback has to be the possibility of saying “if you can’t play nice, you can’t play.”