Speaking for Geeks: Getting your session accepted

Proposing a session to a conference can be daunting, and many people who try come away frustrated. They’ll propose dozens of talks and get none of them accepted. They’ll decide that they don’t have the name recognition to be accepted. After all, it’s the same group of people who are always speaking, so you must be part of the group to get accepted, right?

The truth is, your sessions don’t get accepted because your proposals are bad. Sure, the organizers of a conference want a few "names" that can draw attendees, but they’re more interested in great content. Larry Garfield looked at data from PHP conferences and found that half of the speakers had never spoken at a PHP conference before. Not exactly a clique of speakers.

When I say your proposals are bad, I don’t mean there was anything wrong with the subject. It might be bad because it was pitched to the wrong conference. A beginner JavaScript session at an event aimed at experts probably won’t be accepted. A more subtle example is a talk about how to manage APIs at an API industry conference — if most of the attendees are consuming APIs instead of creating them, your talk wouldn’t add anything to their lives.

The first thing to do is to make sure the content of your proposal is appropriate to the audience. Take a look at the past year’s sessions and see what talks were given there. Try and videos or slides of those talks online to see what they said. See who is sponsoring the conference. You can learn a lot about the audience and their expectations by looking at previously delivered content, or at the list of companies who are trying to reach that audience. Your proposal is to your audience, not to the conference organizers.

Most conferences ask for a proposal in the form of a title and an abstract. Many speakers try and describe the exact contents of their talk in these, but what you really should be doing is advertising your talk. The abstracts often are what goes on the conference’s web site and in the program guide. These are what the conference is using to sell their tickets. Give them an ad that sells their tickets, they’ll give you a speaking slot.

Your proposal is the advertisement for your talk. Make sure it sells.

A well written session abstract answers three questions for me as the attendee:

• Who is the talk for?
• Why should I come to it?
• What am I going to see?

"Who is the talk for" helps the audience self-select. It helps them know if attending this session would be a worthwhile use of their time, or if the content will be too simple or two advanced for them. If I were presenting this blog post series as a talk, my "who is this talk for" would be:

Whether you’ve presented at a conference before, or think you have no chance of ever getting a talk accepted

This "who is it for" also helps the conference organizers match your talk to their audience. It shows them that you’ve thought about who their audience is and made sure your talk will be relevant to them.

"Why should I come to it" tells the audience what’s in it for them. People are selfish. They’re not going to come to your talk to make you feel good. They’re not going to come so your company can become more well-known. They’re going to come because they’re going to get something out of it that they can use in their personal or professional lives. You’ll see this theme in future blog posts on the subject. At every stage of public speaking, you should put yourself in the audience’s place and ask "what’s in it for me?"

The "what’s in it for me" for my Public Speaking session would be:

start giving awesome technical presentations, both at conferences and to your customers and co-workers.

What you’re after here is to describe the outcome of your talk, in terms of the audience. What will they know or be able to do after leaving your session that they didn’t know before coming.

"What am I going to see" gives specific, concrete examples of what’s in the talk. This reinforces the "what’s in it for me" by showing them how you intend on making good on that promise. It also further helps clarify "who’s it for" by allowing people to think about the specific examples and see if they’d be useful to them.

The "what am I going to see" for this Public Speaking session could be:

we’ll talk about how to deliver a session that will get your point across, wow the audience, and come off flawlessly every time. Topics covered will include "The SDLC (session development life cycle)", "Giving Good Demo (aka Watching You Use Software is Painful)", and "How I Learned to Stop Worrying and Love the Audience."

You’ll notice two things about this part of the description. First, It’s not a dry, boring list of topics. I made the attendee feel like she’ll be a superhero after the session. I punched it up a little with some humor. If you think of your session abstract as an advertisement for your talk, you’ll want to make sure it’s a good ad that attracts people. Second, it’s not an exhaustive list of everything covered in the talk. It’s a high-level sampling of topics. Long lists are hard and boring to read. No one will bother. And if you don’t list every single subject, that leaves some mystery and gives you some flexibility in what you actually talk about. This is especially good if you’re giving the same talk at multiple conferences and intend to keep it fresh by changing the details here and there.

Now that you’ve advertised your session, it’s incredibly important to live up to that ad. We’ve all been to conference sessions where the description in the show guide didn’t match up with the content of the talk. No matter how good the actual talk was, you left feeling frustrated and confused.

In a multi-track conference, this is an even greater sin, as the attendees had to choose between several sessions to attend, and may have skipped another talk to see yours, only to find that you didn’t talk about what you promised.

The final session abstract for this talk is:

Whether you’ve presented at a conference before, or think you have no chance of ever getting a talk accepted, you’ll come away from this session ready and able to start giving awesome technical presentations, both at conferences and to your customers and coworkers.

We’ve all been there, in the audience struggling to follow the conference session that meanders around aimlessly. Or that spends so much time on setup, time runs out before anyone gets to the point. Or that consists of some guy reading his slides to us. You can do better, and I’ll show you how.

Starting with how to propose a conference topic in a way that will help it get accepted, we’ll talk about how to deliver a session that will get your point across, wow the audience, and come off flawlessly every time. Topics covered will include "The SDLC (session development lifecycle)", "Giving Good Demo (aka Watching You Use Software is Painful)", and "How I Learned to Stop Worrying and Love the Audience."

Once you’ve written your conference abstract, pass it around some friends for review. Good candidates for reviewing are people who attend lots of conferences, speak at lots of conferences, or have ever organized a conference. Cal Evans has a service where he reviews session submissions periodically. He’s organized numerous conferences, large and small, including Day Camp 4 Developers. Their next (virtual) camp is on Speaking for Developers, even.

This is part of a series on becoming a better public speaker. Read the rest of the series.