BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Neal Ford on Giving Technical Presentations

Neal Ford on Giving Technical Presentations

Bookmarks
   

1. This is Brian Rinaldi and I am here with Neal Ford of ThoughtWorks. Neal, why don’t you introduce yourself?

Hi, I am Neal Ford, I am with ThoughtWorks, I have the little bit awkward title of director software architect and meme wrangler in that I wrangle memes and ideas form various places. It’s a side effect of ThoughtWorks allowing people to choose their own titles.

Brian: So, you’re presenting tomorrow on giving technical presentations, you’re actually giving a presentation about giving technical presentations.

That’s right. It’s a presentation about presentations.

   

2. What inspired you to choose this topic?

Actually, I just wrote a blog entry about this because that material didn’t make it into our book, Presentation Patterns. We ended up writing a book about this, I speak at a lot of conferences, I average maybe 50 software developer conferences a year for the last four or five years and I noticed that overtime, you can’t help being exposed to that many presentations, found the things that work really well, the things that didn’t work so well, and I am a software geek by my nature, so I tend to apply software idioms to the real world and so at one point I remember being struck by looking at this presentation, it was actually a print out of a presentation and it was a just long list of bullet points and I remember thinking to myself “if I was going to name that, I would name that Bullet-Riddled Corpse” and that was actually the first pattern that I came up with, so that was when I had this spark of idea that taking the game of pattern and anti-patterns approach of naming things and categorizing them and applying them to things in the presentation world.

And the anti-patterns thing, turned out, was the most useful side of that concept because some of the tools lead you down a really horrible path encouraging you to do things that specifically lead you toward ineffective presentation techniques, so we specifically wanted a way to call out things you shouldn’t do and things you should do. When I started discussing this idea with my two co-authors, Nate Schutta and Matthew McCullough, they, being software geeks like me, instantly latched on to this metaphor and for a long time we kind of sat on it because we thought it’s an interesting thing, but the audience for this book is a few hundred people in the entire world, but then we realized that PowerPoint, Keynote are the lingua franca of big organizations and that’s the way communication channels work in big companies and this is really more broadly applicable, so our big challenge was taking the patterns – anti-patterns concept and getting the non-software geeks to understand that and applying it to doing presentations.

   

3. The book is not purely targeted at, say, a developer giving a presentation?

No. It certainly encompasses that, but we shot for a much broader audience for all kinds of presentations. In fact, one of the reasons we didn’t make it a recipes book, because that is certainly something the general public would latch on to much more, we’re not actually giving you a recipe for doing a technical presentation or doing a keynote or doing a sales presentation, the advice we are giving is actually one level of abstraction deeper than that and less specific than that, so we are talking about the building blocks by which you would make a recipe to build a keynote or technical talk. So, the patterns that we are talking about are actually widely generic across all kinds of presentations. For example, one of them which I make heavy use of is a pattern we call Context Keeper where you if you are talking about some subject that is going to last for a series of slides, keep some little visual icon around so that keeps people in mind “oh, this is the agenda item we are on”, that keeps the context for that whatever that subject is. And that works across any kind of presentation you are doing because that is just about keeping things in mind without being too proof about it.

Brian: Sure. That is even a common thing in UI where maybe you can even color code some things so that it’s a visual cue that you are in this particular section of the site.

That’s right. Colors are context keepers, that’s one of the applications of the context keeper pattern. So we shot for getting one level below specificity in terms of what kind of thing you are building, but really talking about building blocks for all kinds of presentations.

   

4. Obviously, you have the book and you’ve seen a ton of presentations, what are some of the things, a few tidbits you might say that make a good presentation?

Ultimately, at the end of the day, there are two pieces of advice I give people when they ask me just what out of the blue advice I can give them. One of them is this pattern that we call Narrative Arc which is really this idea that a presentation should tell a story, because at the end of the day it’s about storytelling. Even if you are doing a technical presentation it needs to have a beginning, a middle and an end, it needs to reach some conclusion because that gives closure and people, when they hear stories, they like having closure and the more story-like you can make it the more it appeals to people, because what’s one of the first things you do to little kids? You tell them stories.

