Feedback after programming workshops is essential to improve them. That’s why serious IT training companies do debriefing and ask delegates to fill in evaluation form.
However, as a trainer, you can do much better. Why do you wait until the end of workshop? Why can’t you ask for feedback during workshops and improve them in real time? In this post, I describe how I create a fast feedback loop at my workshops.
The method that I describe below was shown to me at instructor training for Software Carpentry, a non-profit organization and community delivering programming workshops for scientists and researchers. I was taught by Greg Wilson, the founder of Software Carpentry and the instructor of the train-the-trainer workshop. Greg said that this is one of two most important concepts shown at the training. I improved and adapted this method to my own workshops.
In short: during your workshop, just before a break, ask participants for positive and negative feedback on two sticky notes. Ask them to write down at least one positive thing about your workshop on a green one and at least one negative thing on a red one. After each break, give participants new sticky notes.
(I use sticky notes for different purposes too. For example, people who finished exercise stick green cards to their laptops, which make it easier for me to track progress, but I won’t discuss this method here.)
That seems to be easy, but there are a lot of small important subtleties that you need to be aware of, so that this method does actually work.
Asking delegates face-to-face is not the same as leaving anonymous feedback on cards. First of all, most delegates would feel uneasy about complaining directly to the instructor. Therefore, they would say that everything is fine. And if you say that they have to give one negative feedback, you make them feel uneasy. In the end, it’s our job (trainers) to make sure that workshops are not only effective, but also a pleasant experience.
Another reason is that the feedback wouldn’t be honest. Participants would complain about infrastructure or other stuff that you don’t have control over. They wouldn’t tell you that, for example, you’re a bad instructor.
Clearly state that you expect at least one negative feedback. Otherwise, some participants won’t give you that feedback, because they don’t want to be rude. If you clearly state that they have to give you one, they won’t feel uneasy. You can say that you’ll feel offended if they don’t share that feedback. :-)
Participants often ignore this part of workshop if you don’t emphasize that this is an important point. They are often tired and the only thing they want is a break (and coffee), because both my and Software Carpentry workshops are intense and exhausting. You need to pitch to them, why it is that important. One effective way is to explain that if they don’t tell you what you do wrong, it won’t be fixed and you’ll do more of that.
Let participants share positive feedback on green cards, so they don’t feel that much uneasy about leaving negative one.
Make sure that the feedback is anonymous. Ask participants to leave sticky notes in one place. Don’t collect sticky notes by yourself!
It’s important that you pitch to workshop participants and emphasize all the foregoing points.
During the break, it’s time to analyze the feedback:
Check how many people gave you feedback. As I mentioned, they’re often tired. If a lot of people didn’t give you feedback, you probably didn’t emphasize why it’s important or you didn’t make it clear that you expect at least one negative feedback (and zero is not at least one).
Positive feedback is not that much informative. Focus on negative one.
If there are multiple cards about the same issue, stack them together.
Most of the time, you can ignore single cards. (But read them anyway.) For each thing there is somebody who doesn’t like it and we have to live with that.
If the negative feedback is one big stack of cards, you really have a problem, so fix it as soon as possible. Imagine that everybody wrote “the toilet is closed”… Any group of at least two cards means there is an issue. An exception is the workshops pace - see the next point.
There are always huge differences in programming skills between participants. Some participants complain that the pace of the workshops is too slow. At the same time, it’s too fast for other ones. Adjust the speed of workshops, so that both groups are of the same size.
In the case of positive feedback, a stack of cards means that participants like something very much. For example, if you got a lot of cards thanking for exercises, do more of them.
The benefits are obvious. You quickly get informed about serious issues that otherwise you might not notice (like closed toilet). You quickly adjust the pace of training - it usually takes one round to get to the right speed. You adapt to unique needs of your participants - this is especially important when you conduct a workshop in a country you’ve never been before.
I’m curious why training companies don’t use this method?