Just over a year ago, I put together the crudely-titled "Quick Thoughts on Not Writing a Crap Abstract" after reviewing a few dozen conference abstracts. This time around I’ve had the honour of being on a conference programme committee and with it the pleasure of reading 250+ abstracts—from which I have some more snarky words of wisdom to impart on the matter.

Remind me…how does this conference game work?

Before we really get into it, let’s recap how this whole game works, because plenty of people are new to conference speaking.

  1. A conference will usually have a "call for papers" (CfP) that is open for a period of time, during which you can submit your "paper". Except, this isn’t an academic conference to which you actually submit a paper for peer-review prior to presenting it. Technical conferences generally work on "abstracts".

    Your abstract is a description of the talk that you intend to give. At this stage its sole purpose is as a "pitch" to the conference programme committee. You do not need to have written your talk before submitting the abstract. In fact, if it’s a new talk, I wouldn’t write it until you get it accepted somewhere. Abstracts let you test the water for an idea, and once you have an audience for it, then you can develop it into a talk.

  2. Once the CfP has closed (and occasionally before) the conference’s programme committee will review all of the submitted abstracts.

    Allow me to let you into a dirty little secret: not every abstract is always going to get read in its entirety and at length. Conferences will have hundreds (if not thousands) of submissions, and most of the time the programme committee will be volunteers kindly giving up their time.

    Consider this: if you have 200 abstracts to review and spend just two minutes on each, that’s already nearly seven hours. And think what you can actually do in that time (including the context switching between subjects, opening the abstract, logging the score). It’s not a lot…scan the title, start reading the abstract…tick tock…DONE. NEXT ABSTRACT.

    Even allowing for a more leisurely review process, the point still stands: you need to stack the odds in your favour because in general if your abstract is not crystal clear people are not going to go searching through it to discern what you meant - it’ll just go onto the 'maybe' or 'nope' pile.

  3. The programme committee decides on the talks to accept and send out notifications.

    • Your talk got accepted? Yay! Now you get to go and write it :)

    • Your talk didn’t get accepted? Never mind. In 2019 I got accepted by 57% of conferences to which I submitted - which is the same as saying that pretty much half the conferences reject every submission - and I’ve been doing this a while so know a thing or two about crafting abstracts. Not to say they couldn’t be improved, but just to give you an idea of how often you might strike out.

Don’t hold off submitting to speak at conferences until your dream conference (Kafka Summit, obviously) comes up. I’m not saying to submit your talk to every single conference ever. But I am saying get practice in writing abstracts, navigating the CfP process, and getting experience speaking - all of these will help you, in the long run, to load the dice in your favour when it comes to conferences at which you really really want to speak.

Show that you care

If you’re serious about wanting to speak at a conference then I would recommend that you invest some serious time in preparing your abstract. You need to do everything you can to show the programme committee of a conference that you deserve that speaking slot.

One way that you do this is by showing that you have taken the CfP process seriously. Just like teachers at school could spot the homework that was done whilst sat on the bus ride to school the day it was due in, the same goes for your conference abstracts. Abstracts that are mistargeted, lazily written, poorly spelt (plus all the things I list below too) shout out "Yeah I fancy speaking at your conference, but I’ve got better things to do than spend time on this…but can I do a talk anyway?". Or to put it more simply from how the programme committee might see it when weighing up your abstract against others: "'Do I feel lucky?' Well, do you, punk?"

Here are some concrete ways you can ensure you’re doing everything to prepare your abstract:

  1. READ THIS ADVICE! Not just mine, but all the other advice that’s out there. You would be surprised how many people don’t. A lot of this process is 'playing the game', and these kinds of blogs all spell out the rules to follow:

  2. Proofread your abstract. Read it out loud (not just mutter it under your breath, but actually out loud). Proofread it again. Use Grammarly to proofread it. There is no excuse for spelling or grammatical errors and they give a REALLY bad impression for your abstract because they imply a lack of attention to detail that the programme committee might assume will be present in your talk too.

  3. Get others to review your abstract. Put it in a Google Doc, give people comment access, and send them the link. A couple of tips for getting the most out of this:

    • Don’t do it the day before the abstract is due in. Make sure there’s enough time for you to review the changes that might be suggested.

    • Respect the reviewer’s time. Don’t send over a draft abstract you just chucked together. It’s not their job to write it for you, but to help you write a good abstract. Make sure you’ve read some of the material I’ve linked to above and that you’re not repeating some of the basic mistakes that show you’ve not really spent any time on this.

  4. Get some speaking experience. This is not about the abstract as such, but speaking in general. Speak at meetups. If a reviewer is wavering on your talk then you having zero experience may push them to reject. Meetups always want speakers—it’s a great way to trial your talks, develop your relationship with the community - and to increase your hours in front of an audience.

