Over the course of my career as a software engineer, technical writer, and now developer advocate, I’ve probably given over 30 talks (both online and in person). As a result, I know a thing or two about writing abstracts and have gained insights into what it takes to write abstracts with a higher chance of being accepted.
In this article, I will address the top three questions I frequently receive about submitting talk abstracts to conferences:
- What topics should my talk abstract cover?
- What should be included in the abstract, and how should I structure it?
- How long should my talk abstract be?
On abstract topic: Talk about what you know
Think about your experiences. What have you learned? In what ways have you grown? Are there things you know now that you wish you had known earlier? If you could go back in time three years, what would you tell yourself? That's a good starting point.
Please focus on discussing topics you are familiar with. Conference abstract reviewers can usually tell when you’re bluffing. Based on my experience, the most successful talks are often those that relate to personal experiences, even technical talks.
For example, let's say you're giving a talk on ‘Introduction to React’. Any React developer can give a talk on 'introduction to React' or find information about it online. There's nothing particularly exciting about that.
However, a talk titled "My Tumultuous Introduction to React" covering why you decided to learn React, the challenges you faced while learning, the mental model you used to grasp the basics, the top five things you believe everyone learning React should understand to make their journey easier, and how learning React has benefited your career, is a far more interesting talk.
In the same vein, anyone can search for information on how to install the Chrome browser, but nobody can share your experience of installing it for the first time or the obstacles you encountered. That's something people cannot find on Google.
In summary, for each topic, consider how to connect it to your personal experience or opinion. Add some life to it.
On abstract structure: Start with the topic, state the problem or paint point, tease a solution, then finish off with the takeaways
Your abstract serves as a promise of what conference attendees will learn from your talk. It is essentially a sales pitch to convince conference organizers that your talk would be a valuable addition to their conference lineup.
The first thing is to make sure that your talk aligns with the conference theme and prospective audience. Then, for structure, your abstract should address the following four important questions in the specified order:
- What is this talk about?
- Why is this talk an important topic or discussion? What is the identified pain point or challenge associated with this talk?
- What is my suggestion or solution for the identified challenge? What is my unique point of view or opinion on this topic?
- Who is this talk prepared for, and what will they learn from attending? Are there practical, actionable takeaways or results that people can expect to get out of this talk? The whole point of your talk or webinar is to leave the audience smarter.
Specifying the intended audience in your talk abstract can be helpful when submitting to conferences with a diverse audience and multiple tracks.
To help you answer the questions above for your conference talk abstract, it may be helpful for you to first develop the talk and write a blog post about what you want to say. Understandably, you might be hesitant to do this because what if your talk is not accepted? My answer is that your effort won’t be wasted, as you can always publish the blog post if the talk doesn't get accepted.
Here is a talk abstract example of mine that has been accepted at a couple of conferences:
💡 Bring development closer to production with valid HTTPS certificates
Dev/pod parity is one of the major rules of software engineering. With that in mind, if almost all production web pages now load via HTTPS, why is it that almost no one uses HTTPS in development? Because the traditional process of provisioning certificates to local environments is hard. That sucks because when dev doesn’t match prod, bad things can happen. Join me in this talk to learn how to use step-ca (an open-source Let’s Encrypt equivalent) to easily automate certificate issuance in your development environments with just four commands.
Sentence 1 is the Statement/Hook. It communicates what the talk is about with concise language:
Dev/pod parity is one of the major rule of software engineering
Sentence 2 states the problem:
With that in mind, if almost all production web pages now load via HTTPS, why is it that almost no one uses HTTPS in development?
Sentence 3, 4, and 5 teases a solution and evokes a bit empathy of why the problem exists in the first place:
Because the traditional process of provisioning certificates to local environments is hard. That sucks because when dev doesn’t match prod, bad things can happen. What if there was a tool built for this?
The final sentences describe precisely what attendees will learn:
Join me in this talk to learn how to use step-ca (an open-source Let’s Encrypt equivalent) to easily automate certificate issuance to your development environments with just 4 commands.
P.S: This talk is published as blog post on FreeCodeCamp if you’d like to take a look.
On abstract length, keep it short
When writing an abstract, avoid the temptation to cover every detail. Focus on answering the four essential questions and leave it at that. As a general guideline, if you can't summarize your talk in a minute or two using your abstract, then you may not have a clear understanding of your topic.
Keep refining your abstract until you can convey it in a minute, aiming for a length of around 100-150 words. Once you're done, seek assistance from someone else to help you edit and assess the clarity of your points. Additionally, create a compelling title that sparks curiosity in readers, enticing them to want to learn more.
Conclusion
Unfortunately, even if you follow all the guidelines mentioned above, there is still a possibility of your talk being rejected. The selection of your talk by conference organizers or reviewers depends on a number of factors that are unrelated to the quality of your abstract.
It could be that a similar talk has already been accepted, or that there are limited speaking slots and other talks were given priority, or perhaps your talk was not completely aligned with the conference theme. Regardless of the reason, don't let rejection discourage you. Keep applying, as it is a numbers game. May the force be with you.