I set up a couple of workshops recently, some with external trainers, and some internally. I have to admit, it is not the most fun part of my job. You make appointments, you write emails, you book rooms. Not very exciting. However, it is also really important, because it benefits a lot of people, and investing in your skill set is crucial for every software developer.

Theoretically, setting up a workshop should be very simple: You make an appointment, invite the people in question, write one or two emails, and everything works out fine. Of course, it is not quite that easy in reality. People forget about the workshop, or do not notice the invite at all. Some are not quite sure they can make it, and try to postpone their decision to the very last minute. Suddenly, what you planned as a ten-person group shrinks into a little group of six. That’s a surprise you would rather miss out on.

There are a couple of things that I have found useful for avoiding such surprises and setting up a smooth workshop event instead. Maybe, you find them useful, too.

Accept or decline - there is nothing in between

Depending on how busy your participants are, the date and time of the appointment should be fixed and announced at least two weeks in advance, maybe even more. Check after two or three days if people confirmed or declined the invitation. Talk in person to those who did neither: Why do they appear undecided? Did they not notice the invitation? Are they not sure they can make it? Are they not sure that the workshop can benefit them?

I remember an incident when a workshop was about to start, and I noticed a couple of people were missing. The external trainer was already there, and facing a group of five. I hurried around the office to find the missing ones, and remind them of the workshop. To my astonishment, more than one had not even been planning to attend. Their reasoning was: “Yes, I got the invitation, but I did not confirm it.” Which was true. The thing is, neither had they declined. In their opinion, they could have it either way up to the last minute.

As the organizer, I found this hugely annoying. Especially since this workshop was given by an external trainer, and was not exactly cheap. I felt the responsibility towards my company to use the money for the workshop in the most impactful way, and here were those guys opting out at the last minute, leaving me with a skeleton group of participants.

However, I can only change my own behaviour, not other people’s. This is why ever since, I make sure that everybody either accepts or declines the invitation. There is nothing in between. If people don’t want to decide, I will rather give the spot to somebody else who is willing to make a commitment and thus shows me that she appreciates the learning opportunity she is given.

Alternative: Overbook

My friend Samantha uses this approach out of experience. She holds a lot of workshops internally, and people cancel last-minute all the time. So what she does is overbook them. In general, if you cannot or do not want to hunt down every person who appears undecided, or if you have a strong feeling that some people will not show up anyway, then overbook the workshop. If there are ten spots, then invite 12 or 14 people or so.

The days before: provide reminders - lots of them

Even with an appointment in their calendar, people will forget about the workshop. Software developers (and most other people in the workplace) have a lot of things to hold in their heads every day, even without thinking about appointments.

Some people really need reminders and confirmation that, yes, the workshop is taking place as scheduled, and, no, you should not have competing appointments on that day. Sometimes, people accept an appointment quickly because, you know, it’s only in two weeks from now, should be fine. Then, two days before the workshop, they suddenly realize they are supposed to be at a client’s site on that very day, an appointment that has been agreed on for a long time. Tadaa, you have one participant less, and very little time to find a replacement.

Therefore, I write at least three reminder emails, roughly seven days, three days, and one day before the actual workshop. I try not to send out the exact same email out three times, but to vary it a little. For example, you can highlight a different aspect of the preparation each time.

Seven days before the workshop: General information, no competing appointments

“Hi all, are you looking forward to the test automation workshop yet? Only seven days to go. Please make sure you have no competing appointments on that day.

A couple of infos:

• Note that the workshop starts at 10am on Wednesday, but already at 9am on Thursday.
• Lunch break at 1pm on both days. Food will be ordered.

Cheers Tom”

Three days before the workshop: Install software

“Hi all, only three days left until our test automation workshop. If you haven’t yet, please make sure you clone the following repository and run the installation instructions:

https://git.intra.mycompany.com/repo/test-automation-workshop/browse

You will need this for the exercises during the workshop. If you face problems or difficulties, please let me know.

Cheers Tom”

One day before the workshop: Final reminder

“Hi all, tomorrow will be the first day of your test automation workshop. I will meet you all in Conference Room 4 at 9am. Please be on time.

In case you haven’t yet, please make sure you clone the following repository and run the installation instructions:

https://git.intra.mycompany.com/repo/test-automation-workshop/browse

You will need this for the exercises during the workshop. If you face problems or difficulties, please let me know.

Cheers Tom”

These reminders are full of redundancy, but this is by design. In the noisy world of everyday office life, you sometimes have to repeat things a couple of times until they stick. Obviously, this does not rule out people “forgetting” to install the required software, or people coming late. However, the odds now are on your side, and if it still happens, that person will have little room for lame excuses.

The follow-up

After the workshop, it is important to know if it was useful to the participants, or a mere waste of time. It does not matter much how you ask them, as long as you do it in some way: Ask them personally, create a quick online survey, write an email and ask them to reply.

The goal should be for the participants to learn something they are likely to use in their everyday work life. Otherwise, the acquired knowledge will soon be forgotten. So, if you ask only one question of the participants, it should be this.

Conclusion

Good workshops are valuable. Apart from the knowledge transfer, they also have a social aspect. Workshops bring people together. You end up in conversations with people you don’t meet that often. You help each other with exercises. In a big company, it is easy to lose track of who does what, and who has which expertise. After a workshop, you suddenly know a few more faces and names. This gives you new opportunities to reach out in situations where you need help, and might make you feel more at home in your organization.

But while workshops are valuable if used to their full potential, they can be an expensive waste of time when not taken seriously. I think the above hints can help: Ask people to either accept or decline the invitation, overbook if you feel that some people will drop out anyway, and rather provide too many reminders than too few. These simple actions will ensure maximum impact, and leave you, the organizer, with minimum frustration.

Time investment:

This blog post took me 2.5 hours of work, including writing, re-reading, and finding pictures.