Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Speaking for Geeks: Getting your session accepted

Freshness Warning
This article is over 4 years old. It's possible that the information you read below isn't current.

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.

Your comments:

Text only, no HTML. URLs will automatically be converted to links. Your email address is required, but it will not be displayed on the site.


Not your company or your SEO link. Comments without a real name will be deleted as spam.

Email: (not displayed)

If you don't feel comfortable giving me your real email address, don't expect me to feel comfortable publishing your comment.

Website (optional):

Recently Written

A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.
The Improvement Flywheel (Apr 29)
An incredible flywheel for the improvement of a development team. Fix a few things, and everything starts getting better.
Managers and technical ability (Dec 26)
In technical fields, the closer you are to the actual work being done, the closer your skills need to resemble those of the people doing the work.
Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?
Building the Customer-Informed Product (Aug 15)
Strong products aren't composed of a list of features dictated by customers. They are guided by strong visions, and the execution of that vision is the primary focus of product development.


Recently Read


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2020 Adam Kalsey.