This is the first post in a series of random thoughts on community events that I’m writing based on my experience running a user group and the Developer Day Scotland conference.
In this post I’ll concentrate on receiving feedback.
Photo by Craig Murphy
First, I should like to concentrate on the management of feedback. If the event asks people to fill in feedback then it should be collated and returned to the speaker as soon as possible. For my user group meetings I try and ensure that when I get home afterwards I collate the feedback and email the speaker before I go to bed. The quicker the speaker can receive the feedback the quicker they can see how they did. The closer to the event the more they will remember and the better they will be able to evaluate the feedback effectively. For Developer Day Scotland I got the feedback out to all the speakers within 3 days.
If the speaker doesn’t receive their feedback after a number of weeks they they are most likely to have forgotten specific incidents during their presentation. The guy that writes “Loved the quip about…” or “It was most annoying when you…” has effectively wasted their time if you, as a speaker, can no longer remember making the quip or doing the annoying thing. The quip may have been an off the cuff remark made in the moment that you could have incorporated in to your future presentations – If you can’t remember it, then you’ve lost the opportunity to re-use it and entertain as well as educate. Similarly, if you can’t remember the annoying thing then the comment about it won’t help you so much. It isn’t easy to purge annoying habits if you don’t remember doing them or associate a particular habit as being annoying.
Bottom line on this point is to get the feedback to the speakers promptly. Devote time to collating it and delivering it to speakers. The sooner the better.
It’s all very well and good saying that but how do you turn around the feedback quickly?
If you have a paper based feedback system in place where you are collecting feedback after each session, you can have people help you input that into excel or a database. That will help you get the feedback processed quicker. In this case many hands make light work.
From personal experience, I don’t recommend the online feedback that happens after the event. This style of feedback takes longer because you are waiting on the attendees actually fill it in. Some might do it promptly, others might take their time, and some will just plain forget. From an organiser’s perspective, the online feedback may seem to be an easy win; it is much easier to collate as it is done online so the database is being populated by the actual attendees. Of course, as the feedback is filled in after the event the attendees recollection starts to fade.
If you want to get as many people to fill in the feedback as possible I’ve found that basing prize draws on the feedback forms submitted encourages more people to fill in feedback. For events such as Developer Day Scotland we had some prominent sponsors offer us developer tools as giveaway item. But smaller items such as books, T-shirts, mice can do just as well for user group meetings.
Having been responsible for collating feedback for a variety of speakers I’ve seen a fair amount of variety in the comments. However, I have to admit that I’ve never had a stunningly bad speaker at any of my events yet. For the most part feedback is positive. The audience generally really does want the speaker to succeed and will often give some leeway for things that go wrong that is out of the control of the speaker.
I’ve also found that there are a few really angry people out there who only ever give bad feedback. So, if you are a first time speaker and you’ve got one of those nutters at your session try not to take it too personally. I’m not going to go on at length about how to interpret feedback as Barry Dorrans, an experienced speaker at DDD and other events, has an excellent post on the subject on his blog: Is “bad” feedback the best feedback?
Finally, there is feedback form itself. What do you ask people? How do you want the results. There are two main types of answer, in my opinion. The first is the tick-the-box style where you just tick the box for the score out of 5 (or 10) on a particular aspect. The second is a question that requires a text based answer, a few words or a couple of sentences.
For the event organiser the questions that ask people to tick a box are often better because it means that when you collate all the feedback together you can rank the speakers. I did this for Developer Day Scotland (and published some of the results.) You can set a base line where you say, if anyone drops below this line they don’t get invited back, or if anyone goes above that line they are automatically accepted next time. Or, if you are like NxtGenUG you can use these scores to give out prizes to the best speakers.
From the speaker’s perspective the text based answers are often better because they give a greater variety of feedback and allow the evaluator to express themselves. This can be used to tell the speaker what they did well, to show appreciation, to point out a negative aspect, or to suggest a way to improve. The wide variations in what people can put would rule out giving them tick-boxes to mark off.
For the text based answers the questions have to be open. They have to encourage people to say what ever they want to say without constraining them into thinking that something isn’t important because it wasn’t asked for directly. I often reduce it to just two questions. “What did you like?” and “What didn’t you like?” And other times I’ll also include the catch all “Are there any other comments you’d like to make?”
Hopefully you’ve found this useful for your own events, or perhaps you have your own comments you’d like to add. Either way I’d welcome any feedback so feel free to leave a comment.
The Blog of Colin Mackay 