My Proposal Was Rejected, Now What?

You see a tweet about an open call for papers at a conference you've always wanted to attend. You read through the instructions and suggested topics list. You feel like you've got a winning idea. After all, you spent the last year of your life solving the problem and learning this technology.

You submit to the CfP and wait, and wait, and wait a little more. Finally you see others tweeting their acceptance to speak, but nothing shows up in your inbox. You refresh it again and again. At long last an email shows up from Conference Organizers.

Dear Jeff,

I'm sorry to inform you that we did not select your proposals for this years Awesome Conference You Are Not Going To Be Able To Attend Now. I want to let you know that we had over 500 proposals submitted and were only able to select 30 of them for speaking slots.

We value your submissions and want to encourage you to continue to submit.

If you'd like to attend the conference we are extending our early bird pricing for another month only for people we have rejected. Use code iamareject.

Sincerely, Jeff

What do you do now? There's so many questions flowing through your head. Why didn't my talks get selected? Did my abstract just not convey what I wanted to convey? Do the organizers not like me? Did I say something bad on Twitter? Did I not blog about this subject enough? Did someone else submit the same talk and they are just better than me?

Maybe you take note that your submission covered an area the organizers specifically called out as a topic they wanted to see at the conference. Maybe you don't feel like the selected talks cover this topic at all. Why, then, was your talk not selected?

You want answers. You turn to Twitter, to IRC, you even reply to the email. Why can't someone just tell you why your talk wasn't selected? How hard can that be?

Why was your talk rejected?

I'd wager that most of the time your talk wasn't rejected, it just couldn't be accepted this year. That might seem like semantics and it likely won't take the sting out of the rejection email, but it is accurate. Let's look at a few things I have heard from conference organizers in the past.

  1. There were 500 proposals submitted and we only have 28 speaking slots.
  2. We selected a talk on testing from another speaker and we needed to cover a different topic.
  3. This talk was one of our top picks but the submitter only sent us this one proposal.
  4. We had 15 different submissions covering composer this year.
  5. We just don't like you.

Okay, so number 5 isn't a real thing.

The common theme in the rest of the responses is numbers. It's a numbers game most of the time. If you think about it, a conference organizer has a lot to consider. Pretty high on the list is the budget. There are budgetary consequences to selecting a talk. Beyond that, a conference organizer has a responsibility to the attendees to make sure the program is balanced for thier needs. As relevant as your talk is to you, it might not necessarily be to the expected audience.

The bottom line here is that a rejection is not necessarily a reflection of the quality of your submission. I'll say it again. When your talks are rejected it does not mean they are bad ideas. Every speaker will face rejection.

Why can't the organizers provide feedback by explaining why they rejected my talk?

This question gets asked a lot. It's definitely a valid question. But the answer is likely not what you're looking for.

Most people are looking for something like, "we rejected your talk because you said you were going to cover best practices and you didn't put in the abstract that you were going to cover tabs vs. spaces so we did not accept it." But the answer will likely be more along the lines of, "we had 45 5-star talks and 30 speaking slots, yours just didn't make it into the 30." The reasons why your talk wasn't one of the 30 can be very difficult to pin down and may have nothing to do with your abstract at all.

Given that, how do I get the feedback I need?

Good question. My answer is simple: seek feedback outside of the organizers of the conference that rejected you. Work with people before you submit to a CfP to get a feel for how well your abstract describes your talk and how you can make it more clear. Keep in mind that you have hours and hours to focus on just your talk, organizers have to wade through 300-600 submissions in days.

Find a place where organizers of the conferences you want to speak at hang out. Ask them if they would give you feedback on an abstract. But do it when it's not the time period immediately surrounding the CfP and recognize that they don't owe you feedback. They might be busy, or might not be open to this. I would caution you to use this sparingly, if even at all.

Find a group of people willing to help out other developers. One group is the PHP Mentoring organization. I know several people (myself included) who are willing to look over abstracts and offer advice to new and experienced speakers alike. Hop on Freenode and join #phpmentoring.

You can also take the approach I've seen others use successfully: crowdsource your feedback. Put your abstract into a gist and tweet about it asking people to leave comments and feedback. This is really putting yourself out there, though, so I'd be cautious.

Ask your co-workers, friends, peers, user group, etc. There is someone out there that can help you refine your abstracts.

What's the silver bullet? How do I get selected?

I wish I knew the answer to this question. Frankly, I don't think there is one. I personally have been lucky over the past couple years to be accepted to speak at several great conferences. But I also get rejected a lot as well. Rejection is a reality for speakers.

That said, there are some things that seem to work well for me, and I've seen other people offer similar comments.

Your abstract should pose a problem and a solution

I don't want to make it seem like there is a formula for a successful abstract, because there isn't. Remember the days of the five-paragraph essay? We don't want to go there. But something that I see in many abstracts of talks at conferences is a clearly defined problem space and a proposed solution. Perhaps this is along the lines of "so you're working with legacy code, I have the steps you can use to add some tests," or, "you're hitting a wall with performance tuning of your webserver, here are some tips and tricks we used to scale to 10m pageviews." A reviewer should be able to take your abstract and pull out the subject and what they will take away in a short sentence like I did above.

Submit more than one talk, on more than one subject

This is especially true if you are going to be travelling to the conference. The more than one subject bit is important as well. Too often, subjects you are wanting to talk about are the same subjects others want to talk about. If you only submit one talk and it's about testing, you have some serious competition to defeat. If you're submitting two talks, make them cover different subjects. Try to make them vastly different. You have the opportunity to edge other speakers out with a strong supporting talk.

Think of this situation: There are 45 five-star talks. The conference organizers are trying to decide between your talk on testing and another speaker's talk. Both cover similar ground and both are excellent. But you also have a talk that might be a 4.5-star talk on nginx performance tuning while the other speaker only submitted this talk. You have increased your odds of being selected significantly as they can get two solid talks from you for the one they would have gotten from that other speaker.

Submit your talks again next year

If you've done the work and gotten feedback from people, refined the abstract, etc., submit the talk again next year. Perhaps it didn't fit with the overall conference topic mix this year but next year it might be the shining star. Don't let this slight setback prevent you from putting your best ideas out there.

What if I never get selected?

If you do the things I talked about here, practice speaking by giving talks at user groups, at your company, blogging about the subjects you want to speak about, tweeting about the subects, etc., you will get selected somewhere. I have faith in you. You should too.

Rejection anti-patterns

There are certainly some rejection anti-patterns. I'd like to cover them briefly.

  1. Tweeting about how the conference made a big mistake.
  2. Sending emails demanding an explanation from organizers.
  3. Never submitting another talk again.
  4. Attending the conference and heckling speakers who got accepted.

You get the picture. Remember, you aren't being rejected personally. Your talk might also be the best talk that was submitted. Keep working at it.

More to Read

Flexible Carousel with AlpineJS

I ran across a nice implementation of a carousel primarily with CSS and augmented forward/backward buttons with JavaScript. I wanted to see if I could replicate it using TailwindCSS and AlpineJS. Turns out, I can. Here's how.

Read Post

Simple AlpineJS Component for Multiple Checkbox Selections

If you need to collect selections through a simple checkbox UI without much hassle, AlpineJS can handle serializing arrays to a comma-separated list in forms. Here's how to do it.

Read Post

I am a Technical Lead, But am I a Manager?

In this post I cover my thoughts about tech lead vs managerial responsibilities in software engineering based on a recent title change.

Read Post