Friday, 27 February 2015

Make me an offer I cant refuse–Writing abstracts for conference organizers

DISCLAIMER: This is all a personal reflection of my experiences and thoughts in relation to being on ONE agenda committee. 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 possible 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.

I sat on my first conference agenda committee last week. 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 on a crisp February 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 waits. 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 distil 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 headshot. 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. 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.

My 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#.

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 humour.

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 the aspects 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. 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.

In these two sentences, you have the following information

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

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 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 shit™” 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 to 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 timeframe 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 favour. Some examples

  • Video example of previous talks you have done and that are publically 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 (kudos to Glenn Henriksen for a lot of help on this!)
  • 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

Monday, 2 February 2015

Swetugg resources

Earlier today (02-Feb) I presented at the newly minted Swetugg conference in Stokholm, Sweden. This was my second time in Sweden presenting and as always, it is a lot of fun with the Swedish developer community. Many thanks for the Swetugg committee for inviting me over and letting me wreak havoc with the attendees!

I had the last time slot of the day and the session was the old reliable Defensive Programming 101 which at this stage has been on the go as long as some of the developers attending the conference. This time around however, I had to deliver it in 40 minutes which is extremely tricky given the amount of material that is in the talk right now. That didn’t happen however, and I was still answering questions 20 minutes over the time slot.

Thanks to all who came to the talk and many thanks to the tech people who managed to get the system working under severe pressure. Also thank you to Fabian Miiro for acting as room monitor and also taxi cab hunter for my dash to the airport straight after my talk.

As promised some of the resources from the talk


Some nice tweets and followups from the day.

A write up from Jaime González García