How I Prepare My Conference Talks
A simple guide that might (or might not) work for you.
I have been giving speeches at conferences, user group meetings and private gatherings, every year non-stop since 2006.
My first talk at a large conference was during the Microsoft TechDays in March 2006, in Geneva, Switzerland. I actually gave two different sessions in that event: once about SharePoint 2005, and then about LINQ. Souvenirs, souvenirs. Hard to believe it all started more than 10 years ago! In the meantime I spoke in events in Denmark, the United Kingdom, Sweden, South Africa, Bolivia, India, Germany, the Netherlands, Ukraine, and of course Switzerland.
Unfortunately I do not have videos of my first interventions, but I can tell you with confidence that I sucked. Badly. Those talks were painful, both for me and my audience, and my slides were strictly horrible. My apologies for such a treatment.
The Lessig Method
And then one day, I came across this video, and it changed my speaking life forever; go on, watch it, I will be waiting for you right here.
This video made me realize that there was a different way to give presentations. There was another world out there! Things could be different, and I just did not know it. The “BSD is Dying” talk just blew me away, in both form and content.
I later learnt that the structure of that talk has a name; it is called the “Lessig Method” of presentation, and it was formalized by Stanford law professor Lawrence Lessig, also known as the founder of Creative Commons.
The Lessig style, similar to the Japanese Takahashi Method, consists of a long sequence of slides with just a few words or an image, some of which are sometimes only visible during a few seconds. The idea behind such a visual presentation is to yield the power to the story told by the speaker. You have to know your script at any given time, so that your words and your slides are in perfect synchronization.
Then I came across Scott Berkun’s speaker checklist, and I started printing out one copy before every single presentation I have given since 2011.
With all of those elements in hand, for the past few years I have been following these steps to give a great presentation:
- Write the speech.
- Create the slides.
In the following sections I will describe each step in detail.
1. Write The Speech
Needless to say, this is the hardest part of the process, usually bundled with self-loathing, procrastination, alcohol, progressive rock, late night typing, suffering, headaches, suicidal thoughts and other niceties. I repeatedly ask myself why, why, why did I accept to talk at this conference again? and stuff like that.
It is normal. It did happen. It will happen again. I know it. I came to the conclusion that I cannot avoid it. So I go through it, I embrace it, and I cry, and I let it all out. And in the middle of that storm, I see sometimes more clearly, and ideas start appearing in my head.
My speech writing process happens in Ulysses through my beloved Das Keyboard 4 Ultimate (I am badass like that.) I live a life in Ulysses, both in macOS and iOS. You can use any other application of course, but this article is very selfish and it is about my own method; you must find your own workflow, and this one suits me very, very well.
In Ulysses I start by opening a new group for the talk, and inside that group I create another one called “Notes,” or sometimes “Research.” Inside of that group I throw everything I find, in disorder, including links, images, code snippets, text, quotes, book references, anything that I find interesting for the subject at hand. All works.
Then I start imagining myself on stage. I imagine the light, the size of the room, etc. This is important for me as it is not the same to talk in a small meeting room with 20 people than in a large cinema with hundreds of attendees (as it happened to me last weekend in Dnipropetrovsk, Ukraine during the UMT 2016 conference.) The pitch, the movements, the expectations of the audience are all different. The speech reflects that. I usually ask the organizers for information about the venue (size, light, etc,) so that I can imagine myself on stage.
Then I start outlining the speech itself. And when I say outlining, I mean actually creating a very simple structure, a skeleton you can fill up with information later on:
That is it! In the introduction I explain what I want to say; in the body I say it; and in the conclusion I summarize what I just said. I swear, it is always the same. There are no secrets.
Using the skeleton above, I start sketching the ideas of what I want to say. I like to create presentations that actually trigger emotions and action in those who watch me, so I tend to offer “action items” at the end of the conclusion, so that my audience feels as a part of the process. The emotional connection with the audience is a factor that many speakers leave aside, and it shows when they present.
Writing a speech for a 40 minute long presentation takes me around ten days; five days of pure typing without restrictions or structure, and five days of edition. At least. The image below shows that my talk “Refactoring iOS Projects” is about six thousand words, which, spoken slowly, would last for around 35 minutes.
The timing estimation in Ulysses, in my experience, is in average five minutes too optimistic; for example, delivering my talk in Ukraine took me around 43 minutes. Pay attention to this; however, I still think the time estimation is a good mechanism to keep track of how much text you have written.
During the edition phase, I often print the speech and go through it in a separate location, like a coffee shop or on my balcony, so that I can pinpoint weak paragraphs, redundant phrases or just plain wrong facts that might have slipped. The edition phase is extremely important and I always factor time for this.
In summary, I write as if I was going to publish my speech; which is something that I have done, for example with my speech “Being A Developer After 40” which I suppose you have seen being shared around, and which is by far my biggest “best seller” to date. And since Ulysses natively supports publishing in Medium, it all works beautifully well.
2. Create The Slides
If I am giving a presentation that does not involved source code, I also use Keynote. But Deckset is just much better for presentations that include source code snippets.
During the creation of my slides I use the following workflow:
- Highlight words on speech.
- Create a slide per each highlighted word.
- Add images, code, links whenever appropriate.
As you can see it all starts with keywords; I just highlight on paper, with a highlighter pen, the most important ideas in my speech, and then just create a slide for each of them, with the word in it. Deckset makes this process very simple.
Then, for each of those slides, replace them with images, emoticons (I love the emoticon support in Deckset!) or code snippets, as required, to support the flow of the speech.
I rinse and repeat, of course, as many times as needed. I rehearse at any point, just to get a feeling of how everything is coming along.
It might happen, during this process, that I figure out that something in the flow of the slides does not sound right; I then go back to the speech. I always consider the speech to be the most important part of the whole process. If the speech is right, the slides will follow. If the slides quite do not work, then maybe the speech is wrong. The slides always follow the speech. Always.
Finally, in terms of timing, the creation of the slides usually takes me around five more days of work.
As as example, you can check the final slides of my presentation “Cocoa Is The New Carbon” right here:
The Markdown “source code” of these slides is available as a Github gist as well.
This phase usually happens at any point of the process, but I schedule some time for “final rehearsals,” ideally in front of somebody else (my poor wife!) or if all else fails, in front of a camera. I sometimes use my iPhone mounted on a smartphone tripod, so that I can see myself later, and have some feedback about my performance.
I like to have at least five full-blown rehearsals before the day of the presentation, and sometimes perform one more on my hotel room the morning of the event. It gives me confidence, because I badly need it; in spite of the amount of times that I have given speeches, I am still terrified every single time.
I cannot stress how important it is for me to rehearse. It gives me confidence, it helps me iron out problems with the speech and the slides, it gives me an idea of timing and pitch, and it helps me wrap up the preparation of the talk with fun and surprising elements.
It is often during those rehearsal sessions that I come up with the fun bits of my talks, like the “Clippy” moment that I used in my session “Being A Developer After 40” in AppBuilders Zurich 2016, or the “Cocoa Award” joke during the “Refactoring iOS Projects” at UMT 2016. Adding fun is great, particularly in the middle of a long talk, to trigger emotions in the audience and to enhance their attention. But I think that, as with any tool, it should not be abused. I try to use only geek or pop culture references for my jokes, and I strictly avoid local cultural references, which is something that can go wrong very quickly, particularly in foreign countries.
There is quite a few very good guidelines for speakers online, like the ones from Scott Berkun or Paul Ardeleanu; so I will not add anything here, other than saying that I read and re-read these during the process, just to make sure I am not forgetting anything.
There are, however, a couple of things that I systematically recommend to speakers, and that I do myself every time:
- I try to arrive early to the venue. As early as possible. I want to jump on stage before the attendees come, I want to go to the back of the room, I want to see how my slides look from afar, I want to test the microphone, I want to test the HDMI connection, I want to feel the room. Even if my session is later in the afternoon, taking position on stage helps me figure out how things are going to be later on.
- I set up my Apple Watch with a special face showing the timer for my talk. This gives me the possibility of quickly glancing the remaining time, which is particularly useful in venues that do not feature some kind of time feedback mechanism. The Logitech Professional Presenter R700 also has an embedded timer that is really useful.
- In big events, I skip the part where I say who I am or what I do. Most conferences these days have a track host that will do that for me, and the website has all the links for people to know everything they need, so I just jump to the content right away. In small events, like developer groups smaller talks, just a slide with my name and website will be more than enough, and it usually comes at the end, anyway.
- I always use a remote control. Either the iPhone Keynote application, coupled with Keynote on my iPad Pro or Mac, or my beloved Logitech Professional Presenter R700 that always comes with me. Using a remote control for my slides frees my body from staying next to my iPad Pro or my Mac, and allows me to tell my story freely, walking on stage as needed.
- I always make eye contact with people. I pan with my eyes across the audience, trying to gauge their interest as I speak, and I hope that this makes them feel a part of the talk as well — something they definitely are. It is a small detail but it plays a very important role in my style.
- Finally, if at all possible, I tell my audience to ask me questions after I leave the stage, so that I can yield quickly to the next speaker, and to avoid the problem of mike-based Q&A sessions that can sometimes be awkward or downright boring. Leaving stage involves returning the microphone to the technical team, removing my laptop and bottle of water, and packing up my stuff. I can answer questions much easily if I do these things first.
I love speaking in public. There cannot be any other explanation to justify the energy and time that I tend to pour into these events. There is a tremendous amount of energy going on in conference rooms, and I love when people come to me after the talk to ask questions and to give me their points of view. I learn a lot and this brings me great joy.
Preparing a good 30 to 40 minute talk takes me between two to three weeks of work, but I think that an audience that takes some time out of their work duties to attend conferences deserves the best possible content. In some cases I have published the speeches, and the response so far has been nothing short of phenomenal. I plan on doing this in the future as well.
As my friend Daniel Steinberg said to me once, the best way to learn is to teach, and I can only confirm his wise words.