I’m at Agile2005 this week. I always expect to meet interesting people at this conference, and I haven’t been disappointed.
One of the people I’ve met was a reviewer for Behind Closed Doors: Secrets of Greate Management (which I co-authored with Johanna Rothman. Should be available in September).
Of course, I introduced myself and thanked him for his helpful comments.
But when I thanked him, he said he was a afraid we’d be insulted because he pointed out broken sentences and areas to improve. Au contraire. We were very grateful both for the content of his comments and his time and attention.
Any time some one spends that much time helping improve a product, it’s a gift.
And the way feedback is delivered makes the difference between whether it’s received as gift or a slap.
Here’s how our reviewer structured his feedback:
1. Comments about what he liked about the ms.
2. Global comments.
3. Specific detailed comments about areas to improve and areas where he didn’t understand what we were getting at.
4. A wrap up of what he liked about the ms.
This is an effective structure for feedback on a product. (But as you know from earlier posts, not an effective way to give interpersonal feedback — the icky tasting praise sandwich.)
When a reviewer starts with a long list of what’s wrong, the product author (whether it’s prose, code, design, whatever) will probably never hear the positive comments. And it’s useful to know what is working–the parts to keep as they are.
More on commenting on code here –focused on code, and useful for reviewing any product. (From Ken Estes via the AYE wiki).