We are used to hearing stories that have outcome, so we are wired for that as people. And so, that’s one way, to make sure it has a narrative arc, and I actually give a few examples of taking really hard core technical presentations, but just like a novel, Henry Miller, the novelist, has a famous quote that says his job is to introduce a protagonist, run him up a tree, throw some rocks at him and getting him back down the tree, that’s basically all of literature is that, and so even when giving a technical talk you need to bring some challenges that you can overcome by some clever application of technology that resolutions the same kind of resolution you get when a hero overcomes a villain in a story. The other piece of advice I would give which is one that I kind of borrowed from Garr Reynolds, in his really terrific book Presentation Zen, which was kind of a precursor to our book, but was a little more abstract than ours. We are software developers, so we are very concrete, we wanted actionable things and most of the other books in this space are not very actionable. But one of the things that he said that really resonated with me was, particularly with the Bullet-Riddled Corpse anti-pattern, that basically when you are communicating with people you have two channels of communication. You have a verbal, logical, linear, temporal kind of communication and you this emotional, kind of knee-jerk channel of communication, and if you are speaking to a group of people and showing a bulleted list of the things you are talking about you are overloading the verbal, logical channel, and starving the emotional channel, which is what makes them boring, because that part of your brain gets restless.

And one of the things you can do is add visual interest, one of the things we talk about, particularly in talks, that one of the key purposes is entertainment as well as exposition like keynotes is that, after you’ve built the keynote, go back and see can you insert something humorous every seven or ten minutes or so, or something surprising, or something that will hit that visual channel or that non-logical channel, because that keeps people engaged and entertained for the whole thing.

Brian: I’ve noticed some of the ones that I like, some of the speakers I like, get that often from relating something that they are talking about, that is technical, to a personal narrative, so you learn a little bit about the speaker, it touches on that emotional aspect of things, it’s not visually necessarily related but it’s like an anecdote from their personal experience.

During my workshop tomorrow morning, my presentations patterns workshop, the thing that I use throughout that workshop is that my wife and I throw this insane Halloween party every year and I have these really, really incredible Halloween pictures that I use as kind of intermezzo slides between subject matter for exactly that purpose, it’s anecdotes that I can tell along the way, that don’t necessarily have to do with presentations, but it is about creativity, we ease into the story, and each one of those ease into the presentation and back out into the stories that you are telling, so, I am using exactly that mechanism in a lot of the presentations.

   

5. You said you talk a lot about anti-patterns. Can you relate some things, particular mistakes that you’ve seen, common mistakes that can ruin a presentation?

Well, certainly, one of the anti-patterns that we talk about is the Cookie-Cutter Idea Size anti-pattern, that for some reasons presenters get it in their head that slides are really expensive and you want to use as few as you possibly can in a presentation, so they cram more and more information onto a slide. In fact, here is a classic example of the kind of anti-pattern we talk about that tools generate. If you’re in PowerPoint and you fill in all the room you have in the text box and hit enter, what does it do? It just makes everything smaller and lets you keep typing and keep typing, that’s the opposite of what it should be doing, it should be actively discouraging you from ever doing that. But it tries to encourage you to do that, so what we try to get people to do is that an idea is a slide, and sometimes some ideas last more than one slide and, so one of things you can use with the presentation tools is the transition between slides to tie some slides together and separate other slides. For example, one of the transitions I use a lot is this fade transition, one slide fades into the other slide, but then when I reach the end of a subject area, I use a much more obvious transition like a push or a cube or something like that that indicates “ok, we’re done with this part of the subject area”. Don’t get caught up with this idea that every idea has to fit on a slide or that you can’t stretch an idea out across lots of slides, you can actually tie slides together using animations and transitions, much like the presentation tool Prezi does, with the kind of swooping in and out kind of effect, that’s what it’s doing, it’s tying those things together for that kind of unifying presence.

   

6. I’ve been a presenter sometimes myself and I was even mentioning to you earlier that one of the common things I face isn’t so much the slides, it’s about getting that mental voice to shut up while I am trying to present. What other things like that, are there common issues that you’ve seen presenters face, beyond just the slide deck?

Absolutely. We actually broke the book into prep your material, build the slides, then do the presentation, there are three distinct steps in the process. And so one of the things, we weren’t trying to be too concrete in the book, one of the things we recommend people do is actually practice the talk four distinct times and each time has a specific purpose in mind, about timing, about being able to get out of your head and not worry, just flow and see how it goes and evaluate after the fact. We recommend people videotape themselves, because a really common anti-pattern that speakers have, what we call the Hiccup Word anti-pattern, it’s some little word that they say over and over and they don’t realize it, it’s this little place holder word that they say, mine is actually, if I am really in a hurry or if I get nervous, I start using the word actually way too much, I know that I do that, I have to consciously keep myself from doing that.

That’s important, to videotape yourself, just the practice of being able to do it over and over in a lot of ways gets you out of thinking about it too much. And there are also some other tricks, my friend Venkat Subramaniam, one of the tricks he does is take his shoes off when he does a talk and that tends to relax you, if you’re not wearing your shoes, if you’re just walking around on the stage barefoot tends to relax you more and tends to make you let go a little bit.

