NDC Blog

Make me an offer I can't refuse – Writing an abstracts for a CFP

Niall Merrigan -

DISCLAIMER: This is all a personal reflection of my experiences and thoughts in relation to being on a couple of agenda committees. It does not reflect any of the views of any companies or any other committees etc. I am writing it to provide some help to aspiring speakers who are looking to improve their abstracts and possibly their acceptance rate.

TL;DR; Writing abstracts is hard. Write the abstract as if the person reading it, will be making a decision on it in about 15 seconds of reading.

Back in 2015, I sat on my first conference agenda committee. It was a hugely enlightening experience for me. It was the first time to get to see what happens behind the curtain at these meetings and how hard a job an agenda committee have. It is a very difficult job to decide what talks to include and what talks to reject.

I am a long time speaker and I have submitted talks to lots of conferences around the world. Anytime my abstracts were rejected, I have tried to ask why, not as a criticism but to make my abstracts better and also to learn if there is anything that I can do better. Unfortunately agenda committees rarely have the time to do this and I have been lucky to get some feedback from organizers which I have factored in to this post.

What you need to know about agenda committees.

Agenda committees are invariably a small group of people who have a vested interest in making the best conference possible for the greatest number of attendees. They have limited resources in time, energy and speaking slots. They have their own areas of expertise and will have their own thoughts on certain topics.

So let me put the following scene in your mind.

Its 0900 in the morning. You are fully charged and ready to review all the submissions you have received in the Call for Papers (CFP). You sit down, a steaming mug of freshly brewed coffee in hand and open your laptop. You start your browser of choice and log into the conference website where your quarry awaits. You do a quick count and realize that you have close to 900 submissions to review. It is at this point, that you realize that this will be a monumental task to distill this many talks down into the slots you have available.

How does a committee pick an abstract?

I cannot speak for all committees but I am working on the assumption that the following generally holds true.

The committee first reads the title and they will see does it spark any interest. They may also look at the name of the speaker that is submitting and if they have submitted any other talks.

At this point, a couple of different things can happen.

  • Title is interesting to at least one person, read the abstract
  • Speaker is known and considered “good”, read the abstract
  • Quickly scan the abstract to see if anything stands out

You may have noticed that the first two options mean that your abstract is read while the third option means it is scanned. Invariably most of us are in the third category. This is why a solid abstract is necessary.

Before we discuss the abstract, let us first look at the other components.

The bio

Your bio is how you present yourself to both the organizers and the attendees. It should be enough that people can get a feel for you as a speaker.

Make sure to include a bio. The bio tells people who you are. If you do not fill in a bio/profile and we do not know who you are, it means we have to go search for you and that raises the frustration a bit especially when evaluating you against a similar people. I suppose this is different if you are a household name but even those fill in the bio.

Some common pitfalls that I have seen.

Include a photo that is a decent head-shot. This is quite easy. Not all of us are great with names and your picture will jog our memories.

I feel that you do not need to include your marital status, whether you have kids or a dog etc. I think this is more an American thing but in European countries, it is not required. Again just a personal preference.

This does not need to be a CV nor does it need to list all your achievements. It can include some of your previous conferences etc. to give people an idea of where you have spoken before (if applicable)

The Title

A catchy title will help. It does not have to be the funniest, wittiest thing but it should give you enough that you will read the abstract. It should also describe the talk as well.

Below are examples of good titles according to me. These titles are from memory and the abstracts I have seen at conferences. This is not an exhaustive list but just an example of some that I like and why.

  • Brewing beer with Windows Azure - Maarten Balliauw
  • A catchy title, tells me it will be doing something with beer and the cloud
  • Databases: the elephant in the continuous delivery room – Enrico Campidoglio
  • A common problem phrased a catchy way
  • How do you scale a logging infrastructure to accept a billion messages a day? – Paul Stack
  • Problem as a title.
  • Applying S.O.L.I.D principles in C# - Chris Klug
  • Don’t even need to read an abstract to understand what the session is about
  • Embracing HTTP in the era of API’s - Hadi Hariri
  • Doesn’t give a lot away but I imply it will do something with REST and HTTP

The title will be the first thing an agenda committee will see and it should generate a spark. The easiest way to review your own titles. Read it as if you know nothing about the subject and see how you react. Would you go see this talk based on that one line?

The Abstract

Now to the meat of the subject. The abstract is your sell to both the organizers and the attendees. It should be effective enough that on a first scan, people will know what to expect and be able to decide if they should go see it.

I usually go with a four 1 to 2-sentence paragraph approach. This gives the both audiences the breakdown of what I am trying to speak about without being overwhelming. It also focuses me to provide an easy to consume abstract.

This is not a hard and fast rule, but it is something that I use so that I can simplify the process of both writing abstracts and consuming them. I try to write the abstract so that the person scanning the talk can make an informed decision within the first two or three lines.

I will break down my own abstract for my talk “Defensive Programming”. Note I chose my own talk as it allowed me to break it down easily and does not offend anyone (other than myself). After following my own advice, I have rewritten parts of the abstract to make it clearer.

