Advice for Public Speakers
A friend of mine asked me for some pointers relating to giving technical talks recently. We had a great discussion and I thought that some of the advice was general enough that I would share it here. Many of us are involved in user groups, and we (as a community) owe it to our other members to help everyone learn.
Of course, I’m not the world’s authority on speaking, and I have quite a bit to learn. I want to hear your speaking tips as well.
Tell a Story
View your talk as a story, in the literary sense. This has a lot of implications in your talk. First, think about books you really like (or even a movie). The very beginning hooks the audience immediately. You may not know much about the story yet, but you are hooked. You need to know more. OK, I admit that very few tech talks have the same hook as “Raiders of the Lost Ark”. But still, work on the hook as much as you can.
Next, continuing the ‘story’ analogy, consider the different components of your talk as characters in the story. Your story (at least for this talk) revolves around one topic. All other topics. are supporting characters. They are part of the story, but they have supporting roles. Do not spend more time on these supporting roles than they deserve. That limits your ability to tell the main story. These supporting characters can be covered, but only in such as these supporting characters tell your main story. Look through your slides, and your samples and look for opportunities to focus on your main story rather than these supporting characters. For example, if your talk is about C# 4.0, you may use a Silverlight application to demonstrate the features. Concentrate on C# 4.0, not Silverlight. (Of course, if your talk is about Silverlight, you do exactly the opposite).
Everyone Needs Practice
Listen to yourself. Do you have an verbal tics? ‘Um’, ‘So…’, Most of us have them. Work on minimizing those tics. They will hurt your delivery.
Mix up the slides and demos. Almost all great speakers split up the cadence of their talk. They do some discussion. Then some demos. Back to slides, or a story, and onward. Staying in any one of those styles for too long will lose the audience.
Demos need the Most Practice
Let’s talk about demos. That is the hardest part. It’s hard because we usually don’t speak while we are coding, and no one likes ‘dead air’. That’s why I use the trick of saying what I’m coding. It avoids ‘dead air’ and I’ve never been able to code one thing while saying something else. It’s usually something like:
“I’ll new up a List of Employees so that I can run a few queries. We’ll have to initialize it with some data. (see note one below). Now that we’ve got a collection let’s find the most expensive employees. That’s a query from emp in employees where salary is …”
By talking through the code, you can keep your focus.
Note: some code is not relevant to your talk, like initializing a collection with a bunch of values. Use a snippet, or already have that written. When you practice, you’ll spot these. They are the bits of code that you don’t want to talk about, because they aren’t part of the story. Just put them in place, and move on. It will give you more time to talk about your main story.
Have the crutches handy
There are two crutches I have ready all the time:
- Snippets for bits of code I forget. Everything I type is on the snippet clipboard, in case I forget something. I try not to just paste code, but it helps to know that I can grab those if something bombs.
- The finished demo somewhere on disk. I’ve often forgot some small bit needed to make the demo work right. It’s easy to do on stage. And, when a demo doesn’t work, it’s easy to get really nervous really fast. Therefore, I always have a way to get to the finished working demo quickly. When the demo bombs, I’ll try to fix it once. If I can’t get it working with one quick session, I punt and say something like “I must have forgotten something, so let’s load the finished solution and look at it. We’ll find what I missed, and you’ll never forget to do that again. Especially if forgetting it means your demo doesn’t work and look foolish on stage.” Then, I load the finished solution. I run and prove to the audience that it works. Then, I look at the code and explain what’s in the pre-loaded solution that wasn’t in the demo that broke. (Trust me, it’s really easy to find.)
Finally, you have to use the big font. And, you have to practice with it because that will make sure you format code so it looks good on the big screen.
The more you practice, the better you’ll be. Talk to any experienced speaker, and you’ll hear stories of when that person gave a talk that felt like a failure. They are great speakers because they learned from that experience. Everyone can do it, but it does take practice.