Rejection & Revision: On Improving Conference Proposals

One of my goals for 2018 is to speak at more tech conferences.

Although I gave talks at two conferences in 2017, the call for proposals (CFP) process still feels opaque to me. Submitting a talk proposal to CFP reviewers is like dropping a letter into the void: usually, the only contact I receive from the reviewers or organizers about my proposal is an email stating whether they accepted or rejected my talk.

Newcomers to the technical speaking circuit haven't mastered the CFP process yet. Receiving so little feedback – an auto-generated rejection most of the time – leaves them without a clear path to improve their proposal for the next CFP.

For an industry that prides itself on iterative development, the black box nature of CFPs feels particularly egregious to me. If a conference wishes to invest in scouting fresh technical speaking talent, feedback besides (and even before!) acceptance or rejection should be high priority.

Despite the flaws of the CFP process, I have developed strategies to turn the rejections I receive into better proposals. I'll share the steps I took to turn my most recent rejections into revisions in the hopes that it will assuage the discouragement of speaker-hopefuls (like you!) and provide them with actions that they can take to improve their talk proposals.

Ask for Feedback

I emailed two conference organizers asking for their reviewers' feedback on my proposal. Both organizers were quite willing to share this information with me.

Before I provide excerpts of this feedback, I'd like to introduce a framework that I use to sift the useful feedback and discard the fluff: Lara Hogan's card suits. In her book Demystifying Public Speaking, she elaborates:

• Hearts: "feedback that is positive, but not specific"
• Diamonds: "feedback that is positive, and specific or actionable"
• Clubs: "feedback that is negative, but not specific or constructive"
• Spades: "feedback that is negative, but gives specific suggestions"

After receiving a rejection, speakers and speakers-to-be should seek diamonds and spades from the organizers. I'll categorize some of the feedback I received for my rejected talk proposal:

"The audience participation section feels like something that would work great in a small meetup group or a tutorial session at a larger conference, but probably won't go quite as well in a 400-person single-track event."

I consider this feedback a diamond. As someone who has never spoken in front of a 400-person audience, it would be impossible for me to ascertain this fact without the wisdom of a seasoned conference speaker or organizer. This ill-placed audience participation could mark me as unprepared to give this talk, which is untrue. I have since removed this section from my talk proposal.

"[Topic] was not a topic that we saw other people submitting talks about. That is also a great feather in your cap for the uniqueness factor."

I consider this feedback a heart. When speaking with this organizer, it was clear that the reviewers liked my proposal, but not enough to select it.

"I think restructuring the talk/proposal to show evidence of why... [would make] you and your material sound more authoritative than anecdotal."

I consider this feedback a diamond or spade, depending on how negatively the organizer connotes the word "anecdotal." I have since cut out any weak language in my talk proposal and put more emphasis on explaining the why.

I'm grateful to these conference organizers for providing me with mostly diamonds – feedback that I can use. When asking for feedback on a rejected talk proposal, push for those diamonds and spades.

Look to the Abstract

Of all the sections of a talk proposal, the abstract is the canary in the coal mine. If the abstract is bad – meaning unclear, illogical, or underdeveloped – then the rest of the proposal probably follows suit.

Before I continue talking about the abstract, I'd like to outline the anatomy of a talk proposal. Typically, it has these three parts:

• Abstract: short, elevator pitch that motivates the talk and summarizes the desired outcome
• Description: talk outline
• Notes: any additional information, especially why this speaker should give this talk at this conference

Since the abstract is often the first thing an organizer or reviewer sees on a talk proposal, it sets up their perception of a given talk. Even though abstracts tend to be looked at first, they should be written last: as in scientific research papers, abstracts act as introduction, content summary, and conclusion.

The best way for a speaker-hopeful to vet and improve their abstract is, paradoxically, to elucidate their talk description. Writing a razor-sharp description can help the speaker determine the biggest selling points of their talk, which is exactly what they should share in the abstract. I'll discuss honing the talk description more in the next section.

Speakers can also ameliorate their abstract by tailoring it to the unique traits of a conference. If a speaker-hopeful wishes to present at a Ruby conference, then their abstract should include how their talk benefits Ruby developers. Even language-agnostic conferences have traits that a speaker can reflect in their abstract – all it takes is a little research to find their quirks! Tailoring an abstract to a conference can convince reviewers of the talk's value-add for their audience.

