Lessons Learned Preparing and Presenting Tech Training Events

Monday, May 5, 2014

You've agreed to present a full day training event, and the day's approaching. What do you do?

I'm not a training expert, but I've learned a few lessons on the job over the past few years that I think will help. I'd done some technical presentations over the years, but in the 4+ years I've been at Microsoft I've been doing quite a bit more. I've presented at dozens of Web Camp events (both one and two day) all over the world, been in charge of the Web Camps Training Kit for the past few years, helped plan and present two Microsoft Virtual Academy events (both full day, almost 400k online views for some of the sessions). I've also presented some smaller training workshops to some development teams at some large companies as they were looking at making some technology transitions.

Most of these events went pretty well. Some of them, towards the beginning and despite my best efforts, did not go well. Here's what I've learned so far.

Different From One Hour Tech Presentation

I'm going to start with the planning stages in a second, but we need to get one thing out of the way first. A training event is significantly different from a one hour technical presentation. Many of the things are similar - you can start to get a handle on it by breaking an eight hour day into a series of eight one hour talks - but it's different enough that some things you can get away with for an hour won't work for eight, and vice versa.

Just a few of the important differences:

Expectations for the balance training vs. entertaining are different. When people invest a day attending training, they have higher expectations of learning something, whereas some attendees of a one hour session - especially at a conference or code camp - are just "channel surfing" and have greater expectations for entertainment. On the other hand, it's perhaps more important to strategically entertain / engage during a full day of training to break it up.
A full day of training is exhausting. I know an hour presentation seems tiring, but wait until you've done a full day. It's a marathon, not a sprint.
Organization and timing are more important. You might be able to get away with rambling and poor time management for an hour, but it won't fly when you're doing multiple sessions.

Note: Keep in mind that this post is focused on presenting several consecutive hours of technical training. Many of the recommendations I'll give will also apply to your standard one hour technical presentation, but keep in mind that I'm not writing about How To Give A Technical Presentation.

Planning

Ask Questions Early

If at possible, do a short pre-meeting before you get too much into planning. I generally hate meetings and avoid them when possible. This is a meeting you want to have. I get different answers in a meeting than I do in an e-mail thread.

Find out the following:

Who will you be speaking to (numbers, skill level, etc.)?
What do they want to get out of the day?
Get a list of specific questions and topics that they want to learn about.
What is the expected format? Is this presentation style (attendees passively watching speaker), workshop (attendees following along on laptops), a mix, or something else?
Will the presentation be filmed? It usually can be if you ask early enough.
What's the tech setup? What resolution will you be projecting at? What video connector?

Some Anecdotes on Planning

Planning win: A few years back I got a request for a day of advanced MVC training, but during a pre-meeting it came out that the team had no MVC experience and while they were experienced developers, what they needed was an introduction to MVC with a few additional, specific questions addressed at the end of the day after they were up to speed.

Lesson: Ask questions before (or at the very least at the beginning of) the event to determine skill and experience level, don't assume.

Planning fail: Probably my worst presentation ever was an ASP.NET MVC bootcamp I presented at a conference. Having spent a portion of my youth in the military, I'd assumed that the participants at a bootcamp would show up expecting to do some work. In what kind of bizarro world do bootcamp attendees just kick back and watch a presentation? None, right? Right.

So I prepared a long workshop style tutorial wherein I would guide attendees through building an application, completely revolving around them typing things into their laptops. I had a bunch of downloads prepared for them including checkpoints at the end of each section, etc. When I began the presentation, it quickly became apparent that none of my assumptions were correct. Many of the attendees didn't have laptops, many that did have laptops didn't have the development prerequisites, and everyone was expecting to watch me talk to them for half a day. It was horrible. Eventually I just had to give up on my plans, throw out my slides, and come up with something new on the fly. It wasn't good, but it was better than the train wreck my original lesson plan had become. Some left, some stuck around and I did my best to adapt, get those who wanted to follow along set up and speak to the rest of them. Years later, this still haunts me. I'm really sorry.

Lesson: Ask an organizer to make sure you're clear on the format. If you expect people to participate, make sure that's clearly communicated to them before the event. Assume people will be participating as little as they can get away with unless.

Get Another Presenter

Training is SO much easier if you have another presenter who can cover a few of your talks. You'll need breathers, and you'll appreciate time to review notes and set up your demos. Attendees will appreciate the break from watching one person all day, too.

This goes double if you're travelling to another time zone. It's really hard to keep focused and energetic when you're jetlagged. Breaks are important, and you'll be kept busy during scheduled breaks.

Preparing The Lesson Plan

What Matters: The End Result

Decide what you want them to get out of the day and let that drive your outline – not the feature list or demos you want to show off, etc. What will they remember a day after your talk? Focus on that.

