If you’re reading this, there are good chances you’re thinking, writing or iterating over an abstract for a conference. The post is about little tips I learnt in more than 8 years of prepping for conferences and in 1 year or reviewing internal abstracts at Aiven before they are submitted for a conference.

🏆 What is a successful abstract?

First of all… what is a Successful Abstract?

There’s no formal definition of a successful abstract, but we can define one based on the outcome, which is “being accepted at a conference”. Therefore a successful abstract is one that maximizes the chances of getting accepted, by following a series of tips that, in my personal experience, worked in the past.

Alert: Bare in mind, this is based on my experience, your mileage may vary.

😱 What should I talk about?

This is the question driving the abstract, and usually the first stopper for quite some people. “I’m not doing anything interesting, I don’t have anything to say” is a phrase that we hear from a lot of non speakers… guess what? It’s most of the time not true! If you dig into your work (or passion) you can always come back with:

• Experiences: people are really interested in talks like “how we deal with X” or “bringing Y into prod”, since show that something is possible, and will avoid them to suffer your pains (if you share them)
• Failures: even more than experiences, people love hearing disasters. Talks like “How setting up Z destroyed our platform” or “How did I spend X$ in a night with monitoring and the wrong setup” get people interested since they can learn important lessons on what to avoid
• Things that you find complex: there’s a good chance others will think the same
• Something you built/planning to build: it’s a product, an open source library, an image? share your idea, plans! you might find people interested in using it or contributing.
• What YOU find interesting: you’re likely an expert in your field, or your’re learning something. There are good chances that what you find interesting is what others find interesting.

You can also find inspiration elsewhere:

• talks from previous years events
• common questions on StackOverflow/Reddit
• blogs written / topics discussed in your community (particularly the conversations they spark)

One special warning here if you’re sourcing the idea from elsewhere: don’t just copy the content, but make research, add a module, drive your own conclusions: add YOUR bit to the content. Just copying someone else’s talk will not set you for success.

🔝 Define the title

Once you decide the topic, it’s time to write the abstract and define the title… What should come up first? You decide, there’s no right and wrong.

Finding the perfect title is not an easy task, and you might want to use a personal style, tone or theme. The following titling tips are therefore general:

• Make the title clear: Most people decide to attend a talk based only on the title, since this is what is shown in the printout agenda. Cryptic titles can work if the analogy you’re using is commonly understood within your target audience.
• Think about the audience and speak their language:
  • use terms people recognize: Kafka Connect, pg_stats_statements, ebpf, perf… use the names you want people to associate with your talk
  • consider what you would like your audience to take away from the talk, and work that into the title
• Make it outcome driven and precise, e.g. Tips for Kafka Connect ❌ (too generic), 8 Tips to speed up Kafka Connect Configuration ✅
• Should the title be funny? Don’t feel forced… choose your own style. People will most likely select to attend a talk solving a problem they have rather than a “silly titled” talk. Prioritize searchability.
• Should the title be long or short: the character limit set by the organizers is the only limit you have.

Alert: Due to space in the agenda, some conferences will truncate your title or put ... after the first N characters. Create a title which is still recognizable after the truncation.

✍️ Write the abstract

Now we’re in the writing phase… how? Let’s first cover some technicalities.

👌 General prerequisites

• Check the allowed # of characters: this is usually given in the abstract form or CFP FAQ. It’s a prereq to shape your writing.

• Check the type(s) of abstracts you need to provide, each one has a different function:

  • Elevator pitch - Needs to be short and to the point, it can be used by organizers or put in the agenda. It’s your chance to convince people with just 1 paragraph.
  • Abstract - what people will usually see in the agenda, usually you have more words than the elevator pitch. It’s what attendees will base their judgment on
  • Submitter notes - your chance to convince the organizers and provide more background about you and your talk (why you’re the right person to talk about this topic and why your talk is different)

Each of the above sections is crucial, don’t just copy paste from one to the other, but take the time to write separate text for the three in order to maximize your chances to get accepted.

💡 Abstract overall idea tips

The next phase is to start the writing the piece, and there are three main points you want to include in the abstract:

• Think about the audience: What’s the problem you’re addressing? Setting a common ground based on a shared painful experience will likely get people interested in what you have to say.
• What makes your talk different: There can be 30 submissions about Kafka Performance, what makes your one stand out?
• What is the give-away for the audience? What do they learn/take home by giving you 30 min of their time?

✏️ Writing tips

• State the problem first: in order to define what your solution/talk is about, you need to first state a problem others might experience and feel theirs. Can’t you state a problem? Maybe that’s an indicator of a no-go for the talk
• Talk about outcomes: be sure to write down what people will learn/do better/think after your talk
• Share details: people will be interested to know what tools you use, what points you’re covering, what steps are in a process. Give a hint about what you’re covering but don’t give the entire talk away! Your abstract is not your talk!
• If you’re still writing the solution and not sure what the end product will be by the date? Add a bit more, you can always refer to some pieces as them being “in working” or “in design” stage. Sharing ideas of implementation can be interesting since you could receive feedback. An abstract is not an absolute promise but rather a guideline.
• Take extra care of the 1st sentence: most people will stop reading after the first sentence if they don’t feel it applies to them. Failing to attract people with a strong start results in less chances of being accepted.
• Think about the level of the talk: what does the target audience already know? Asking yourself this question allows you to define what you need to explain and what acronyms can be used without description. This also gives you a point of evaluation to understand how, explaining a bit more in the abstract, could make your talk engaging with a wider audience.
• Pick the person: be precise and consistent on how you use “I”, “we”, “you” in the abstract. Tip: using “we” might provide the feeling that both you and the audience are together into the problem and solution journey.
• Write down the take-aways clearly: an attendee shouldn’t have to guess what they will bring home.
• Aim for simplicity: attendees or reviewers might speak/read english as their second language, use an inclusive language that all understand. People might rarely open a tab on a browser to check a term they don’t understand, don’t let them do it. Don’t overuse jargon, and always evaluate if a term is always commonly understood or if it needs explanation.
• Use space accordingly: avoid walls of text, aim at a logical division in paragraphs.
• Don’t overthink: an abstract is NEVER perfect and there are multiple conferences, being refused at one it’s not a drama.

📫 Once you wrote it, but before submitting tips

• Ask for feedback: Think about your talk target personas and ask similar people in your network for feedback. Also, ask outside the pool of target personas, you might get interesting external ideas on your content.
• Accept the feedback: sometimes it is difficult to hear that you need to change, but people are there to help you and have different eyes that might help you recognize errors or explain a concept better.
• Refuse the feedback: You don’t have to accept ALL suggestions. Hear, evaluate, decide! You need to be happy with the end result, you are the one submitting. This is also a suggestion for reviewers: it’s important to understand what to say, but also important to know where to stop your duty.
• Learn from mistakes: when asking for feedback, take note of the edit suggestions, you can learn a lot from them. Keeping an history of changes helps.

📦 After submitting tips

• Ask organizers for feedback: especially in case of rejections, ask for feedback! They won’t always be able to give you feedback, but if they do, you can learn how to better craft a message for their audience.
• Loop: once you have a working abstract, send it to more conferences adapting the content to the audience.
• Re-use, refine, adapt: an abstract is a live document, change it based on feedback, experience in delivering the talk, enhancements in the field and target audience.

🍀 Evergreen tip

• Don’t feel bad about rejections: they happen to everyone! If you never start submitting you’ll never start public speaking!

Do you have other tips to share? Or feel some of these are not correct? Would love to make this piece better with your help!