Presentation Styles

time to read 9 min | 1637 words

It is sometimes hard to believe, but I have been giving talks all over the world for quite a while now. It is said that practice makes perfect, and I think that practice has certainly made me a much better presenter.

The story about how I learned to handle public speaking is entertaining, and I get to tell it quite a lot.  But this post is not about that old story, it is about a new story. I have been doing a lot of presentations for a long while now, and I can track how I improved as a speaker since the beginning.

Detailed Bullet Points is probably by far the most common, and usually considered as flawed. This type of presentation is also referred to as Power Point Poetry. You can safely assume that I am not overly fond of this style.

Recently, I have leant much more toward the presentation zen style of slides. For that matter, I consider the slides a far third in the importance in giving a session. The first being the ability to actually talk and the second is good familiarity with the material.

Before the first & second, however, there is something that is far more important, at least to me. And yes, I am aware of the impossibility of priority zero. Language. I am not a native English speaker, and speaking in English, especially public speaking, is not something that came naturally to me. I still remember doing a talk and switching to Hebrew during the introduction without noticing...

But I have been practicing English quite a lot lately, apparently speaking only English for long period of times does help, and it shows. It got to the point where I sometimes automatically speaks in English, which I find highly disturbing at times. Oh, and if someone can explain to me the process in which I can select which language to talk, I would be grateful, I am extremely interested in that, but I have no clue how it works.

Anyway, given that you are actually able to speak coherently in the language that you are going to use, there is one important thing that you must do before you start prepping for a presentation. Decide what is your goal, given your constraints.

Constraints are things like:

  • What is the level of the people in the audience?
  • What is their familiarity with the subject at hand?
  • How complex is the topic?
  • How much time do you have?

The goal is affected by your constraints, not the other way around. And the sad thing is that often enough, it is so easy to get it wrong.

The basic problem is that most of the time, it is so bloody hard to get it right. It is easy to spend hours on a topic, because it deserve to have hours dedicated to it. But most often you have an hour or so, and that is it. And in that timeframe, you have to decide what you want to do.

Broadly, there are several options:

  • High level vision - what you can do, why you want to do it, how does this help you make your life better. In technical discussion, you might also want to be able to do a demo or two, but you keep it high level, and don't get mired in the code. The main goal is to give the audience the concepts and the understanding.
  • Introduction - show what is going on, demos, skim the surface, don't get too deep, with some minimum level of introduction to the concepts that are being exposed. The main goal is to give the audience an actionable start. They can go home and do something with this.
  • Detailed overview - this is a focused discussion on a specific topic. Usually this assumes some level of familiarity with the subject from the audience, and we can dive into the details and discuss a topic or two at length. Note that a topic is a small matter, but we can cover it quite well. The goal is to shine a spotlight into a particular area, and give the audience a lot more knowledge about it.
  • Blow their mind - despite the name, and the fact that I had done a presentation just like that very recently, I am not sure that I like this style at all. Somehow, I feel that this is cheating. Basically, in this style of presentation, you identify some problem that your presentation can help solve, and then you try to do the best demo you can to get an impressive result. The reason that I feel like cheating is that it is usually an non actionable presentation. You usually can do something with it right away, but you would need to do a lot more to get the real benefits out of this. This also takes a whole lot of time in prepping for this, and you have better be able to judge the audience and see if you get the appropriate reaction. If you can't keep up the pace of the presentation, you are going to flop badly.

In Oredev, I had done three talks, and a workshop, which falls naturally into each of those categories. Peter Hultgren has this to say about my Active Record presentation:

The best presentation was probably “Using Active Record to write less code” by Ayende Rahien, which was cocky and super motivating. Even though I have some experience using ActiveRecord, and pretty much knew about the features he brought up, I had the same “wow” reaction as everyone else did. If you can deliver an ad-hoc presentation which preaches to a converted and makes him want to re-convert, then you’re on to something.

Leaving aside being immensely flattered by him, that was a "blow their mind" approach, which I purposefully tried to stirred the pot. I assumed that calling everyone in the room a criminal would make sure that it wouldn't be a popular presentation, but apparently that was quite popular. The theme of that talk was Persistence is a Solved Problem.

As I said, this is a dangerous technique. Another talk that I did in this style was ReSharper in DevTeach almost a year ago. And that one is a great example of a flopped presentation. I wasn't able to keep up the wow effect, and I basically lost the audience midway through.

In Oredev, I also had the "Producing Production Quality Software", which was a high level talk. That one went well as well, and it mostly involved telling a story. The key part in this presentation is involving the audience. Since I am talking to a crowd of IT guys, it wasn't hard to get them to commiserate with my war stories about production failure.

I also gave a Rhino Mocks presentation, which unfortunately was at the last talk at the last day. Here I made a major mistake, I fail to read the mood of the audience as wasn't able to adjust as well to a crowd that was simply a bit tired to be fully participating. This is something that I should have handled better, which I hope that I'll be able to utilize in the future.

The interesting part about Oredev presentations is that we had only 50 minutes for each presentation. Most other conferences has an hour to an hour and a half. That gives the speaker a lot more time, and it made prepping for Oredev much more... interesting. On the one hand, it is hard to try to squeeze almost fifteen minutes out of a session. On the other, it does mean that you have a very succinct talk if you manage to do so.

That is another important aspect of the constraints that I mentioned before. Which style of presentation you use is greatly influenced by the amount of time that you have. In particular, for most people, showing code is the most time consuming process in the presentation, except writing code. And there is basically few things worse than leaving the audience hanging without any input from you while you are busy typing code.

If you can cut down the writing code part to less than 20 seconds without input to the audience, it will work, otherwise, you need to prepare ahead of time. Something that I like to do for my presentation is to do a lot of ad hoc coding. Sometimes it works, sometimes it doesn't.

When it does work, it tend to impress people. When it doesn't work, I crash & burn :-) I try to have a backup plan for such scenarios, but I need to actually notice that I need the time to move to it.  Another tip, you have ten seconds to debug a problem in your presentation, if you try to do anything more than that, you better back up, blame Murphy, and move on.

For that matter, watch the audience. You need to match the presentation to the people actually listening to it. Always start a presentation by syncing up with the audience. Who are they? What do they know about the subject? Tell them what you are going to talk about, how this is going to help make their life better.

In the timeframe of most presentations, you can't really give a whole lot of information. You just don't have enough time, and worse, you don't have a consistent audience, which would allow you to start from a level ground. What you can do, however, is to raise their interest. If after a talk I give, people in the audience go home (or on next Monday), and start looking up the things that I talked about, then I know that I have been successful.