by Amanda Sopkin
How to Get a Technical Talk Accepted at a Conference or Event
So you have been considering getting into the conference speaking field? Well you’re in luck, it’s a great time to jump in! Maybe you gave a talk at a local meetup and enjoyed it. Maybe you attended an event recently and started to think about ways you could contribute to the attendees. Maybe you ran across a good talk on YouTube that inspired you.
I have been speaking at conferences, reviewing proposals for events, and coaching new speakers for the last couple of years. I find that many people have misconceptions on the subject, like “I need tons of experience before I can speak at an event” or “speaking at events is invite only”.
But there is a growing movement in tech to make speaking more friendly to beginners and more welcoming as a whole. More and more events even have a separate application (call for proposals) process for beginners.
Picking a Topic
The process of coming up with ideas for your next proposal can be more similar to that of songwriting than something more systematic, like approaching a technical problem. Inspiration comes from many different places and in many different forms. Here are some ways that I have come up with talk ideas:
- I saw a talk with X format and decided to apply it to Y subject.
- While working on a project, I thought, “Wow! I wish I knew X, Y, and Z before I started!”
- A conversation with coworkers about X led me to see the potential for a talk on it.
With these approaches I start out with the idea and then find a way to make it work for the conference. For example, when I applied to speak at Pycon I knew I wanted to talk about computational randomness. So I started there and then added to the Python specific meat of the talk. You can also start with the conference in mind and brainstorm ideas from there. By using this method, my thought process was more like:
- These are the top X, Y, Z ideas people are looking at in this language/framework now.
- This conference tends to have talks in X and Y subject areas every year.
- An event is specifically requesting talks in Z field.
Personally, I have found the first approach to be more successful. Often, starting with the conference in mind can lead you to write talks that you think the conference wants, rather than writing something you are genuinely passionate about. Also, people tend to come up with similar ideas which can put you in a bigger pool of competition (i.e. writing 1 of the 100 talks about the basics of machine learning in Python vs. a unique problem you are particularly suited to solve).
Writing your Abstract
Once you have the idea, it is time to jump into representing it in the best light possible. One of the biggest misconceptions in conference submissions is that you don’t need too much effort into this step because
A. You are too important or
B. Your idea speaks for itself.
Unless you have been specifically invited to speak (at which point you can decide your own topic with some input from the organizing team), your proposal will often go through a blind review process where it has to fend for itself against the other (well-written) proposals.
And details are important! Reviewers are busy people often reading hundreds of proposals for an event. If there is not enough content there, they will not guess what you could have meant. They will mark it down and move on - regardless of your qualifications.
With the importance of this writing stage in mind, here’s a little about my process once I’ve got an idea…
Write the description first
Conferences have varying requirements for a submission, but I often start with a more detailed description and outline to solidify my ideas as recommended by Alaina Kafkes in this piece. This helps me illuminate the most important stuff that I want to talk about.
Sometimes you start out writing a talk about how brown bears are best, but as you start to sketch out the timeline for what you want to discuss, you realize that you really want to talk about why polar bears are undervalued and really deserve more attention overall.
Answer the question: why should I attend this talk?
The abstract you submit is your selling point. The elevator pitch of your talk. It’s like a dating profile to potential matches. Think about the value of your talk to potential attendees, because this is how reviewers will decide whether or not to include it.
I usually write out a separate section with at least 3 explicit takeaways that I will incorporate into the abstract and often also include that in my description. One of the most common reasons talks get denied is “Can’t think of any takeaways”. As a reviewer, a common litmus test for reading a talk is “Would I have interest in this talk myself?” and if the answer is no, that can be a good reason to favor a different, more compelling proposal instead.
Think about why you are the best person to give this talk
Saron from Code Newbie gave this advice in a webinar on submitting to conferences that really stuck with me. Don’t submit a talk that should be a blog post. As someone who really loves practical takeaways, I often write talks that feel more like “5 reasons to switch to X framework”, but the best talks have a good story as well.
Looking at it from this perspective humanizes my speaking and makes my talks more like a journey than a series of tips that could be easily skimmed. You want to leave your attendees with more than what they would get from a written piece.
Have at least one person read your work
I always have at least one person review my work and I will continue doing this until the one time when they do not manage to catch something really big. These embarrassing mistakes that I somehow missed in the 50 times I read it myself have included:
- choosing a word that didn’t mean what I thought it did
This step is really important. To many reviewers, grammatical mistakes both consciously and unconsciously convey a lack of effort.
If the conference offers it, get feedback on proposals! Even if not explicitly stated, when emailing and asking for a second opinion I have never been turned down. This makes a world of difference. Some of the useful feedback I’ve received has included cutting irrelevant subjects, adding more detail to a particular technical explanation, and making the takeaways more obvious.