Submitting conference abstracts that get accepted

This content originally appeared on DEV Community and was authored by Matt Eland

I often get asked by coworkers and folks in the community "How do I get to speak at a conference", “How do I write a good talk abstract?”, “How come I keep getting rejected?” or “What does the conference submission process even look like?”. Because this is a complex topic and a recurring one, I thought I’d share some of my insights into this common question in writing.

The simple answer is that you must write an abstract that is relevant to the conference and its attendees, is easy to understand, and is more interesting or more relevant than other good abstracts. But the details get a bit muddy, so let’s dive into it.

What does the conference review process look like?

First of all, it’s helpful to understand the conference review process. I think I’ve now reviewed session proposals from 12 total distinct events and all of them work in a similar way: the conference has a public call for proposals - or call for papers or call for presentations or call for speakers – the terminology varies but they’re typically called CFPs for short.

During the CFP process the conference has a public way for people to submit information on their talk. This information includes:

• The title of the talk
• An abstract consisting of a few paragraphs describing the talk
• The name of the speaker
• A profile picture (optional)
• A tagline identifying the speaker (Mine is AI Specialist @ Leading EDJE)
• A short bio of the speaker
• Additional notes visible to organizers only

It’s important to note that all information in the proposal aside from the additional notes field will be visible to attendees should your talk is accepted, so you write this primarily to the attendees, even though the conference must review and select it.

The CFP process is usually open anywhere from a week to a month. Once the CFP closes submissions are not allowed and the review process begins.

Review processes vary from event to event, but they sometimes will involve a preliminary “weed out” round to remove abstracts that are not well formed, did not follow event instructions, or are not well suited to the conference.

The purpose of this “weed out” round is to reduce the workload for the conference for serious review and ranking. Most of the time you don’t need to worry about the “weed out” round, but I’ve seen a few friends get rejected by conferences from not reading CFP instructions for special conditions like “Don’t refer to yourself by name in the abstract” or they’ve submitted 1 hour talks for a 30 minute timeslot.

The “don’t refer to yourself by name in the abstract” condition might sound weird, but more and more conferences are doing either entirely blind CFP reviews where reviewers don’t know who submitted a talk or reviews where the first round is blind and then final rankings are made once speaker information is available. The purpose of this is to reduce biases that might be preventing women and minorities from getting conference speaking slots, or to reward relative unknowns who are submitting great talks and competing with established speakers who are starting to coast.

During the actual review process, a panel of community reviewers – typical senior tech professionals in the area who are trusted by the conference – review each session and either give it a numeric rating directly or rank it relative to a few other random sessions from the conference. Reviewers will do that for every talk in a specific technology area, such as web development or databases or data / AI.

Once all reviewers have reviewed sessions, the conference rganizers have a body of numeric ratings for each talk they’re reviewing. Conferences then tend to take the topmost ranked sessions overall for the conference, or the top X talks from every track of the conference to form their agendas.

If a track has a lot of talks in a specific topic, it’s possible that a talk on an already covered topic that ranked third might skipped over for lower placed talk if it deals with a different technology.

Additionally, conferences can only cover so much travel and hotel costs for speakers so many conferences like to select multiple talks from the same speaker in order to reduce schedule impact.
This is part of why you should submit multiple talks to the same conference.

Why do abstracts get rejected?

So, why do people like me rate sessions poorly?

There’s a number of reasons I might rate a talk poorly:

• There are obvious grammatical or spelling issues
• The speaker didn’t pay attention to the event – listing the wrong time length of their session, referring to the talk as a workshop at a conference that doesn’t offer workshops, etc.
• The topic of the talk is wrong for the conference’s theme or typical attendees.
• The approach of the talk is wrong for the audience (trying to give a mass-market keynote talk for non-tech professionals at a developer conference, for example).
• I can’t tell what the talk is about from the title
• The title isn’t compelling
• The abstract is way too long
• The abstract is way too short
• The contents of the talk appear illegal or unethical – advocating for illegal activities or even
• presenting someone else’s abstract as your own

In conference selections you get usually one shot to select speakers and you want to select someone who’s going to give your conference and its attendees the attention and preparation they deserve. That means someone who’s going to follow directions / instructions, read emails from organizers, and put in the time and effort to deliver a great talk.

I do note length of abstract in a few of those points above along with the talk title. We’ll come back to those topics later.

For now, keep in mind that most of the time I don’t actively reject talks.

More often I’m comparing 3 talks to each other based on their merits and talks simply don’t rank as high as others because the other talks are more compelling.

What people look for in an abstract

So, what makes an abstract compelling?

I think a good abstract accomplishes a few key objectives:

• The title tells the reader what the talk covers – both the main technology and focal area. For example, “Jupyter Notebooks: Not just for nerds” tells you the technology involved (Jupyter Notebooks) and hints that the talk is an accessible introductory talk. On the other hand, a title like “Holy Crepe Making Machine, Batman” might be intriguing, but doesn’t tell attendees or organizers what technologies we’ll be highlighting or who would benefit from attending (that being said, I might still attend that talk). Keep in mind that many attendees pick talks just by their titles alone.
• The title encourages the reader to read the abstract – Conferences have a lot of talks. Attendees won’t read every abstract and organizers know this. They look for talks that invite attendees to discover more. While a reviewer is going to read your abstract no matter what, making them excited to read yours increases your odds of acceptance. Interesting titles like “Machine Learning Belongs in a Museum” can be more compelling than “Machine Learning for Air Humidity Control”.
• The abstract is focused on a key problem or opportunity – Your abstract is about a need or desire your attendees have, whether that’s learning how to get started with something, discovering how to optimize algorithms oSr AI solutions or how to navigate the troublesome waters of a layoff. The opening of your abstract should focus on this need or desire.
• The abstract should communicate your approach – If an attendee spends the time to read your abstract, they should have a good idea of the main topics covered in your talk, as well as if the talk will involve demos. You don’t have to give your attendees the entire outline of your talk, but they should know the major bullet points you’ll cover. If you cover additional technologies beyond your main technology, you should list them here (though ideally include them in your title as well). Nobody likes attending a vague but interesting talk only to discover that it’s not applicable to their day-to-day tech stack.
• The abstract should tell the attendee what they get from attending the talk – Attendees often pay a real cost for conference attendance – whether that’s money from their pocket or their training budget or in terms of time off from work. Each conference has only a few slots for talks to pick from and attendees will inevitably be picking between multiple interesting topics. End your abstract with a summary of the key things the attendee will gain by you spending time in your session. Readers who make it to this are interested in your talk and this is your closing “sales pitch”.

You may notice that my focus here is almost entirely on the attendee and not on the session reviewer. This is because you write your abstracts for the attendee, not for the conference.

The conference’s job is to determine which abstracts will best serve their attendees. They often look at multiple competing abstracts on the same topic and can only accept a few, if any. Yours needs to more clearly communicate its unique approach and value to attendees in order to win among multiple competing abstracts.

Sometimes you’ll submit abstracts on niche topics that the organizers or attendees may not be familiar with. In those cases you need to communicate the basics of the technology, where it fits
into people’s existing workflows, and why it’s worth exploring.

For example, I produce a lot of content on a technology called Polyglot Notebooks that lets .NET developers perform data science and data analytics experiments in Jupyter Notebooks using .NET.

Most .NET devs don’t know to look for this technology, so I have to “sell” the technology as something that helps dev teams communicate their APIs in interactive ways and allows them to perform regular analytics tasks in a shareable way.

Unique and niche topics aren’t bad to submit to conferences, but conferences can only accept so many non-mainstream topics, so your abstract will need to be especially polished and understandable – particularly since your session reviewers won’t be familiar with what you’re speaking on.

Writing a good abstract

Now that we’ve covered the details of the CFP process, let’s walk through the structure I’ve found for writing my abstracts.

Picking a Title

First, you start with a title. Consider the technology and approach you’re taking and come up with 3 titles. Then write those down in a document and come up with 12 more.

You need to consider a lot of different titles to come up with your best possible title.

For the sake of argument, let’s say that you want to share with the community on a new JavaScript AI technology that magically detects and eradicates bugs in your code as you write it. For sake of argument, we’ll call this fictitious technology Woodpecker.js.

Our first three titles might be:

• Tired of bugs? Let woodpecker eat them as you code!
• Woodpecker.js – It eats bugs so your users don’t have to.
• Getting pecked to death by bugs? Woodpecker.js can help!

All of these mention the core technology and the key benefit and all of them have a humorous bent to them.

We can also ask a large language model for ideas if we get

I sent Bing Chat the following prompt:

Give me 12 titles for a tech conference talk on a JavaScript framework called Woodpecker.js that detects and removes software bugs as you write your code. Titles should include Woodpecker in the title and be interesting to conference attendees. Sample titles include “Tired of bugs? Let woodpecker eat them as you code!”, “Woodpecker.js – It eats bugs so your users don’t have to.” and “Getting pecked to death by bugs? Woodpecker.js can help!”

Bing Chat gave me the following response:

Here we see 12 decent titles for the same abstract as well as 2 links to a similarly named CI tool called woodpecker-ci, an article on JavaScript conferences (that we could potentially submit this talk to), and a link to writing good abstracts.

