Pitching Your Proposal

In the tech world it's a rite of passage to speak at a conference. From novice developers (especially those of us who look like an under represented community) to seasoned experts, there is good-intentioned pressure to volunteer time as a speaker. This article addresses the bits after you've decided to submit an abstract to an event.

First things first: conferences are very expensive to put on. At best, they cost organisers time. Larger events will have extraordinary expenses they need to cover. Room rentals, AV equipment, coffee, meals...we expect a lot from the events we attend, and people buying into your session is what pays the bills for the conference organisers.

Your session will be selected if the conference organiser thinks that your session, along with the others they are selecting, will pay those bills (and maybe earn them a small profit). Some speakers will manage to attract an audience just from their reputation. The rest of us need to write a good abstract. Even though I've written three books and have over a decade of experience, about 1/3 of my conference proposals are rejected. Having organised my own tech conferences, I know it's not about me, but rather it's how all of the other sessions will fit together to provide a coherent experience for the attendees. The organisers will be trying to prevent whiplash from topics that are too different, but also provide a range of options to tempt people from a variety of backgrounds.

A great abstract needs to satisfy several target audiences:

  • Conference organisers: by being sufficiently different from other proposals to fit the talk into the schedule.
  • Bosses (and attendees): by having a clear outcome which justifies the cost of the conference ticket.
  • Attendees: By being catchy enough to attract people into the session room during the conference (conferences generally keep stats from year-to-year on how many people attended each topic/speaker).

You can't control what other people are presenting, so there's not a lot you can do to ensure you are different than other presenters. You can, however, make an effort to build your reputation through open source contributions, blogging, and Twitter to make you stand out as the person who should be presenting any given topic.

Pitch the Problem

The first thing your abstract needs to do is explain the problem your session will solve. Your abstract should, in gory detail, make people uncomfortable with how horrible things are right now. Even if you are describing a new language, there is a reason that new software exists. Unpack that reason.

There's no single right way to describe a problem. Here are a few suggestions:

  • Write a list of all the bad things that will happen without implementing your solution (failed deployments? lost revenue?).
  • Describe what's wrong with the older software that you want to replace (security bugs? confusing syntax? maybe it's slow?).
  • Write a list of the good things you want to talk about, but then pair them up with what a "negative" inverse is to this benefit. For example: brings clarity through clearer graphs / dashboards -- flipped: embarrassing downtime by not being able to see strain on infrastructure until it was too late.

(One of my favourite abstracts was titled "Git Makes Me Angry Inside". It was an intro session to learning Git. Eventually this title was replaced with "Git for Teams" which eventually became a book. Sensationalism is fun, but it does have limits.)

In your description of the problem be sure to avoid attacking alternate solutions. You also don't want people to feel bad that they have done the problem you have identified without realising it was the wrong thing to do. No shame, no blame. It's a fine line.

  • Problematic: "Software ABC is so bad that it will ruin your day." Potentially embarrasses people who are using that software and have not experienced the same problems as you.
  • Better: "If you've had problem XYZ from running Software ABC, you may be looking for alternatives."

Brainstorm all kinds of bad things as part of your first draft. Ask your friends and coworkers for other bad things they might have experienced which would be good in your description of the problem.

List Learning Outcomes

The most successful talks I've given have been the ones where I was absolutely hopping about something. Hopping mad about Git. Hopping excited about front end development for Drupal. It almost doesn't matter the topic, so long as I was passionate about it. Conferences are exhausting and overwhelming for attendees. I know that the week after the conference, there's a very strong chance folks who attended my session won't remember a thing I've said. But they might remember the passion I brought to the stage. And if I engaged them, and if they can remember how exciting something seemed, maybe they'll be tempted into doing a bit more research about the thing I was talking about.

But the first thing I need to do is get someone to attend my session.

To get people into my session I need to make some promises about what people will get out of my session. This is the "what's in it for me" part of your abstract. Learning outcomes are a tool used by curriculum developers to establish the definition of done for their lessons. Your learning outcome must answer the question "what can an attendee DO as a result of this session?" ... and they must be able to prove that skill. If it's not a testable outcome, it's not a learning outcome.

More recently, I've been structuring my abstracts to include a bullet list of outcomes for attendees. It's reasonable to have one learning outcome per 15 minutes of presentation. So if your presentation is 60 minutes, it's reasonable to have up to four testable learning outcomes. Caveat: Having learning outcomes won't be a natural fit for all types of session. For example, if your presentation is a case study, it may not have obvious learning outcomes. In these cases though, it's probably your bio (or the company you work for) who's attracting the audience. ... more voyeurism or "birds of a feather" or commiseration.

You can get some sample verbs from Bloom's Taxonomy. For introductory sessions, good verbs include: describe, define, summarise, compare. For more advanced sessions, good verbs include: evaluate, critique, prioritise. If the session is a workshop, you may be able to use "bigger" verbs such as: install, verify, create, build. To write your learning outcomes, simply fill in the blanks:

By the end of the session, attendees will be able to [verb from Bloom's Taxonomy] [topic / action expected].

A full learning outcome would actually include a definition of what the test is, and to what degree of precision you expect people to complete the action. For example: will be able to identify language features as PHP 5 or PHP 7 with 70% accuracy. Don't worry about this for a conference session; focus on outcomes that a boss might be willing to pay for. "describe features of a new language" is not very compelling; but "identify and fix slow running code" might be.

Brush Up Your Bio

Actually, don't write your own bio. Have someone else write it for you. Chances are high you won't be nearly as boastful as you should be. Once you've got a good bio you can adapt it to suit the sessions you are submitting. Generally my bios talk about length and strength: how long have I been working in the industry, and what my experience is with the topic I've proposed. I sometimes add a funny quip as the last sentence, although I've been doing this less than I used to.

To get you started, here's a quick fill-in-the-blank sample bio:

[Name] has been a [descriptive title] since [year]. In this time [pronoun] has [list 2-3 relevant accomplishments]. In [pronoun]'s spare time, [pronoun] enjoys [list one hobby]. You can follow [pronoun] on Twitter at [@handle].

If I were presenting a Drupal talk, my bio might look like this:

Emma Jane Hogbin Westby has been making websites since 1996. In this time she has written several books, presented at (almost) every DrupalCon, and contributed to Drupal core. Emma Jane now works as a Technical Project Manager in Nottingham, UK. In her spare time, Emma Jane enjoys bees. You can follow her on Twitter at @emmajanehw.

A workshop about Git, however, might be a little different:

Emma Jane Hogbin Westby has been teaching version control for over a decade. From CVS to Git, Emma Jane knows how hard it can be to learn version control. Her latest book, Git for Teams, helps teams discover and implement the perfect Git workflow for their project. In her spare time, Emma Jane enjoys single malt whisky. You can follow her on Twitter at @emmajanehw.

Putting It All Together

Once you've got a rough draft of your presentation, get a friend to help you give it some polish. If you don't feel confident showing it to your friends, there are a couple of helpful strangers you can approach. I volunteer with Help Me Abstract and provide light feedback to many of the submissions. Cal Evans also offers more comprehensive feedback through his site. If you're looking for a quick read from a range of people, Help Me Abstract is probably a good fit. If you are looking for mentoring and more feedback, Cal might be a better fit for you.