Brainstorming Your Next Conference Talk
The following article is part of a series of articles discussing the lifespan of a presentation; from idea, to delivery, to archival and back again. When needed, we’ll take special note of issues related to programmers and presentations involving code. Enjoy.
Last time we talked about the benefits of doing conferences presentations, and today we’ll help you figure out what that presentation topic should be.
When brainstorming a tech talk subject, or anything of value, it’s helpful to have some kind of low friction for your output. This could be as simple as pencil and paper or as sophisticated as dedicated mind mapping software (personally, I like MineNode when brainstorming on my Mac). After removing the friction of capturing ideas, let your mind wander. Don’t stop writing, capture everything you can think of, even the bad ideas. This exercise is not about evaluating ideas, it’s about capturing them. Things to consider and document:
- What conferences might this talk be targeted at?
- What is the format for those conferences?
- Do I have enough time to cover this topic with respect?
- Who am I?
- What do I do?
- What talks am I uniquely qualified to give?
- What topics were performed last year at these conferences?
- Which talks were well received?
- What common threads can be found amongst these talks?
- What does the audience want to learn?
- What are people struggling with?
- What do you know, that they don’t – but should.
Do multiple brainstorm sessions over the course of different days. Like an app idea list, it’s helpful to keep this as a living document for years to come. (Personally I like Trello for things like this.)
After brainstorming a bunch of ideas, you need to consider the merit of specific topics. Keep the following in mind during your review:
- Be genuinely interested and excited about your topic. Your enthusiasm will show through your work and life is too short to do something you are not excited about.
- Avoid the trap of assuming that you’ll have new experiences by the time the talk will be delivered or using the talk as some kind of project accountability hack. Things take longer than expected. Projects change directions. You don’t want to be on the hook for a talk you can’t deliver.
- Embrace recent accomplishments as your source material. Not every tech talk can or should be delivered by a senior level developer with years of experience. If you have just spent time learning something new and building things with it, you are in a unique scenario. You can use your knowledge to help people learn faster while at the same time having empathy for those brand new, like you were not long ago. These kinds of talks can work out great.
- Don’t overlook non-tech talks. Much of the challenges we face in our careers come from our interactions with other people, managing our businesses, finding a new job. There are tons of lessons to be shared here, and in fact these benefits usually outlast the tech stuff, which is revamped every 5 years or so.
- Consider reusing previous talks. There is nothing wrong with repurposing a previous talk as the source for another. Most people at conference X did not see you perform that talk at conference Y. In fact, most speakers say that a talk is better the second or third time since you’ll naturally get to know the material more and be a better performer.
By now you should have a few topic ideas. The next step will be to outline each topic’s content. Don’t worry about specifics, this is just to help you explore what the talking points might be and get closer to your final pick and then an abstract.
We’ll help with writing that abstract very soon.
This article series is brought to you by: OwlDeck.
OwlDeck is a new macOS presentation tool for programmers and geeks who need to display code and love Markdown.