Speaking at technology conferences can be a very rewarding experience. You get to establish yourself as an expert in your chosen field, meet people outside of your company who do what you do, and often save money since conferences usually cover the registration and travel costs for speakers. However, there is one obstacle between you and those benefits: the proposal selection process.
Most conferences issue a CFP (Call for Proposals) to solicit talk ideas from the public. The CFP is usually a form that asks for things like the title of your proposal, a short abstract, your bio, and other items. You fill out the form and then submit it. But, where does it go?
For years, I had no idea what happened after I submitted a proposal because it went into a black box. I imagined that some artificial intelligence ran complex analytics on my proposal, and this Supreme Intelligence determined if it was worthy of the conference. I just waited until the AI sent an automated email that told me if my proposal was selected or rejected.
Of course, the reality is that conference proposals are reviewed by committees of humans whose job is to select the proposals for the conference. Since most conferences receive more proposals than they can host, the job of the committee is to find the best of the best and discard the rest. Most committees also move proposals on the bubble to a waitlist in case any speaker with an accepted proposal has to cancel.
I learned the true story of how proposals get selected by serving on a number of programming committees for conferences both large and small. It is a tough process of going through hundreds of proposals to find the ones that deserve a place on the conference schedule. I almost always like more proposals than I can approve so I usually have to reject a number of excellent submissions.
Conference programming committees usually view proposals through a web based tool. We see everything entered by the person who submitted the proposal and often things they didn't submit like their past submissions and the ratings given by those who attended their previously accepted proposals. These tools often use a star-based rating system that ranges from one to five stars. Giving a proposal a five star rating means that the reviewer is confident that this proposal should be included in the conference. One star usually means that it should be rejected. Anything in the middle reflects the continuum between an obviously superior proposal and an obviously fatally flawed one. Most proposals fall in the middle. To provide a diversity of opinion, most review systems average the ratings of the reviewers for a given proposal.
As I reviewed proposal after proposal, I began to see a pattern for what made a good proposal. There were certain criteria that, if they were present, made it clear how I should rate any given proposal. Since review systems often use stars to rate proposals, I came up with the acronym of STARS for these criteria. STARS stands for Subject, Type, Audience, Rigor, and Speaker(s). While conferences vary in the information they gather from speakers, every programming committee I've served on cares about these five characteristics (even if they use different words to describe them). I award roughly one star for each criterion successfully met by the proposal.
While large conferences seek a variety of topics, most events have a fixed set of subjects they want to explore. After all, if a conference provides a rich table of subjects that attendees would find interesting, then more people will buy tickets which contributes to the bottom line of the conference budget. A sign that a conference that will lose money is seeing several speakers in rooms with just a handful of attendees. One way to avoid this is to select proposals on subjects that people who read through the conference website will find relevant to their work.
I consider the subject criterion based on whether a proposal meets the spirit and theme of the conference. For tightly focused conferences, this is easy. A proposal called, "Extreme Data Analytics in Python" would not be a subject that many attendees at a Docker conference would find interesting. However, "Becoming a Container Polygot: Docker, Kubernetes, Mesos, and CoreOS" would seem much more compelling.
Being good at coming up with titles really helps evaluators determine if your proposal is on a relevant subject matter. However, in my opinion, clear beats cute. If you can't come up with a creative title for your proposal, then make sure your title at least clearly describes the subject of your proposal. You'll just have to refine your idea in the other sections of your submission.
If your proposal seems like a pitch for a product or service, then I won't think it is on a very relevant subject. Most attendees hate sitting through pitches unless they are clearly marked as being presented by vendors.
Conferences often have different types of sessions including short lightning talks, 30-45 minute sessions, hour long keynotes, and half-day or full-day workshops. It's important that your proposal has the right type. I've seen a surprising number of proposals that want to be half-day workshops but are clearly better suited for a 45 minute talk. Choose your type wisely.
Proposals must clearly detail the target audience of the session. If the proposal writer doesn't know who will come to the session, then the programming committee probably won't either. It's far better to name the titles (software engineers, DevOps engineers, Testers, Visual Designers, Directors, janitors, etc.) of the people who are in your target audience than to say that it will be attended by "everyone".
You should also clearly describe the experience level of the audiences that will get the most out of your session. Is it for a beginner, an experienced professional, or a grizzled expert? Conferences often want to provide programming for different levels of experience so clarity is essential.
It's also important to describe the takeaways that will be provided to the audience when they leave your session. This should be more than just "knowledge". Effective sessions provide attendees with actions they can immediately apply to their jobs when they return to work.
Some CFPs only want a short abstract, but most also want detailed descriptions and notes. Make sure that your proposal has a complete description of the content that will be presented during the session. I love it when proposals include a detailed outline of the session including the time allocated to each agenda item. This is like gold.
If your session requires a technical setup for attendees, then clearly describe that, too. State if they need to bring a laptop and the software (including versions) they need to install before showing up to your session. If you're providing anything via portable storage or networked machines, describe that as well.
A good way to understand the level of rigor needed for successful proposals is to look at the conference site from previous years. Some sites only show the abstracts for accepted talks, but many provide the full description. This is a great way to understand the expected level of detail.
Of course, speakers are the show so they should be qualified to speak on the subject of the proposal and able to present in an engaging way. The two main ways that evaluators can judge speakers are their bio and videos of them in action.
There are many online resources for writing effective bios, but they should at least state what you do and where you have worked. Just like proposal titles, clear beats cute. It's fine to work a little humor into your bio, but you should focus on facts.
Of course, just like resumes, bios often fail to reflect the true capabilities of a person. So, videos are extremely useful for determining how the people who will run the session come across to audiences. Don't worry about the quality of the video. Most evaluators care more about the content of the video and how well you present it. I strongly believe that presentation videos should be included even if the CFP does not explicitly ask for one.
If your proposal includes multiple speakers, then you should includes bios and videos of each speaker. Most proposals provide bios of all speakers, but many try to just include videos of the best speakers in the group (or, the most well known ones).
The STARS criteria provide two main benefits: consistency and balance.
Once the initial excitement about having the honor of influencing the programming for a conference you love wears off, it can be a slog to go through several hundred proposals. The STARS criteria keep me honest by providing a consistent way to evaluate proposals whether I'm starting the first one in my set or are on proposal #171.
The STARS criteria also provide a balanced way to evaluate proposals. If you're a popular speaker who sloppily submits a proposal that is not relevant to the conference, should be a 40-minute talk instead of a 4-hour workshop for your ego, and lacks sufficient detail for the committee to recommend, then your submission will suffer under STARS. On the other hand, if you're new to the speaking circuit, but you've put together a thoughtful proposal that is on a highly relevant subject matter, targeted to a core audience of the conference, and clearly explains what that audience will gain from attending your session? The STARS system will reward you for your diligence.