There are little rituals like that, I know a really well known speaker that is always getting dry mouth, he was always concerned about that, so his little ritual was get two full glasses of water and sat next to him in case one of them spilled he still had one of them, that was enough to ease his mind, it was “ok, now I can handle this”, little things like that that we end up finding. And in fact we sprinkled little anecdotes all through the book to break up the book, pattern books tend to get very choppy, and so we wrote these little stories of our experiences and some of our friends’ experiences, one of them was Shoeless Subramaniam, which is Venkat and his penchant for taking off his shoes, little anecdotes and tricks that people have used.

Brian: It’s funny you mentioned the words, I umm a lot, I noticed that when I present, I don’t have a word I pick on, but I have actually been to presentations where the person, it’s been distracting, they say a particular word so much that you lose sight of what they are saying, all you are hearing is that word.

I have a colleague, his hiccup word was frankly, and he would say frankly over and over again, especially when he got nervous, so we had this big meeting in front of clients, he was kind of the MC of the thing, we were sitting around waiting for our turn, so I started counting frankly’s, just as a way to pass the time and then in an hour when he came and sat down, I said “Scott, you said frankly a lot”, “yes, I was kind of nervous, I think I probably said a lot, what was it? 10-15 times?”, I said “53 times” in an hour and he had no idea he had done that, it’s so easy to do, that’s why it’s really critical to watch yourself on tape which is initially very, very painful, but that’s part of the chore of becoming a professional speaker is get over that to watch yourself and get feedback. And that’s at the end of the day the secret ingredient to getting better in any kind of skill is to get real feedback and you can give yourself feedback by videotaping yourself and seeing the things that are annoying that you are doing and don’t realize and stop doing it.

Brian: So, back on the topic of slide decks, as a speaker myself, I’ve struggled with, I tended earlier to put too much information on a slide deck, as something you have already touched on. There are a lot of speakers now who have gone completely the opposite direction and put almost no information on the slide deck and I am not sold on that.

But, see, it depends on what the purpose of that presentation is. All of my presentations, on purpose, make no sense as a stand-alone document, because I am not building them to make sense as a stand-alone document, because if you make them to make sense as a stand-alone document, which we call the Slideument anti-pattern, then is not going to be as effective as it could be as a presentation. It goes back to what I was talking about before, there are two channels, if you make it a whole thing, a whole document you have to put both channels on it, which means it’s going to be less effective as a presentation, more effective as information. I purposely want mine to be this kind of two-headed thing.

   

7. [...] What are your feelings on those, I mean particularly, are you fine with whatever format?

Brian's full question: Speaking again on the topic of slide decks, one of the things you also brought up briefly is that there are also these new types of slide like non-PowerPoint, non-Keynote presentation formats, there are even a lot of technical presentations, they are even starting using HTML slide decks and things like that. What are your feelings on those, I mean particularly, are you fine with whatever format?

I am perfectly fine with those, Prezi is very popular and that’s actually just an implementation we call the Cave Painting pattern, so we actually came up with that pattern and then we realized that Prezi is an implementation of that and we figured out ways to do some of those same techniques in Keynote, so really that is just a context keeper kind of pattern, the zooming in and out. We’re actually ok with all kinds of alternative formats, our biggest headache with particularly many of the early efforts in HTML, JavaScript world are mimicking the worst parts of the existing presentation tools, they make it really super easy to create really dull bullet point slides and I never want dull bullet point slides and it makes really easy to create something that I think it’s really horrible and that is not useful to me, I really leverage all the transitions and animations and all that stuff because when you start using those you, that’s when you start turning it into a tool that assists your narrative and so I am really waiting for those kind of tools to get better and better at that. We constantly poke around at them and play with them because I would love to get out of, as much as I use Keynote, it’s a love- hate relationship, there are many, many, many things I would change about it and fix, so I am always looking for alternatives, I haven’t found anything yet that gives you the visual richness you have to have to really push the envelope.

Brian: I completely agree with you, because I did a number of HTML presentations for a while, but I felt like visually they were boring and it didn’t lend itself to easily creating attractive, it was just simple, it was easy to do text and bullet points and code, but even adding any kind of visual, any kind of animation or transitions tend to be a little bit difficult.

It’s a difficult job. And back to your earlier point, you’ve come full circle, one that they do kind of accommodate but people don’t seem to use very much is the Takahashi or Lawrence Lessig style, where you may have seen some keynotes where just one word or image going by really fast, there would be hundreds of slides. You could actually do that on top of some JavaScript, but not a lot of people, most people doing that in the heavy visual tools not in a barebones kind of world, that visual style could be accommodated in a more barebones tools, but it doesn’t seem like a popular thing.

   