The abstract that I submitted to conferences in September and October was, admittedly, not a good reflection of my talk description. It also was not tailored to the special characteristics of each conference. My abstract – and overall proposal – feels much more polished now that I have addressed these flaws. But, in order for me to strengthen my abstract, I first had to edit my description.

Whittle Down to the Essentials

As I mentioned earlier, the talk description influences the direction an abstract should take. An airtight talk description leads to an airtight abstract.

The description section of my rejected proposal was thorough but lacked direction. I was trying to sell the audience on a thesis muddled by too many arguments.

When I put together slides to give this talk at a meetup, I leaned on one of these arguments more heavily than others. This made me realize that my talk description didn't accurately reflect what I wanted to talk talk about. Instead of including every possible argument for my thesis, I rewrote my description with a focus on one.

My choice to narrow the scope of this talk was validated at the meetup: attendees loved the clear cause-and-effect relationship that I presented. Confidently settling on a focal point for my talk also helped me eliminate wishy-washy language in my description, and as you can imagine, whittling down my talk description helped me write a stronger abstract for the next round of CFPs.

But not every speaker-hopeful has taken the opportunity to practice their talk in front of an audience before applying to speak at conferences. Another technique that speakers use to find the linchpin of their proposed talk is the conclusion framework.

I learned about the conclusion framework from Bill Kennedy. He shared it with me as an exercise for succinctly expressing the purpose of my talk.

Here's my take on the conclusion framework:

• I believe... [thesis]
• I have shown you... [argument(s) that support thesis]
• We now both agree on... [reworded thesis]
• Go forth and... [call to action]

I recommend that every speaker-hopeful fill in these four sentences at least once per talk proposal. The conclusion framework acts as the speaker-hopeful's North Star: it will keep them on track as they revise their abstract and description.

Try a Meetup

Although talk proposals can be revised alone, there's nothing like presenting a talk in front of an audience to discover where a talk shines and where it flops.

When speaking at a meetup – especially a more intimate one – I preface my talk with instructions for my audience: feedback, please! I share my Twitter handle on every slide in my deck to encourage audience members to reach out. In the parlance of card suits, those who tweet at me usually share hearts.

To dig for more diamonds and spades, after the conclusion and Q&A I like to ask the audience some questions of my own beyond "Any thoughts?":

• "Do you have any criticisms of my talk?"
• "How did you feel about [slide]"?
• "Was there anything I said that didn't feel clear?"

One diamond I received at a meetup was that I sometimes use uncommon words – English words, not jargon – on my slides. Given that my talk deals with words more than code, utilizing language that will keep the audience engaged matters deeply to me. I never would have received this feedback without presenting in front of audience members who don't speak the way I do.

Finding a meetup to speak at seems like it would be just as daunting as submitting talk proposals to conferences, but it's been so much more relaxed in my experience. I search Meetup for meetups in my area that interest me and email the organizer(s) to see if they have any open speaking opportunities.

Keep Submitting

At the end of the day, there's only one way for a newcomer to speak at a conference: by continuing to submit talk proposals to conferences.

I hope that, by sharing with you – the speaker-hopeful – how I bounced back from my recent talk proposal rejections, you feel empowered to improve your talk proposals and own the next round of CFPs. Anytime you feel discouraged by rejection, remember that you can channel that negativity into actions that make your talk even better.

Resources

• Demystifying Public Speaking by Lara Hogan
• HelpMeAbstract
• On conference proposal rejections by Tracy Osborn
• What Your Conference Proposal Is Missing by Sarah Mei

Acknowledgments

Thank you to everyone – and I am fortunate there are so many of you! – who has helped me navigate the labyrinthine world of technical speaking. This blog post wouldn't have happened without your support.

Photo credits to Unsplash and #WoCInTechChat.

Enjoy what you read? Spread the love by sharing this piece. Have thoughts or questions? Reach out to me on Twitter or in the comments below.

This blog post was originally published in Chronicles of a Junior Dev, where I've been blogging about my first year as a software engineer. You can keep up-to-date with Chronicles by following me on Twitter.