Expectations for the balance of training vs. entertaining are different compared to a one hour presentation. When people invest a day attending training, they have higher expectations of learning something, whereas some attendees of a one hour session - especially at a conference or code camp - are just "channel surfing" and have greater expectations for entertainment. On the other hand, it's perhaps more important to strategically entertain / engage during a full day of training to break it up.

A lot of the value you're providing in a full day of training is in the higher level conceptual models and organization. You're not just working through the feature list, you're explaining why the features exist and how they work together.

Work From An Outline

As I mentioned earlier, an eight hour training course is just eight one hour presentations. It takes time an preparation, but you can do this. Let's look at an example breakdown an eight hour course on anything - could be on How To Make Ramen Burgers:

Keynote. You always need an introduction. Explain what you'll cover, set expectations, explain the high level roadmap for the day, cover prerequisites.
The Tools - Explain what you'll use, how it works, where you can learn more. (note: If you're thinking this doesn't apply, remember to adapt tools to the concept. e.g. for Node, this is stuff like NPM.)
The Concepts - Now that we're familiar with the tools, let's build something simple and explain every concept, ever step of the way. Remind advanced folks that we're going to speed up in a bit. Let them feel superior for being so experienced (and stay awake) by asking questions. Key point: the experienced people are not your adversaries! They are your allies, and a huge asset in teaching the class. Include them, don't battle them.
Deep Dive 1
Deep Dive 2
Deep Dive 3
Deep Dive 4
Wrap Up. Summarize what was covered, encourage everyone with what they've learned, give resources for going further. This is important for two reasons. First, you want to tie things up conceptually so they don't just leave with "Whoa, that was a lot of stuff. What was the middle thing?" feeling. Second, you want to make sure they can take advantage of what you just taught them, and learn more or get help.

Yes, steps 4 - 7 are not filled in.

But already you're down from 8 hours to 4 hours, and that's quite something.

Now, for steps 4 - 7, here's the idea. You are the expert. You've been asked to speak because you know something. You're really quite smart, and experienced. Right? If not, well... oh, dear, we should have covered that earlier. You'll really need to be somewhat experienced to do some training. If you're not, and you can't get out of this, hack like mad for a week or two to try to build some experience. Good luck!

So, you're experienced. What would you tell a friend who wanted to learn about this concept? Can you break it into four big things they should know? Either four main concepts, or a four step process? Great. From there, it's just four one hour presentations.

Here's what I currently cover at Web Camps:

Keynote
Introduction to ASP.NET and Visual Studio 2013 Web Tooling <-- The tools
Building Web Applications using the latest ASP.NET technologies <-- The concepts
Building web front ends using the latest web standards <-- Deep dive #1
API Services for both web and devices <-- Deep dive #2
Running, improving and maintaining a site in the real world <-- Deep dive #3
Real-time Communications with SignalR <-- Deep Dive #3
Wrap Up

Note: Presenting several presentations works best if there's a natural flow. In the above case, it's something like Create -> Build -> Deploy.

But be willing to make exceptions. For this example, you'll see there's one small thing that's out of order: Sessions 6 is post-deployment, and 7 is a dev topic. That is completely intentional, based on presenting this content a few times. SignalR is cool and exciting. It's a highlight, and it's fun to end on. Scaling and maintaining a site in production is really important, but it's hard work and requires more energy than most attendees will have at the end of the day. So I break my logical flow to put the hawt guitar solo at the end. And, honestly, to keep people from leaving after session 5, or at lunch time.

A Theme

You've been to technical training, right? It gets hard to keep perspective and focus after a few hours. One really useful way to simplify that is to have a common theme. For me, that's usually a common scenario: we're building a site that does X. It doesn't really matter what X is as long as it fits all of your scenarios and you can excited about it. Really, it should be something you can get excited about. Do you like golfing? Make a golf tracker site, not a Contoso Widget Inventory System. And definitely not a Foo app that tracks Bar and Baz instances.

Demos

Okay, let's start with the bad news:

The only way to keep people awake and interested in a full day training course is with a lot of demos.
It is exponentially harder to do a full day of demos than it is to do a single hour of demos. The hardest part is that you don't really get any set up time in between sessions, but even if you do it might get monopolized by someone with an obscure question who isn't thinking about the time it takes to set up demos for the next session.

