The technical conference season never stops. Hundreds of technical conferences are always occurring around the globe, giving engineers and developers the chance to share their knowledge and experiences with members of the community. But even as these events are occurring, the Calls for Papers (CfPs) for next season are already opening.
If you’ve ever felt compelled to deliver a talk at a conference, there’s no time like the present to submit to a CfP.
And I’d like to help you do just that by beginning with the most important part—writing an abstract.
Why listen to me?
I’ve had the privilege of serving on a technical conference Program Committee for a couple of years now. During which time, I’ve reviewed hundreds of technical abstracts and offered personalized feedback on a large percentage of those. On top of that, I’ve successfully seen 5 globally-recognized events through, start-to-finish, as Program Committee Chair.
After all of that, I have a few thoughts on what we looked for in abstracts on the Program Committee, how you might extrapolate that for any technical conference, and what you can do to prepare to submit for your next conference CfP.
The Secret: Write a Good Abstract
It shouldn’t come as a surprise to anyone that the secret to getting into a technical conference (or really any conference, for that matter) is by writing a good, relevant abstract. After all, the conference organizers and the Program Committee only have your abstract to base their decisions on. You may as well make it easy for them.
Conference abstracts can be beautiful pieces of prose that introduce your topic, summarize your session, and provide some proof that you are articulate enough to present on the subject at hand. That's a heavy ask for a short write up... If you don’t necessarily write on a regular basis, that might sound daunting. But it doesn’t need to be.
Let’s break it down.
💭 Decide on a Relevant Topic
I shouldn’t have to say this, but I’ve seen enough irrelevant CfP submissions that I feel the need to bring it up. The biggest favor you can do for yourself is understanding the conference that you're submitting to and the audience that will be attending. This is going to involve a little bit of research on your part. To guide you in that, consider asking yourself these questions:
Is the topic I want to speak on relevant to the conference to which I’m submitting?
(And vice versa for those of you who would like to speak at a specific conference.) If it is your dream to speak at Blah Blah Generative AI Conf, maybe don’t try submitting a talk on your experience working with OCaml. Unless you have a good angle. Which leads to the next question…
Does it make sense for an attendee of Conference XYZ to come to your talk?
Someone at a .NET conference might not necessarily find Apache Kafka useful to them and their everyday work. But that doesn’t mean that there couldn’t be an Apache Kafka talk at a .NET conference, and that’s where having the right angle comes in. If you are targeting a specific conference with a specific (perhaps non-obvious) topic, I would challenge you to start by convincing yourself that a nontrivial number of attendees from Conference XYZ would be interested in your talk before you spend time crafting an abstract and submitting.
Are there any conference themes or tracks to be aware of?
Some conferences are general and bring together a variety of subject matter, speakers, and presentation types. In which case, the world is your oyster—submit away!
But keep in mind that even some general developer conferences use themes and tracks to ensure that their audience can still get enough of a certain type of content. For example, a conference might have an AI/ML theme for that year, or perhaps they’re committing to a handful of specific content tracks like Big Data, Streaming Data, and MLOps. It’s worthwhile for everyone that you check into those themes and tracks ahead of time; tailoring your content and abstract will do wonders for increasing your chances of acceptance.
And on the other hand, not abiding by the tracks can really make it difficult for the committee to evaluate and accept your session.
🛠️ Build a Foundation
Alright, so you’ve done the research and have a topic and conference you plan to submit to. The next step is to begin to formalize exactly what you will include in your abstract. I usually start doing this by writing a rough outline of key details.
As you do this, keep one thing in mind: every talk and session is there to benefit the people in the audience, and each abstract should reflect that. The conference is for the attendees.
Here are some questions to get you started:
1. Why should someone care about your talk?
Put yourself in the shoes of an attendee at that conference. They’re looking through the conference agenda and trying to figure out which relevant sessions they should attend. Make it easy for them! An attendee should know from the very first sentence of your abstract (or better yet, the title) what they can expect to get out of your session. Oftentimes, attendees are choosing sessions in the 5 minutes prior to the talk, so you need to be quick to capture their attention. Don’t waste your precious first sentence explaining who you are or which company you work for—focus.
2. What technical details are you covering?
After the attendee has been reeled in by a good title or opening sentence, now’s your chance to really prove to them that they’re going to get something good out of this session. Show them what they should expect to be covered in your conference talk. Explain exactly what tech you’ll be presenting on or using in your demo. Tell them how you accomplished what you did. Convince them (and the Program Committee) that you know your stuff.
3. What takeaways can an attendee expect?
Finally, make it super explicit what an attendee should expect to get out of the talk. Will they know the ins and outs of a specific API? Will you be giving them all the tools they need to build a certain app? Tell them! It may not make for beautiful prose, but know that there’s absolutely no reason why you can’t use the final (short) paragraph of your abstract to explicitly state your takeaways.
📝 Put Pen to Paper
Now for the easy part—write the abstract. 🙃
Don’t let this intimidate you. You don’t need to be a great writer to craft an incredible abstract. Really. You start with your foundation—conveniently, these are just the facts and key details from your outline—and build from there.
What does this look like? Here’s a template:
Abstract Template
[Descriptive Title]
[Opening sentence with a good hook based on your answer to question #1 above.] [Optional sentence to segue into the details of the talk.]
[The meat of your abstract. 2-4 sentences on the technical details of the talk based on question #2 above.]
[Summary and takeaways based on question #3.]
Bam, look at that! If you answered the questions from the previous section, you basically have an abstract right there! But remember, this is meant to be a starting point. This first draft should not be your final draft.
Ready, Set, Iterate
Now we refine. And I’m going to purposefully do a little hand-waving here. How you refine and how much you refine will be up to you and your writing style. I mean that—use this time to find your style and what works for you.
Generally speaking though, with your draft in hand, do roughly the following until it’s done (by some definition of ‘done’):
- Read the draft out loud to yourself. Does it flow? Does it sound good? Before you completely discount this part and skip to the next one, stop. Reading out loud is important; written text can look fine, but saying it out loud will help to point out parts that don’t feel natural, put it more comfortably in your own words, and also identify any pesky grammatical and spelling errors.
- Remove unnecessary information. It’s common for CfPs to request that your abstract be relatively short. To maximize how many you can submit to, it's beneficial to be short.
- Confirm that your draft contains all of the information from the questions you asked yourself in the previous section. If not, add it back in! At a bare minimum, the audience should know what your session is about, what technical details it will cover, and what they will get out of it.
A final note… and a dose of reality
I strongly believe that technical conferences are meant to be by the community for the community. Anyone who wants to present should have the tools and resources at their disposal to make that possible. If you’ve been looking to submit to speak at a technical conference but haven’t known where to start, I hope that this post serves as the nudge that encourages you to finally do so.
As you start on your journey of writing abstracts and submitting to CfPs, I have one final thing for you to keep in mind: even if you write an objectively incredible abstract, there’s no guarantee that you’ll be accepted to every conference you submit to. You shouldn’t let that discourage you. Speaking from experience, sometimes conference organizers have to reject even some great sessions due to time and space constraints.
To stay on track:
- Start small—apply to local or regional technical conferences that may have a smaller pool of applicants.
- Take advantage of your rejections and iterate. If you’ve been rejected, reach out to the conference organizer and see if they have any advice or feedback as to why your session was rejected.
- Know that it’s a numbers game. Even great speakers that I know of still receive rejections, so they increase their chances of acceptance by submitting to many conferences.
- And watch this space for followup posts in this series to make this process feel a little more tangible. 👀
With that, get on out there and start applying to CfPs; with any luck, I’ll see you on stage at a conference someday soon!
Top comments (0)