The web is a funny old place. You create a wonderful application; deploy it for the world to see and then everybody just wants to break it.

This session will show you some of the most common security mistakes developers make and how to avoid them. There will be (possibly frightening) demos with code in C#.

This talk is rated level 200-300 with a target audience of web developers (not just ASP.NET. All the examples will be in .NET however if you are not a web developer, some of the parts of the talk will be handy)

It is assumed you have some knowledge of web programming, basic security concepts, a working brain and sense of humor.

So line by line

The web is a funny old place. You create a wonderful application; deploy it for the world to see and then everybody just wants to break it.

This opening sentence sets the scene. It tells you some of the aspects that I will be discussing and allows you to get a general feel if this is something you would like to go see. It is a tag line and could also be a question to the reader.

This session will show you some of the most common security mistakes developers make and how to avoid them. There will be (possibly frightening) demos with code in C#.

Second line, tells you what the presentation will show you or the learning opportunity. In two lines, you should have an idea of whether you would like to see the talk or not. It should distill down the talk to show that you understand what you are going to show and what the learning objectives are. This is where a lot of abstracts fall down, they don't tell you what you will learn by attending the session.

In these two sentences, you have the following information

  • Web Development
  • Web Security
  • C# code
  • Demos not just a PowerPoint deck
  • Security mistakes made

This talk is rated level 200-300 with a target audience of web developers (and not just ASP.NET developers. All the examples will be in .NET however if you are not a web developer, some of the parts of the talk will still be interesting)

The third paragraph tells you the level of the talk and the target audience that the speaker is going for. This is a handy guideline, which will avoid bad speaker feedback by telling the attendee who the intended audience is. The level here is based on the Microsoft standard level concept which is detailed here

In short 100 means beginner with no knowledge and 400 is “deep dive weird expletive™” Most people sit in the 200 and 300 brackets. However, one person’s level 100 is another’s 300 so take these with a pinch of salt.

It is assumed you have some knowledge of web programming, basic security concepts, a working brain and sense of humor.

The fourth paragraph gives you any other information such as prior knowledge, a computer with software installed etc. In my case, it acts as a teaser to say that I do this in a humorous fashion.

Some common pitfalls
  • Poorly formatted abstract.
  • Difficult to read means that people will get frustrated. This might bias any decision for your talk.
  • Spelling errors, missing words etc.
  • A common problem. You think and type. If you do not do a QA check on your abstract, it shows a lack of preparation, which may reflect how you will do your talk. I imply this, and spelling errors annoy me.
  • The abstract doesn’t define a learning objective
  • If it is unclear on what the person seeing your session will learn, then it makes it difficult to decide if it should be included in the conference
  • Abstract is overly long
  • People just give up reading after a while. It is that simple.
I did everything as you said and my talk was still rejected.

There are many reasons why your talk was declined.

  • Larger name speaker with the same talk
  • It is between you and the person that wrote the book/technology/framework. Who would you pick?
  • Another abstract similar to yours looked more appealing
  • This is one of the biggest reasons to decline a talk. Someone has a better abstract or spin on the same topic.
  • Topic was not applicable to the conference
  • Your topic is too niche or the wrong topic for the conference is usually the issue here. If you are doing something that is a bit esoteric then you need to have a good pitch for it. Also submitting a topic that is not in the spirit of the conference will be declined.
  • Session level was too low or too high
  • Beginner talks are welcomed at many conferences but when it is yet another intro to X technology, which is not bleeding edge; it probably will not be picked.
  • You did the talk at a similar conference recently or in a nearby area
  • Note this happened to me with Øredev and they gave me feedback as such. Some conferences have restrictions on performing the same talk again within a specific time-frame and/or geographic area. This can be a contentious point for speakers
Anything else

Some submission forms have a box for additional information and you can use this to sway the committee in your favor. Some examples

  • Video example of previous talks you have done and that are publicly accessible.
  • Put the link in. This will save the committee trying to research you and also shows you have presented before·
  • Previous conference talks given and general ratings if you have them.
  • Two hundred people at your talk and all green. Put it down!

If you are a first time speaker then here are some additional tips

  • Find a mentor to help you.
  • I have been lucky and I have gotten a lot of advice from different speakers over the years on everything from tone to how to build my slide deck. Plenty of speakers are willing to help out with this. Please reach out to me if I can help as well via twitter
  • Practice your talk with your local user group
  • If you have not given the talk before, larger conferences may not be willing to take the gamble. So having a run through of the talk before hand or saying it will be been presented at a local user group will inspire some confidence. It also benefits your user group!
  • Lightning talks
  • If the conference does a lightning talk system, submit your talk as one if possible. It is a smaller gamble and also gives the conference team a chance to see you in action,

So that is it. Again this is all from different experiences so your mileage may vary on this. It is not an exhaustive list at all but hopefully this will help you on your abstract preparation. Call for Papers for NDC Oslo 2017 and NDC Sydney 2017 is currently up www.ndcconferences.com