So, just plan to give 8 presentations without any time in between them. (Note: Remember that I said it's great to have another presenter? Yeah. Any time another presenter speaks, it resets your clock. Gold.)

Begin / End States

Okay, we've built up some stress. You have to give eight presentations, you can't count on having any prep time between them, and they have to be good. What can you do?

Here's where prep can really help. The idea is that, for each demo, you have a begin state (where the demo starts) and an end state (the way the demo should look when your demo is done). This really helps with your peace of mind: for every demo, you've got a set place to start and - more importantly - a working demo to fall back to in case everything goes wrong. Just like washing your car ensures it won't rain, having a working (and validated) end state for each demo does wonders for both the demo and your peace of mind. Trust me. And, if you get nervous (like me) it's so great knowing there's a working example of your demo app in case things just won't cooperate.

You can do this using source control labels if those come naturally to you. For the Web Camps Training Kit, we just have subfolders with begin and end stats.

Strategic Typing

Think about what you'll be live coding. Does this add value? Does it teach people? Are you 100% certain you can pull it off without dealing with a minor typo here or there? Hey, if you're a ninja coder, more power to you. Run that kata.

For the rest of us, think of what you'll actually show, and what your attendees will profit from seeing. Forget about impressing them, focus on the actual value of having 100 or so people watch you type. As I've done this, I've moved to showing a lot of my demos as tours rather than "feats of strength" - here's what the code looks like, let's talk about it.

I realize I'm not going to impress people with this technique, or get high speaker ratings, or any of that. I'm okay with it. I have a limited amount of time, I choose to focus it on making my viewers successful rather than trying to make me successful.

But, recognize that just watching someone explain code can be boring, too. So I try to pick strategic bits and pieces. An easy way to interact with the code is to intentionally break it, or change output text.

Reset Scripts

Doubling back a bit here, but if you're going to give the same training several times, what do you do? The simplest solution is to have one source of truth, and you copy from that into a presentation directory each time. That totally works. The important bit is not to present from the source directory.

If you want to level-up a bit, you might want to write some scripts. The idea is to have three directories for each demo: Begin, Complete, and Initial. The idea is that your script copies your initial state directories over your presentation directory.

You Don't Have To Write Then All From Scratch

You don't necessarily have to write all of your own demos. More precisely, there's no perceived value to your students / attendees in presenting novel, amazing demos that don't actually accomplish something. Your demos should be optimized for the time and opportunity. Lately I've been building some simple code by hand, then showing a completed example someone else has published. I'll dig in to the code and show them how the exact concepts and code we used in the simple Hello World example work in a completed application.

Ask around - Twitter, social networks, co-workers, etc. Often someone has a great demo already written, waiting for you to show it off. That lets you focus on the presentation, not building a new demo from scratch.

Presentation

Managing expectations

Be really clear with expectations and roadmap throughout the day.

Show the outline at the start of the day and set expectations on what you will and won’t be covering.
Refer back to the outline regularly during the day – it doesn’t hurt to have a “you are here” at the start of each talk. It also cuts down on questions about things that will be covered in a later session.
Wrap up at the end – helps people digest what they’ve learned (as explained earlier).

Things make a lot more sense if you're providing the conceptual framework for attendees to file the content away.

Slides

There are different philosophies on using slides in presentations. For training, my opinion is that they can really help, and it's best to keep them pretty standard.

Here's what I think the slides should do:

Make it easy to follow what you're talking about by showing structure, showing frequent "you are here" signposts, and giving plenty of context.
Gives something for attendees to write down (or take pictures of).
Give the speaker some cues. It's hard to remember where every single demo goes in a full day of training. Some Demo slides that just show the title of the feature or concept can cue you in so you're not wondering what's next or forgetting demos.

The standard things apply - don't read slide after slide, don't make eye charts with tons of bullet points, etc. Use diagrams and pictures where possible. Use the slides to enhance the presentation, not as a crutch.

Rehearsal

It's time consuming, but it's important to take the time for a full rehearsal. If you're co-presenting, take turns presenting your sessions for the other speakers (screen sharing if you're remote). I know this is a big time investment and you won't want to do it - or you'll want to race through it - but this will really pay off.

Two big things to pay attention to:

Timing - You know how it's tricky to nail timing a one hour talk? Multiply that by eight. You need to know which sessions are running long, which ones can be sped up if you're running late, etc.
Demo Transitions - You'll want to make sure you're able to transition smoothly between slides and demos, that the demos actually work when you do them consecutively, etc.

Cheat Sheet

As you're rehearsing, make notes on a one-page cheat sheet. Mine usually include reminders about important bits of code or steps for the demos, anything tricky about the demo reset steps or setup, and important points I miss in practicing. I keep mine with me when I speak, and the fact that I know it's sitting next to me means I rarely really need it. When you do need it, though, it saves your audience from watching you fumble around. And it's handy to glance at during travel, as well.

Tech Check

It's a good idea to get in to the place you'll be presenting early to make sure that your laptop works and check the resolution and font size are visible in the back seats. Attendees shouldn't have to suffer through any of that. If you absolutely can't schedule it, at least find out the tech specifics and make sure you've got whatever video adapters you'll need.

It's All About Preparation

You'll notice that pretty much all of the above covers how to prepare for the event itself. There are a few other small tips for during the event (e.g. have some energy bars or Five Hour Energy handy, ask questions at the beginning to verify attendee experience level), but if you've prepared correctly then most of the actual presentation is already done. Just be the user interface for the content you've prepared. Disappear.