Writing a conference talk
I’ve had to write a lot of conference talks so far this year. Some have gone amazingly well, others not so much. After years of panicking for a week before I’m due to present, I think I’ve finally worked out a decent method for writing talks
The abstract
It all starts with the abstract. I practice something called abstract-driven development, where I submit abstracts and write talks when they have been accepted. This works really well if you’re very familiar with the subject area, but not so much if it’s something that you’re planning to learn for the talk.
My advice would always be to only submit abstracts for talks you already have, or subjects that you’re very familiar with.
Writing the abstract is an art in itself. Some conferences want 4 lines, others want detailed write-ups. I find that the sweet spot is around 3 paragraphs. If you structure your abstract correctly, you can select the main paragraph and submit that for conferences that want short abstracts.
I’m a big fan of the pain, dream, fix method. First, identify a problem that people have. Next, let them dream that you can solve it for them. Then, tell them how to fix it.
Take a look at this abstract as an example:
Do you remember the time you spent an afternoon putting print statements in your app trying to debug an issue and removed them > before shipping the fix, only to add them back in a day later to work on another issue? Wouldn’t it be great if those debug > statements could just stay in your code forever? Like a little gift that keeps on giving, not just for you, but for everyone else on > your team too.
That’s what an application log is for! Logs aren’t just for when things go wrong. They’re for helping you to keep track of what’s > going on within your application.
We take a look at how you can add helpful messages throughout your codebase and leave them there, even in production! We’ll cover > common logging strategies, log aggregation and how to efficiently work with your logs to get the data back out again.
It’s quite a long one, but it follows pain, dream fix pretty well. We can cut out the first paragraph if we need to cut it down and still keep the main deliverables from the talk in the last paragraph.
Give pain, dream, fix a try. It worked wonders for my acceptance rate. If you’re not sure, give it a go and submit your abstract to Help me abstract where a team of volunteers are ready to help work through any issues you may have.
(Help me abstract really works! I had a brand new abstract accepted to php|tek thanks to feedback from there).
Writing the talk
Once you’re accepted (congratulations!) it’s time to write the talk. I’ve tried various different methods of writing talks including going straight to Keynote, writing it in a text file and drawing mind maps, but none of them have worked as well as using an outliner. As far as outliners go, Fargo is the best I’ve found (and it’s all web based which is awesome).
I tend to start by writing down everything I can think of. Fargo stays open in a tab for a few weeks. Any time I read something that is relevant, I copy/paste chunks of the article into my outline. I save relevant references and even tweets that fit the theme. At this point my outline is just a huge brain dump, starting with my introduction and the aims of what we want people to learn all the way through to which XKCD I should use in the talk.
Once you’ve done a brain dump, watch some related talks from other conferences. Most conference videos are available online for free. Watch them and get ideas for what you can talk about (and what you shouldn’t cover). Put this into your outline too whilst you’re watching. Try not to copy their talks exactly, but feel free to borrow ideas.
At this point, you probably have a decently sized outline. Start a new outline with some top level headings:
Intro
Identify the pain
Section one
Section two
Section three
Conclusion
Thanks/Questions/Feedback
You can have as many sections in the middle as you need - my last talk had six, a previous only had three. It depends on the talk that you’re giving.
Work through your initial outline and move everything into your new outline. Everything should fit under a specific category. Once you’ve moved everything you can across, look at what you have left and decide if you need another section to put it in or if it should be deleted. Either it’s good enough to stand on it’s own or it can go. I used to have an “everything else” section for this information but it ends up feeling bolted on and not really cohesive with the rest of the talk so now it gets deleted.
Finally, create your slides. Take each of your top level outline entries and use them as section markers. Show the list of sections to the audience at the beginning so that they know what they’re in for. Each time you change sections, show the section list with the new one highlighted - let people know how far through you are.
Keep your slides light on text. Use large fonts that are easy to read. Use relevant images if it helps you (personally, it’s not for me). There’s no “correct” number for the number of slides. Some people use 20 slides for a 60 min talk, others use 120. Use whatever fits your presentation style.
Delivering the talk
Practice practice practice. The best way to prepare a talk is to give it to a real audience. We’re fortunate in the PHP world that there’s plenty of user groups looking for speakers. Of the 3 talks I’ve given this year two of them went really well and one didn’t go quite to plan. Guess which one I didn’t practice at a user group?
User groups give you an opportunity to gauge how interested the audience is in certain sections that you’re not sure about yourself, as well as seeing how long the talk runs for and how the content flows. By using something like joind.in you can collect feedback after the event and work it into your presentation before you deliver it again.
Finally, it comes to conference day. Don’t worry about the slot that you’ve been given. I’ve spoken just after lunch on the first day (oh no! People will be full of food and sleepy), first thing on the second day after the social and free bar (oh no! People will be hung over) and right at the end as the last talk before the closing keynote (oh no! Everyone will be tired and sleepy). In every case, people have turned up ready to engage and learn. Whatever you invent in your head is rarely close to what actually happens. People go to conferences because they want to be there.
Check your slides on the projector as soon as possible. I’ve had situations where my colour scheme looked awesome on my laptop but didn’t show up well as it was a back lit projector (white on light blue) and situations where the aspect ratio was off as I didn’t read an email and I had big black bars on either side of my screen. Both times I managed to fix things as I checked my slides over 3 hours before I was due to talk. If you’re prepared, you can deal with anything.
Then, it’s time to give the talk. Get up at the front and do your thing. No-one’s there to judge you - if anything they want you to do well even more than you do!
Take your time, speak clearly and if you forget your rehearsed line, don’t worry. No-one else knew what you were going to say either so just roll with it and carry on with the next section.
Make sure you have water in a glass ready - not only does it help with a dry throat but it helps to punctuate a talk when you make a point that you want to drive home.
If you have a fixed microphone, try not to turn away from it too much. If you have a headset microphone, awesome! Try not to move too much as it can distract from the slides and content if the speaker is constantly walking up and down the slides. Instead, choose a point and present from there. It can be a lectern, it can be any point on the stage. Just choose a small area and stick to it.
Finally, enjoy yourself! You’re presenting because you have something that you want to share. You may be doing it entirely for self-gain, it may help your career at some point. You may be doing it just because you love helping people. What I’m certain of, is that you wouldn’t be doing it if you hated the idea of standing up in front of people and sharing what you’ve learned. Embrace the fact that you’ve been asked to help people out, and use the opportunity to teach others and learn a little more about yourself at the same time.