In my speaking career so far, I’ve been fortunate enough to be accepted to give a couple of workshops at RailsConf in 2015 and in 2019. A few times since then, I’ve been asked for advice on how to put on a successful workshop at a tech conference. This post contains what I’ve learned, and I hope you find it useful.
A Note: Recent world events might make a post about conferences a bit less relevant. I haven’t tested these approaches as much for all-virtual workshops, but my honest belief is that techniques like using worksheets actually become more important for a virtual setting. I’d love to hear from anybody who tries these ideas in a virtual workshop setting.
My Best Advice: Worksheets
If I get exactly one idea out there, let it be this: You should make detailed worksheets for your workshops. And I mean detailed, a good standard you should attempt to reach is that someone who has no particular background in the topic area (for e.g., somebody non-technical) can complete the workshop regardless simply by following the instructions one by one. This is a very difficult standard to reach, but if you try to get there, you’ll have a much smoother experience overall with fewer repeat questions. The work and testing you put in to a workshop’s worksheet will shine through in the overall quality as well - you should test it many, many times.
Worksheets help your audience with varying experience levels, late arrivals, people who want to leave early, or even people who have computer problems and fall behind. An attendee who falls behind your pace of presentation can catch up and finish successfully. An attendee who finds parts of your workshop very simple can finish those portions quickly and help their neighbors. Somebody who really wants to see a talk that intersects with the second half of your workshop time can leave early and finish later. These are all good outcomes that may not happen if your participants need to follow your presentation to complete the workshop. It also takes a lot of pressure off of you, the presenter.
As an added benefit, you can add bonus exercises that don’t find in the timeframe of the workshop for people to do in their own time if they wish. You’ll be surprised how many people finish the bonus exercises during your workshop!
Finally, it makes your workshop scale. People can do it on their own time if they don’t wish to attend your workshop in person. You’ll find people doing the workshop years after you’ve presented it, which is a good feeling.
For an example, I really like how my http://railsconf2015-aws.s3-website-us-east-1.amazonaws.com/ worksheet came together.
My Second Best Advice: Testing
Creating a workshop is really, really hard. You cannot wing a workshop and have it go well - at least I can’t, and I don’t know anybody who can. You will underestimate the level of detail you need to provide for a workshop to work successfully. You will forget small steps that are obvious to you because you’re close to the material, but that will completely stop a large number of participants in their tracks. You will not realize that installing one particular library in the toolchain can take half of the length of your workshop, because you’ve had it installed for months or years.
This is where it’s really important to consider your target audience. If you’re catering to experts, test your workshop on both experts (to ensure they find the workshop useful) and beginners (to ensure your workshop is accessible to people who will show up). If you’re catering to beginners, you should strongly consider testing on somebody who is entirely without a background in the topic area, to ensure your instructions are sufficiently detailed.
Part of me really wishes I had video of the “first dry run” of the workshops I’ve given. The first dry runs are universally terrible and disastrous events. It’s an absolutely eye opening experience, and testing until the workshop appears to be a smooth operation is a great way to ensure you won’t experience the “first dry run” experience in front of an audience of strangers.
It is difficult to fit your material exactly to the length of a workshop. A workshop is shorter than you think it is just by looking at the time slot, but every participant will have a slightly different experience. I’ve found the answer to time limitations to be twofold:
- Practice the worksheet many times, and get a good idea of how long it takes you when working at a deliberate pace. Have at least the workshop’s length in material.
- Mark the back 1/3 or so of your material as “Optional” or “Bonus”. This ensures that people who breeze through your workshop will have something to do, while accounting for the expansion of time that tends to happen when you’re presenting the workshop to a crowd.
This formula has worked really well for me. If you test your material and have a detailed worksheet, you should find that most participants complete the planned sections, and more than a few complete it all.
A hot topic in tech conference workshops is the “installation” phase for technical workshops. You’ll hear all about conference wifi, and often get promises about how conference organizers will ensure that participants in your workshop will be pointed to your all-important preflight instructions.
First, you absolutely should provide your preflight installation instructions via multiple avenues, for e.g. registration pages and social media. Give your audience every opportunity to install ahead of time. Then, anticipate that for whatever reason, they won’t do this.
Second, have some sympathy for why participants won’t have installed things ahead of time. Maybe they chose to come to your workshop at the last minute. Likely, they’re very busy with conference social events, or needed some distractions from all the technical topics flying around them and didn’t get around to it. In short, prepare for many participants to not have done anything in advance. An obvious solution, as much as possible, is also to minimize dependencies. If it takes an hour to get everything up and running, somebody is going to have a bad time no matter what you do to try and help them through.
I like to handle this by doing a short presentation at the beginning of my workshops, and actively encouraging people who need the time to do installation work to ignore me and do that. If you’ve given people detailed worksheets, they should be able to catch up anyways, and this won’t be a very big problem. Worst case scenario with a disastrous conference wifi situation, some people will leave and try your workshop later.
A Good Workshop is a Launchpad
When you look at a finished worksheet, it should feel like you’ve created a high quality 101 + 201 guide for a topic, and given hints as to where somebody could self study to go even further. You are time constrained in a workshop, but a worksheet isn’t, and you can create as many “next steps” hooks as you have time for. The process of paring down dependencies will make your “101” lessons a lot crisper, because it forces you to think about what’s important for a starting point.
Don’t try to teach every single thing about a topic. Rather, find a common sticking point and take your audience step-by-step past that sticking point, and then tell them where to go. Happily, you’ll find that many people will take a little bit of knowledge and go really far with it. Find a sticking point and focus really hard on breaking through it, and you’ll have made something valuable.
(Thanks to Noah Gibbs and Ernesto Tagwerker for their feedback on drafts of this post.)