The life cycle of a conference talk
Although lines of code are the most convenient metric of success in open source, I’m proud of those of my own contributions that have taken the form of documentation, teaching, and outreach.
One such skill that I’ve been working on improving over the past couple years is public speaking, specifically educational talks on a variety of open source related topics. At my current skill level, I’m finding it increasingly important to understand what works and what doesn’t in the process that I use when creating my talks. Below the fold will be a few pages of my thinking “out loud” about the topic.
The Idea
“I should give a talk about that!”
That sentence is my cue to write the idea down somewhere, because otherwise it will disappear. If I have any idea of what the talk’s content should include, it goes straight into a .rst file in my slides repo. Whenever I see an interesting article or teaching tool that relates to the topic, I drop the link into that file.
Outline
The few hours when an idea is shiney and new and still makes sense in the context where it originated are the best time to outline a talk. I think of the outline as the brainstorming phase of story development: concepts from the outline often end up as sections of the final talk, but those which don’t fit can easily be thrown out along the way.
The better-developed I can get my outline, the easier it is to continue development of the idea later. It also helps me to write abstracts when submitting the talk to conferences.
Abstract
The abstract is that single-paragraph summary of a talk which convinces a conference’s committee that the talk would be a good fit, and then appears in the program if the talk is selected.
A good abstract is essential to the success of my talks, because it guides the rest of the development process. The title and abstract are how I make sure that only people interested in what I have to say will show up to my talk. They’re the promises that the finished slide deck needs to fulfill.
With this in mind, I’ve identified some common traits in the abstracts which get accepted (vs the many talks I’ve had rejected from conferences).
A good abstract:
- Starts with a hook that will catch the reader’s attention
- Demonstrates understanding of the audience’s needs
- Asks questions from the audience’s perspective, which the talk will answer
- Summarizes why the presenter is qualified to teach the subject
- Identifies any prerequisite knowledge that the audience will need to get the most benefit from the talk, or reassures beginners that their questions will be welcome
- Ends with a recap of what the audience can expect to learn and an encouragement to attend
These factors can make it seem tempting to promise more than the talk can deliver. Don’t fall into that trap! If you have any doubt about your slides’ ability to fulfill a promise made in the abstract, go write the slides for that part of the talk and make sure they’re sufficient before continuing.
Application
Once I have an outline, abstract, and title for a talk, I’m ready to look for conferences whose attendees might be interested in it.
I use the site Call To Speakers to find new conferences, as well as applying to everything in my local area which overlaps with my knowledge and interests.
I typically submit 2-5 applications to conferences I’ve spoken at before and enjoyed, or interesting new conferences which:
- Occur on dates when I expect to be available
- Are near home or offer travel assistance for speakers (though this will be a much less pressing concern with a grownup job than it was during school)
- Seem likely to interest the kinds of people whose company I enjoy, such as open source nerds
- Have a reasonable code of conduct that shows they’re prepared to handle both real and imagined problems in a way that’s fair and reasonable
When To Apply
A conference’s Call for Proposals (CFP) typically closes 3-9 months before the date of the conference, with speakers getting notified 1-2 months after that. Dates vary for each conference, of course.
After attending and enjoying a conference, I put “check for <conference> CFP dates” on my calendar for a reasonable-sounding time the next year. If there’s no update on CFP timing when my calendar emails me a reminder of that event, I move it forward a month and check again then.
Slides
After a talk gets accepted to a conference for the first time, I convert its outline into a slide deck. The purpose of the slides is twofold:
- Slides are a good excuse for speaker notes on my screen, which help reassure me that I haven’t forgotten any of the important content
- They give the audience something to look at, to reduce their tendency to look at their computers or phones. Ideally, the picture on each slide complements the topic I’m discussing on it, and slides change frequently enough to prevent anyone from getting bored.
My favorite slide decks have averaged close to only 1 word per slide. My usual slide decks are pictures with section titles above them, interspersed with the occasional graph or bulleted list.
Google’s search features for finding images licensed for reuse are extremely useful in compiling this type of slides. Wikimedia images are especially nice because their pages have the citation pre-written for you.
Rehersal
This is the part of speaking which I hate most, and tend to procrastinate badly on. When the slides seem about 75% done, I fire up Audacity and record my entire talk as if I’m presenting it at the conference.
It’s horrible. It’s always horrible. There’s a certain quota of horrible-ness in a talk that’s guaranteed to be there at first, and the only way to get it out is through rehersals.
I don’t take notes while recording the rehersal, since that would mess up my estimate of how long the talk takes, but I do jot down some notes on slide order and which transitions were awkward immediately after finishing the talk.
Analysis
Okay, I lied about rehersal being the worst part of preparing a talk; that honor actually goes to the part where I have to listen to the recording.
This is the part where I have to be my own poor audience, enticed by the talk’s abstract into stumbling into a room and being subjected to an hour of my shrill, obnoxious voice. I don’t like this part. But I make it feel productive by taking notes, either on paper or in my slides themselves, on how to make it slightly less terrible.
These improvements tend to fall into three categories:
- Ordering and transitions. I rarely get my content into an order that flows optimally on the first try, and have to re-learn the transitions between sections every time I rearrange my slides.
- Pruning extraneous content. When I really like a topic, I often want to digress into cool stories every slide, and listening to those digressions is the best way to identify which are useful and which sound irrelevant.
- Adding facts and citations to substantiate the claims that I’m likely to make when discussing a topic.
Repeat
Unfortunately, a single rehersal is never enough. The more times I practice a talk, the better it gets. It’s two years and a dozen talks into my speaking career, and I still cringe at having to listen to my own voice, so I doubt it’ll get better. But it’s worth it, to create finished talks that others benefit from and enjoy.
Finishing Touches
Shortly before my presentation, I put the canonical copy of my slides at talks.edunham.net/conferencename/talkname. I also add that URL to the intro and Q&A slides, so that viewers can find the slides easily.