8. My last question is something fun, well, it’s always fun to watch other people’s struggles sometimes, you feel guilty about it, but at the same time, you’ve probably seen your fair share or given ones that have gone horribly wrong, do you have any anecdotes you can share about a particular fail or some lessons you’ve learnt from it, things like that?

Absolutely. One great one that ended up generating one of our better patterns, I think, and this back from, I’ll change the names to protect the innocent, this is back many, many years ago, back in the late ‘90s I used to speak at a lot of Borland conferences and they had this brand new piece of technology out I think it was called Zurick, the idea was, there was this terrible idea from a technology stand point anyway, it was a way for .NET applications to call EJBs using CORBA as the bridge, basically every kind of middleware on earth working together on this Rube-Goldberg-esque kind of thing and it was in beta and they wanted to demo this thing. And so, they tried it on the opening keynote and it crashed.

They tried it on the second day and it crashed, they tried it on the third day and it crashed and so they had one shot left to try this thing and the powers to be told this guy “you have got to get it to work, this demo”, but the problem was this software was non deterministic, it would run three times then crash, just couldn’t get it to work and, so in a desperation late at night what he did was took a screen shot video of him interacting with the software working correctly and then did it on stage the next day as if he were doing it live, he was just playing this video he had made in his room of it actually working, but we actually realized that’s a much better way to demo software at a conference, we call this now the Lip-sync pattern, because you are relying on the fact that the Wi-Fi is going to be working and every part of your software is going to be working and that you can click through and get everything perfect while explaining what you are doing to the crowd and how you are going to react when things break.

It’s much better just to record that beforehand and now you can talk over the top of it and explain what’s going on and speed up slow parts that are not relevant to what you are trying to get to but have to be there for other things, this is a really powerful pattern and makes for a much more impressive presentation. It’s not nearly as sexy as going up there and banging out something that works fantastically, but it’s really terribly unsexy too to have to type and backspace and type and backspace and watch things crash and burn, and that’s not really helping your presentation in many cases and so that terrible lesson has lead us to what is really effective, we do this in most of our presentations, use this Lip-sync pattern.

Brian: Yes, in fact I know that pattern, there’ve been times I used it because that I’ve found that first of all the live coding or the actual live demo where you are doing it takes up time often doing things the audience doesn’t need to see, number one, and number two, what are you proving anyway? All they want to do is see how this works, are you just proving to them that you are not faking it? If you were faking it, you shouldn’t be there in the first place.

Very often it’s ego-driven, showing how good I can do, but here’s a really common thing, so the professionals that do this, like Venkat Subramaniam, make it look really nice. But here is what you do, you are sitting in your cubicle and you can bang this out, you are a really good typist, but now you are on stage in front of 200 people and they are all watching you type and so that makes you nervous, and what you do is speed up which makes you make mistakes, which makes you more nervous, which makes you “now I’m wasting a lot of time making mistakes” that makes you speed up even more, now you are in this death spiral on stage in front of a group of people; you don’t need that grief, why are you adding that much pressure on yourself when you can sit in your cube, where it’s nice and quiet and get the perfect version of it working and captured, and now on stage you can talk about the perfect version of it and all the points you want to make about it, rather than walking this tightrope in front of an audience; that’s just too risky for me.

Brian: Yes, I would say some of the worst, the biggest presentation fails I have seen, fortunately I haven’t had one go like that for me, but where the demo failed it just derails it, and then you end up debugging in front of an audience, and the audience is watching you trying to fix your coding issues and other things.

If you’re teaching how to fix broken things, it’s illustrative, but it’s probably not your purpose, you wouldn’t be giving the talk in the first place.

Brian: And the other thing I’ve noticed, the presenters generally don’t have a sense of how long they’ve spent fixing it, they think it’s just been a matter of a couple of minutes and the audience is like “it’s been ten minutes you fixing this and you just lost track”.

There is nothing more excruciating than watching somebody trying to fix something in front of a crowd. I have very little patience for watching people type live because it’s such a waste of time, such a waste of my time as an audience member, I’m paying to watch someone type? I can watch people type a lot, I’d much rather use to get on with whatever is on. And so using Lip-sync the point we make is you can get a lot more material in an hour long talk if you never spend time typing, because that is a really slow, inefficient way to show people stuff is to build it from scratch in front of them. You’d actually get a lot more exposition out of talks. Q1

Brian: Well, it’s been great advice, I really appreciate you sharing with us and sounds like it’s a lot we can learn from the book.

I hope so, we enjoyed writing it and enjoy doing the workshop, so I’m looking forward to it tomorrow.

Brian: Thank you.

Thank you.

Jan 06, 2014

BT