Speaking at Conferences: How to write a talk and get it accepted

At php[tek] 2013, Engine Yard sponsored the Mentorship Summit, a special forum to discuss the value of mentoring to create more connections and advancement opportunities for developers. A common theme that came out of the summit was that speaking at conferences is a great way to further oneself both personally and professionally. During the discussion, inevitably someone said they’ve submitted numerous times but had never been accepted to speak, then someone else said they don’t know how to write a good proposal, and many discussions were had about what it means to write a good talk proposal.

I’ve had this conversation many times over the past few years with those I mentor, but this year something was different: I was a member of the selection committee for Distill, Engine Yard’s first developer conference.

Being on the other side for once has changed how I think about what is important when submitting for a talk and I thought it might be helpful to share how my perspective has evolved.

Questions and Answers

A proposal typically consists of a title, a short abstract, and sometimes a larger body of text to give the reviewers more detail about what to expect in the talk.

The first two items are really important because in addition to helping your talk stand out to the reviewer, they are also how an attendee will choose your talk over others on the schedule.

It’s important to understand that there is an implicit question being asked in the title of your talk. For example, the two talks I presented at php[tek] were:

1. "PHP 5.5: The New Bits"
2. "MySQL High Availability, Disaster Recovery and Load Balancing"

The first one has an implicit question along the lines of: What’s new in PHP 5.5? and the second: How do I make my database more robust and more scalable? How do I make it easier to recover from failures?

Your abstract will then further inform the attendee (and the reviewer) of that question, and more importantly, create an expectation, or even a promise of what the talk will cover.

Most negative feedback I hear about talks isn’t that the speaker was terrible or didn’t know what they were talking about; it’s simply that the talk wasn’t what the attendee wanted. Communicating the intent of your talk clearly is essential. If an attendee is disappointed, it’s often either because he misinterpreted the intention of the talk, or the speaker failed to properly set his expectations.

For example, if my MySQL talk focused mainly on using memcache (as a means to reduce load on the DB and therefore reducing the need to scale) it would have been a terrible talk — though a worthwhile topic, it’s not addressing the question posed by my title and therefore not meeting the promise of the talk.

However, a talk is not always a matter of simply answering a question. Sometimes you are teaching people how to better ask their question. If the talk had been titled “High performance websites with MySQL”, then memcache would certainly be answering some of the implicit question by teaching them how to ask a better question: “How do I make my website faster when using MySQL?”

Is Your Question Relevant?

One of the more important things to remember is to ask the right question. What do people care about? Look at schedules from previous years for the conference (if they exist) to get an idea of what experience level the conference targets, and observe the associated community to see what people are interested in — what are emerging trends and topics that people are fascinated by?

Are you the right person for the job?

A very important thing to realize about your proposal is that who you are matters. To be more specific: why are you qualified to speak on a specific subject, or why do your opinions about it matter?

When selecting talks for Distill, I ran into mostly speakers I was unfamiliar with. So I Googled them.

If you want to establish yourself as a possible speaker, you need to be part of the larger conversation on the subject on which you want to speak. This can take many forms:

• Blog posts
• Tweets with people about the subject (yes, that's right, your tweets can matter!)
• Any other media (podcasts, books, magazine articles)
• Code contributions

The last one takes the longest to verify and is a last resort — if the reviewer hasn’t been grabbed by your title/abstract then they may or may not even bother.

If you are contributing code to projects but doing nothing else, then you should start blogging about what you’re contributing.

Submit Early, Submit Often

This one seems like it will be quite controversial to communities other than the PHP community which has made this the norm: submit many proposals.

When I submit to a conference, I will propose no fewer than four proposals. This not only increases your chances (by the numbers), but when selecting talks, if you have absolutely no other information on a speaker, this will at least give the reviewer a better idea of what you do, and a little more about what experience you may have.

Speaking Experience

The ability to communicate as a speaker is also something to worry about when selecting talks. Having a history of speaking, be it at other conferences, user groups, or even via webcasts/podcasts, is a big plus. Be sure to share all the media from your talks: slides, video and audio recordings. Similarly, podcasts are another way to give great insight into your ability to communicate verbally.

However, even writing can give insight into how you communicate.

Hard skills vs Soft skills Talks

There are two types of talks: so-called “hard talks” that teach technical skills, and “soft talks” which teach personal skills (e.g. team working, project management, how to get hired… how to write talk proposals).

When setting up a conference schedule it’s very important to get the balance of hard skills vs soft skills talks right. Too few hard skills talks, and it’s hard to justify the expense to your employer.

But quite often, the soft skills talks are the ones that get the most people talking, and when you are an experienced developer are often what you need to advance your career.

What this means is that you are far more likely to get a hard skills talk accepted than a soft skills talk — just because of the ratios, and because the few soft skills talks that are selected have to really stand out, typically well established speakers are chosen.

The “Distillation” Process: How We Selected Talks for Distill

For Distill, our review process was what I called “Iron Chef Style”. We rated each talk as follows:

• Content (15 points)
• Fit (10 points)
• Speaker (5 points).

The content is the topic covered, the fit is how well the talk fits into the overarching theme of the conference, and the speaker is not who they were, but what made them the right person to talk on the subject.

Once they were all rated by each member of the committee, we tallied the numbers and sorted by the totals.

At this point, we asked if anybody had any specific talks they felt strongly about, and also used the standard deviation to see which talks have the biggest difference between the different reviewers to start discussion on those.

This gave us our top 32. We then looked at any speaker who had multiple talks in the top 32, and made a decision on which one of them we preferred and removed the duplicates (there were only 3).

Finally, as we further refined our theme, we narrowed our list down to the final 15 — who were selected as speakers for Distill.

I was surprised at just how much of an extremely lengthy and difficult task this was. To anyone who has ever done this with my talks… I promise that my bribes will be much bigger in the future, you deserve it!