Title: How Developers Can Better Deliver Training and Workshops Date: 2013-05-08 Tags: howto, effectiveness, speaking, presenting, training
Note that this IS NOT a PowerPoint How-To. Read a couple of those later (by people other than myself).
This past weekend, I attended the Kansas City Developer’s Conference (in Kansas City in case you didn’t have that figured out yet).
While I thoroughly enjoyed the conference and all of the sessions I attended, one thing that surprised me a bit is that I do not think most of the speakers had spoken in front of groups this size before.
That was very encouraging for me, as I was afraid the barrier to entry in this or any other event of this size would be way over my head, but I think I can be an asset.
But, it also leads me to this post. I was a bit amazed at how many times I saw the same mistakes repeated in each presentation or speech. It wasn’t true of every session or every speaker, nor would I say that one speaker made all of these mistakes.
Also, the only reason I know they are mistakes is because I have made them myself!
I have had the fortune of having some great mentors and coaches throughout my career so far; I’d like to share the things I’ve learned.
I’m not entirely sure, but I think it all starts with the lack of a feedback loop. I worry about suggesting that everyone should ask for feedback at the end of your presentation, but really, everyone should.
There were no surveys, no requests for feedback, nothing. Being that I love sharing my opinion, I gave my unsolicited feedback to a lot of people :-) And now, I’m sharing that with you as well. Well, that’s kind of your fault, you’re the one reading this! Going back over the KCDC site now, I see that Dusty Burwell and Boon Lee have added a link to give feedback. +1!
Couple that with the fear of speaking in front of people, a developer’s natural tendency will be to try to become a subject matter expert and put all of their effort into that, and not stop to think about how to effectively pass that information on to someone else.
So with that, here are some simple steps to improve your presentation or workshop. This is by no means an exhaustive list, but these are some of the recurring things that I saw this past weekend.
I kinda hate the DOs / DO NOTs, but that seems to fit here.
DO set expectations of prior knowledge / experience
Just like college, make sure that your class / session description properly sets expectations around the expected prior experience, skills, abilities, or interest of the participants. Also list any needed materials or pre-requisites.
DO NOT assume that anyone will actually read that!
Just like college ;-) So, you should start your session by addressing the crowd and assessing where they are all at. You can make subtle changes or speak to certain topics more when you have a good feeling of where everyone is at.
DO have a written agenda.
You do not have to include it in your presentation nor share it with your attendees, but it doesn’t hurt! And you need it for yourself so you can stay on topic and have a clear plan of where you want to take the people.
DO know what apps you will use ahead of time
And set up presentation modes / profiles in these apps. Better yet is a presentation VM, although if you need to hop into a tool you do not expect, that can wreak havoc.
DO NOT present code in Light text on a Dark background
It looks great on slides with little content, but for live code, it does not offer enough contrast at the size font you will be using. It’s hard to read at the back of the room.
DO make sure to enlarge the fonts of those tools from above
Most people remember to zoom on their IDE, but don’t overlook your text editor or terminal.
DO view your presentation from the back of the room
or simulate it the best you can. What looks good on your monitor will most likely be illegible at the back of the room, and the only way to know that is to test it out.
DO leave plenty of time for collaboration throughout.
Dictation is boring. I’m not going to listen. Neither is anyone else, especially with two to three solid days of presentations. You need to get people engaged and talking. Most people do this, or at least do not prevent it, however most do not plan in enough time for this.
If you practiced your timings and you come out at 50 minutes of a 1 hour session, leaving 10 minutes for Q & A, you need to go back and cut out material.
Change your presentation to be more collaborative, because even if you don’t, we, the participants, will. ;-)
Consider cutting half of your content out. You can always put it behind your questions slide or at the end of your deck, or leave it somewhere else as topics to fall back on in case you put us to sleep and we’re not talking and you finish early.
DO leave plenty of time for private discussions afterward.
If you are allotted one hour, then people have one hour to give, usually nothing more. Instead of trying to fill the hour completely, leave plenty of time for private discussions at the end. Consider 30 minutes of speaking / public interaction, followed by 20 minutes of private conversations or directed questions, and that allows people 10 minutes to clear the room and let the next person or group set up.
DO be courteous of the speaker or people behind you!
Whether you are presenting back to back, or you have someone at your company waiting for the precious conference room, follow the points from above and plan on leaving early. Yes, people want to hear what you have to say (I hope) but the meeting or presentation afterwards is just as important as yours, treat it and the next speaker as such.
DO NOT make your breaks too short!
It’s easy to think you only need 5-10 minutes for a restroom break, or 45-60 for lunch. But back to my point above, people are going to want to talk to you! Make sure you leave time for that PLUS time for you, as the speaker, to go to the restroom or take the five minutes you need to clear your head and regroup. Remember, developers suck at estimating time, make sure you’re not being too optimistic or aggressive with the length of the breaks.
DO NOT use your flashy new tools, show off how cool you are.
I won’t say that no one cares. The problem is, a lot of people do care, but they will notice it and be distracted, wondering what is that slick new tool you just used. You want them to be engaged in what the topic is, not your environment.
DO NOT talk outloud while you are flipping around or hacking something.
It’s bound to happen, a file is missing, a command fails, you brain-fart and have to get down and dirty. Don’t talk thought it thinking that people are going to follow you, they’re not. You’re just going to lose them, and then you’ll be even further ahead and have bigger problems. Instead,
DO take the time to regroup and explain.
When something does not go smoothly and you have to brute force it, so be it. But regroup. Take a deep breath, and then explain calmly and slowly what you just did. Wait (and ask) to make sure everyone is caught up before proceeding. And it’s probably good to take a note so you remember to clean that part up next time.
DO ask for feedback.
People clapping, or the lack thereof, at the end of your session could merely be appreciation for you putting out the effort. You need to know what they liked and what they disliked.
DO NOT Leave it open-ended
One of the worst things you can do is hand someone a blank sheet of paper or ask “What did you think?”. Most will not fill it out. You can provide an area or avenue for additional comments, but that should be additional.
DO NOT use a generic Q&A form.
Come up with specific questions about the material you just presented. Boring, generic questions offer you no insight into what worked well and what should be improved.
Did you go in depth enough?
Did you go too deep?
If it was hands-on, Were you participating along side? Were you able to keep up?
DO keep it simple and make it easy
There are apps available that let you text in your vote, and the class can watch the polling. There are few problems with these:
If people think it’s cool, they’ll be Googling it and not paying attention to you.
People may be more likely to vote following the trend.
Google voice usually does not support these apps,
But email does… and do you really want them looking at email instead of paying attention to you? Very few people can open their email and not SQUIRREL!
Instead, consider gasp pencil & paper! Or a survey at the very end.
As the note said above, this is not how to create an effective PowerPoint. There are plenty of tips and tricks around that on the web, and after you have considered the above, I highly recommend you read up on that.
But above all else, try to be mindful of your audience and do not run at full production speed. (Hello, pot!) Make sure that they are keeping up and are able to comprehend what you are saying. As mentioned in the book Slack and probably 5 million other places, people need to be able to practice first at a slower speed, be patient and slow down.