Why didn’t my talk get accepted?

Whilst these are specific to a Kafka-focussed conference, the premise of them will be transferable to other technologies.

  • Scale alone does not get you a speaking slot. I don’t care if you’re processing 1 gazillion messages - that in itself is not a 45-minute conference talk.

  • Just because you use Kafka in your architecture doesn’t itself mean that the audience want to hear about your bespoke Llama-shaving software you wrote with it. Make the talk about the technology or the problems you solved—not the bespoke software that you wrote (that’s just your vehicle for the story that you’re going to tell).

    Kafka is a fairly mature technology now. "Show & Tell" is not enough. Just because you have a system using it in Production, that’s not enough. You need something engaging; a hook, a story. "We’re using Kafka, we’ll talk about the problems we encountered" is not compelling. It’s the same as probably 75% of the other abstracts.

  • Pay attention to the conference subject(s). If it’s a Kafka conference don’t submit a talk that’s about a technology that’s not Kafka unless you can clearly explain in your abstract why it’s relevant.

    Your use of the technology needs to be relevant too. If you use Kafka to stream your messages in but then your talk is 90% all about how you use Spark to process them I am going to wonder what it’s doing at a Kafka conference. Maybe a great talk for Strata, but not a Kafka conference.

    Read the CfP closely - conferences will say what kind of talks they want, what subjects and technologies they want.

  • Kafka and Kubernetes, it’s so 2019 😜. Either get ahead of the BS curve if that’s your intended route in for a talk—or if you do want to talk about something that’s now "early majority" then make sure you’re pitching beyond simply "hey <buzzwords!>" and instead have something to say about it that others don’t.

Abstract specifics

Here are some of the common mistakes that I’ve noticed people make. Some of them you might disagree with, but in general if you can check off all this list as things you’ve avoided doing then you’re off to a good start.

  • I don’t care what your system’s internal name is and nor do conference attendees. It’s just confusing, even if it’s the wittiest acronym ever.

  • Think about the audience. What are they going to gain from attending your talk? Ensure that your abstract makes that clear. If you’re talking about an implementation then focus on something relevant within what you built that you want to share with people for them to benefit from.

    An analogy would be the 1000 photos from your latest holiday. Do you take five photos of that 1000 and weave a good story around each one, or do you subject someone to every single step and sight of the journey with every one of those 1000 photos?

  • Capitalise your words correctly (Kafka has a Kapital K!) ESPECIALLY in your titles! If you don’t then it looks sloppy and gives a bad impression from the outset.

  • Don’t include all the URLs! Especially if it’s plain text then a dozen http:// quickly pollute the readability of the text. You only need one or two at the very most. You’re writing an abstract, not a blog.

  • "If there’s time" / "Bonus content if time permits" - don’t put this in your abstract. Either cover <x>, or don’t. By putting this in you’re suggesting to me that you don’t really have a handle on what your talk will be like.

    Pro-tip: no-one will actually read your abstract back against the delivered talk. So long as you don’t completely lie and deliver a talk about Mozart when you promised the crowd Meatloaf, you are fine to ad-lib content that wasn’t included in your abstract.

  • Just as you should not be terse in your abstract, do not be too verbose.

    • The reviewer will get bored and be desperate for a tl;dr

    • it suggests that if you cannot be clear and concise in your abstract maybe your talk will also be waffly and wordy.

  • Don’t submit too many abstracts. If I see your name multiple times my eyes as a reviewer start to glaze over. Pick a small handful of your best topics and pitch those. Focus on the conference and work out which is likely to fit best. If you really have half a dozen talks that are all perfect for the conference then just pick the ones that you would like to deliver most.

  • The few hundred words that you have in your abstract are your only opportunity to pitch your talk to the programme committee. Take care with those words and make them justify their space on the screen. Don’t assume that the programme committee will have mind-reading powers and will somehow magically know what an amazing talk you might give - lay it out in front of them in the abstract.

  • Links to talks and blogs are useful to indicate that you’ve got experience in the subject, but they are not a substitute for a good abstract. Chances are the programme committee won’t have time to read and watch them, so you still need to nail the abstract.

  • Use white space! Use paragraphs! Confronted with this, how many people will take the time to pick through it?

    ks02

    Compared to this, where the paragraph breaks make it nice and easy to grok:

    ks01

This from Jason Yee should be emblazoned on every CfP submission page everywhere:

Thoughts? Questions?

@ me on Twitter!