I’m rather partial to “From Bugs to Breakfast: Woodpecker.js Devours Code Issues” so we’ll go with that and hope the conference doesn’t schedule us just before lunch or dinner when attendees
are hungry.

The opening paragraph

Now that we have our title, let’s start our actual abstract.

I like to begin my abstracts with an introduction to the problem and technology. Focus on a need or challenge attendees have and introduce your topic as a potential solution.

For our abstract, our opening paragraph might read as follows:

Tired of bugs slipping through and reaching production? Is your AI copilot asleep at the
helm? Woodpecker.js might be able to help. Woodpecker.js is a revolutionary technology
that gleans insights by looking at multiple alternate realities in which your code went out as
written, learns from the bugs that occurs in those alternate worlds, and silently applies the
fixes for those bugs to your code.

While this technology sounds too good to be true (and is, since it doesn’t exist), the paragraph establishes a need or challenge: bugs are reaching production and developers want to focus on development and not debugging.

The paragraph also assumes readers may not be familiar with the technology and briefly explains what it is and how it works at a very high level. This orients your readers to reading the rest of the abstract and doesn’t assume much knowledge for attendees.

Outline the talk's approach

Now that we’ve oriented the reader, our next task is to help them understand what we’ll cover and how we’ll cover it.

I usually do this with either a single middle paragraph or a short sentence and a list of 3 – 5 bullets.

Let’s do the latter here:

In this talk we’ll show an interactive demo of Woodpecker.js and cover the following topics:

• Woodpecker.js in action: bug-proofing complex time zone and validation code.
• How Woodpecker.js works
• Getting started with Woodpecker.js
• Securing your application by anticipating future breaches
• Overcoming key challenges, including explaining alternate realities to your CTO

While this clearly is a ridiculous technology (that I want – please someone invent this), this list of bullet points helps attendees and conference organizers imagine your talk before you give it.
This is important because I’ve seen more than a handful of abstracts get rejected for reasons like “There’s no way you can cover all this in 50 minutes” or “This talk looks like it has about 10 minutes of content. I’m not making this a half-day workshop”.

Additionally, if attendees are already familiar with a topic, they might be on the fence on attending your topic in the hopes that you cover more advanced topics. By outlining your high-level
approach, attendees won’t be playing roulette on what you’ll cover and can make informed decisions. This protects you a little from people complaining about your session not meeting their
needs / expectations.

Ending your abstract

Your final piece to the abstract is a short summary or call to action that recaps the key benefit and need of the talk.

In our case, that’s going to be as simple as the following short paragraph:

Come see how Woodpecker.js can help you leave bugs to the birds and focus on what truly matters: delivering value to your organization through secure bug-free code that meets the needs of your users.

With that in place, you close your abstract and send and now the waiting process begins.

What happens next?

After you send in your abstract (which you definitely did well before the last day of the CFP process, right?) the waiting begins.

For me, this is often the hardest part as I’m frequently checking my inbox as time goes on for those acceptances or rejections.

My best advice is to keep yourself busy with another project during the CFP review process, and to have a backup plan for if you’re rejected.

Preparing an accepted talk takes a lot of time and effort, so think about what you might do with that time if you weren’t selected for a talk.

In my case, I had a heartbreak a few years ago where a conference I really wanted to get into rejected a talk I really cared about and it stung.

I decided instead to spend that time building a small course on a topic of interest to me and I sent out a tweet announcing the disappointment and the new project in that course.

This brings up an important point: be gracious. It’s natural to want to blame organizers or be mad or vent, and these things are understandable, but I advise you to do them privately if you need to do them at all. Session reviewers and conference organizers are connected to their communities and tech is a small world sometimes. If you leave a bad taste in someone’s mouth from a post on socials,
they might remember next year and it could be a deciding factor in reviewing your abstract.

Remember, conference organizers want reliable speakers who will do a good job. Publicly complaining is unprofessional, but understandable, and may negatively impact your chances. In my case, it ended well because the conference had a number of speakers cancel and I was chosen as a back-up speaker to fill those slots. I graciously accepted, scrapped my planned course (which I’m now building a few years later, oddly enough), and delivered a talk I’m still proud of.

My closing thought for you is that even if you do everything correctly, you may not get picked. Things you view as critically important may be seen as less important by organizers, or you may be competing with a lot of other related topics.

Rejection happens, so learn from it, grow from it, and submit a diverse set of abstracts to give conferences many options for content of yours to consider and accept.

Finally, if you happen to be around the Columbus, Ohio area and want to give a talk at a user group, send me a note; I run one of our user groups and know most of the other organizers and would love to help connect you.

This content originally appeared on DEV Community and was authored by Matt Eland