Why your talk was rejected

The headline for this blog post is a bit sensational. Realistically I can’t tell you why a given talk was accepted or rejected. My own accept:reject ratio is around 1:7 and it would be worse if I count events that never respond at all.

That said, I’ve been on the program committee for three different conferences now. Many of them I’ve done a number of times. Each of these events has been very different but I feel like I have more insight into how decisions about which talks to include are made. I hope I can help folks understand how program committees often work.

The process

All the conferences I’ve worked on do at least part of the talk selection process blind. That means that every talk is rated (usually 1 - 5 or 1 - 10) and the reviewers don’t know who submitted the proposal. This helps eliminate unconscious bias that might give known speakers or community members an advantage. Sometimes I’ll recognize who submitted a given proposal. In that case, I usually abstain from rating the talk so that I don’t bias the results.

After all the talks have been rated the curation phase starts. The organizers take the top third or so of the proposals and try to make an interesting and varied program out of them. This part often involves a lot of hard decisions. If seven proposals on microservices made the initial cut the committee will probably have to narrow that down to only one or two. While some folks would enjoy it, a full afternoon of microservices talks likely wouldn’t have broad appeal.

Another aspect of curation is balancing the targeted skill level of the talks. Most of the events I’ve helped with strive for a mix of beginner, intermediate, and advanced talks. Other events specifically want content that will challenge their attendees. This might mean focusing on Computer Science fundamentals or it might mean exploring the edges of a framework or language to get folks out of their comfort zone. Most events have a general vibe they are going for and part of curation is ensuring the program reflects that.

Curation also involves ensuring that there is reasonable diversity among the speakers on a number of axes. Most events want a mix of first-time speakers and experienced folks that will draw a crowd. Some events want a mix of titles or backgrounds. I’ve attended events where they had a specific target for how many local speakers would be on the program. They did this to ensure that it felt like a community event. Other conferences want to offer travel funding to those coming from far away and take their budget into account when selecting speakers.

Finally, there’s the simple numbers game. Events often have five or more proposals for every speaking slot. That means 80% of people are going to be disappointed. It sucks but time is a limited commodity.

Ways to improve your chances

Follow the submission guidelines

The chance of getting rejected for violating the submission guidelines is low but why take the risk? If the event asks you not to include personal details, don’t include personal details (or links to twitter or YouTube that will identify you). Read track descriptions before selecting a track for your talk. Follow character/word limits. All of these things are pretty simple but they can make a huge difference. Talks that don’t fit into the track are unlikely to be selected. Talks that don’t follow the guidelines make extra work for the committee.

Write well and be concise

I hate writing. I especially hate writing talk proposals. But I like giving talks and writing the proposal is the price of admission for giving the talk. I try to have my proposals reviewed by a friend or co-worker before they are submitted. I also run them through a tool like grammarly to catch the most egregious errors.

Also, try to be concise. In the Ruby community, it is not uncommon for a single-track, regional conference to get 100 - 200 proposals. Shorter proposals are more likely to be read in detail or multiple times. Usually, I read the title and abstract and then speed read the remaining sections. If I have questions or concerns about the talk I look to see if the speaker addresses them. I feel a bit guilty about not reading every word in detail but attendees won’t be reading every word in the program either and part of my job is to act like an attendee and pick talks I’d want to attend.

But, don’t write proposals that are too short either. I should be able to tell what your talk is about and what I’ll learn from the abstract and title. The other sections of the talk should address any concerns I have. If your talk involves live demos have you done them successfully before? If your talk is a hard format to pull off (culture, a collection of stories, an intensely technical topic in a short amount of time) why are you confident you can do it successfully? If the proposal is unclear about exactly what you’ll cover or how you’ll teach the content include that as well. Finally, consider addressing why this topic is important and/or why it is a fit for the event. This is a great place to speak to the event’s vibe or how much you enjoyed previous events.

Practice Humility

Make sure your proposal doesn’t come across as bragging. You could say things like “I’m the foremost expert on XXX” but you’ll probably have better luck if you say “I’ve successfully talked about this topic at three meetups in the past year”. You don’t have to be excessively humble but even when I know I can do a good job of a talk I won’t say “I’ve done a similar talk in the past and got rave reviews.” Instead, I’ll try to provide evidence and use polite but confident language. For example, “I know the collection of stories talk format is challenging. I’ve successfully done talks with this format and I’m comfortable doing it again. The unifying theme of my stories will be XXX.” This addresses a potential concern of the committee by saying I’ve been successful before but they don’t have to take my word for it since I show I’ve thought about the issue and have a plan to mitigate it. When I was a new speaker I would say “I’m a relatively new speaker but I’ll practice my talk with my co-workers and/or my local meetup to ensure I work out any snags before the event.” I think this made organizers more comfortable taking the risk of accepting my talk.

Also, as a general tip, I try to avoid talks that are product/gem pitches or all about my company. If your proposal contains sentences like “I wrote XXX and want to give an overview of it”, “learn about product XXX”, or “my company is super cool, here’s what we did!” you have a higher chance of getting rejected. Instead, try focusing on the problems your gem/product solves and how knowing about it will benefit attendees. You can also focus on any particularly interesting challenges that you or your team have overcome and how attendees can apply the lessons you learned to their own lives.

Submit multiple noticeably different talks

This is the most important tip. Make sure you submit a couple talks on different subjects. Pick topics that are interesting but not insanely popular. Containers and functional programming are really popular in my community right now. I like both of those topics and have done talks on them in the past but I’m avoiding those topics right now so I don’t have to compete with as many other proposals. Instead, I’m picking topics that I hear people talking about at meetups or on nerdy news sites.

Look at the track list and past programs for events and try to figure out what is likely to be over-represented in the submission pool and don’t submit on that if you can avoid it. One event I submit to every year often has a lot of advanced technical talks and culture talks so I try to submit a beginner or intermediate technical talk. Usually, that means I’m competing against fewer similar proposals which increases the chance I’ll get a talk accepted. Also, ask the organizers or others in the know if there are topics that a conference will never select. For example, one well-known event generally wouldn’t accept testing talks.

Currently, I try to submit three talks to an event I really want to attend. Ideally one is a completely new talk and all three are significantly different from each other. My current strategy is one culture talk, one technical topic that I feel is “up and coming”, and something that is technical, a bit obscure, and beginner friendly. This way if a conference gets a ton of culture/career talk proposals I still have two other ways to get accepted. Several speakers I respect do the same thing and I’ve seen this strategy work again and again.

The vast majority of feedback I’ve given to folks after acceptance/rejection emails go out was “You wrote a great proposal on a cool topic. There were five other proposals on basically the same topic and another proposal did a better job balancing the program.” That sounds like the conference equivalent of “it’s not you, it’s me” but sometimes that was just how the CFP process went that year. Dumb luck plays a role in acceptances as well.

Final thoughts

The worst part of being on a program committee is knowing you have rejected good talks. I always know I’ve rejected a talk that would be better prepared and presented than a talk that got accepted. I feel especially bad when the folks I consider friends and look up to get their talks rejected. But putting together a conference program isn’t an exact science and I do the best I can and know that other committees do the same. After you’ve put your best foot forward it is usually just a matter of luck.