Four kinds of talk proposals that get rejected from !!Con

It’s that time of year again: I’m working on organizing !!Con (“bang bang con”), the conference of lightning talks about the joy, excitement, and surprise of computing that’s held each May in New York. This month, the !!Con team reviewed nearly 300 (!) submissions that we received in response to our 2018 call for talk proposals.

In addition to the letter grades that each reviewer gives to each proposal, this year I also tried to write a sentence or two for each talk I reviewed, explaining why I gave it the grade I did. As I wrote these explanations, a few themes emerged in the kinds of talks I was giving less-than-enthusiastic reviews to. I want to talk about what these were and offer advice on how to avoid them, in the hope that someone will find my advice useful when they’re submitting talk proposals to future !!Cons, or other conferences like it. (For conferences that aren’t much like !!Con, keep in mind that this advice may not do much good, and may in fact be misleading.)

The time-less talk proposal

!!Con talks are meant to be ten minutes long.¹ On our talk proposal submission form, one of the things we ask prospective speakers for is a “timeline”, or a summary of how the speaker plans to use their ten minutes of stage time. The timeline helps us make sure that the speaker understands the lightning talk format, and that they’ve put some thought into making sure that their talk will fit into the allotted time.

Most other calls for talk proposals don’t ask for a timeline, so even people who are frequent conference speakers don’t always know what we’re asking for here. As a result, every year we get some talk proposals that completely fail to provide any kind of reasonable timeline. Some people use the timeline as a place to continue their abstract. I’ve even seen people just copy-paste their abstract into the timeline field on the form. Other submitters seem to think that by “timeline”, we’re just asking how long the talk will be — for instance, we got a couple this year that just had “10 minutes” listed as the timeline. (We’re not asking how long your talk will be — we already know how long it’s supposed to be! We’re asking how you’ll use the time.) And even more absurd than “10 minutes” was the one we got this year that said “20 minutes”! That’s pretty clear evidence that the talk submitter doesn’t know what !!Con is and didn’t bother to read what the call for proposals was asking for.

Timelines aren’t legally binding agreements, of course. We expect that most speakers will rearrange things a little, or even a lot, between when their talk proposal is due and when the talk actually happens. The important thing is for the speaker to show that they can come up with a plausible-sounding plan for fitting their talk into ten minutes. For advice on how to do that, see my post “How to write a timeline for a !!Con talk proposal”, which has several examples.

The boringly-titled talk proposal

We have a policy at !!Con that talk titles have to include at least one exclamation point.² However, an exclamation point isn’t sufficient to make a title exciting. Consider the following four titles:

• “Bending the Laws of Physics! Or, How Wi-Fi Keeps Getting Faster.”
• “Preserving Digital Art and Games for 100 Years!”
• “What alien invaders, birds, and computer simulations have in common: flocking!!”
• “Introduction to Data Analytics with Apache Spark!”

One of these things is not like the others. The first three are all titles of talks that were actually presented at !!Con (by Kiran Bhattaram in 2015, wilkie in 2016, and Jan Mitsuko Cash in 2017, respectively). The fourth is representative of a class of talk proposals that get rejected. I’m not trying to pick on Spark in particular here — it’s just an example — but “Introduction to Data Analytics with Apache Spark!” sort of looks as though the submitter just took the title of a talk they’d given at another, more traditional conference and stuck on an exclamation point on the end.

Fortunately, titles are easy to change. In fact, we do sometimes ask people to change the title of a talk after it’s been accepted. When we can only accept about 30 proposals out of nearly 300, though, a boring title can be enough to push a talk into the “reject” category. So, instead of giving us a reason to reject your otherwise amazing talk, come up with an exciting title that shows us how excited you are about giving the talk!

Another thing to keep in mind regarding titles is that at !!Con, your talk’s title really doesn’t have to serve as a stand-alone summary of the talk. At bigger conferences, where there are a hundred talks and lots of tracks to choose from (and where a talk is usually more than ten minutes long, so choosing any given talk is a larger commitment), attendees often scan through titles to decide which talks to attend, and so some speakers will try to pack their talk titles with descriptive keywords that they hope will attract attendees. But !!Con is a single-track conference where there’s time for attendees to read all the talk abstracts, and every talk is well-attended, so a title like “A Shot in the Dark!” works well even though it doesn’t explain what the talk will be about. In fact, titles that don’t reveal all the details are a great way to pique the audience’s curiosity.

The “this talk will make you more productive at your job!” talk proposal

We get a lot of talk proposals that purport to show the audience how to achieve a practical goal — get more done at work! write more maintainable code! ship a product! — or that purport to teach a specific skill or a way of thinking about programmimg. These kinds of practical, be-more-effective-at-work talks go over well at many conferences, but we find that most of the time, they don’t work so well at !!Con.

Why not? I think it’s because most people don’t come to !!Con with the goal of learning practical skills. Rather, they come to have fun and ignite, or reignite, their excitement and curiosity about computing. It’s not that people don’t pick up useful knowledge to improve their craft from talks at !!Con — to the contrary! — but it’s a question of how the knowledge is presented. My advice to talk submitters is to aim for whimsical rather than practical. Tell a compelling and engaging story of how a project got done despite obstacles (like the story of how Lisa Ballard and Ariel Waldman built spaceprob.es using an undocumented NASA API!), or share an interesting concept for its own sake (like locality-sensitive hashing!).

Some !!Con talks, like Bomani McClendon’s great talk last year about building giant animatronic glowing mushrooms, do include “lessons learned” and high-level takeaways, but those high-level takeaways work because they’re presented in the context of a specific project or a specific concept. One of the high-level takeaways for Bomani’s talk, for instance, had to do with how he came to see software as a medium for art, and himself as an artist, as a result of writing software for an art project. But if the title of his talk had been “Level up as a programmer by seeing software as an artistic medium!” rather than “Making Mushrooms Glow!”, it wouldn’t have been as strong of a talk proposal.

These kinds of differences in framing can be quite subtle, but the good news is that if you submitted a talk proposal of the “this talk will make you do better work!” variety and it was rejected, it might not take much effort at all to reframe it as a talk proposal that would be a great fit for !!Con. Consider revising and resubmitting it next year!

The “everyone at this conference shares my background, goals, and motivations” talk proposal

!!Con attendees and speakers come from a wide variety of backgrounds — they might design games, build smart watches, study geometry, or develop interplanetary spacecraft flight software. A given audience member may or may not know much about any of these topics. But even talks on very narrowly specialized topics will have something to offer to both specialists and non-specialists, if they’re done well. (The lightning talk format helps: in our experience, just about anything can be interesting for ten minutes if it’s presented well.)

So, narrowly focused talks are great. The problem arises when speakers make incorrect assumptions about the audience’s background, goals, or motivations. We get a lot of talk proposals that aren’t a good fit for !!Con because they assume background that not everyone in our audience has, or goals that not everyone in our audience has. This can happen, for instance, when people take a talk they’ve previously submitted to a more narrowly focused conference and try to reuse it for !!Con. If you send us a talk proposal that you previously sent to PopularMachineLearningToolFest or JavaScriptWebFrameworkOfTheMomentConf, you’ll probably need to make some changes to the way you’re framing your talk to make it suitable for !!Con, regardless of how wonderful PopularMachineLearningTool or JavaScriptWebFrameworkOfTheMoment are.

Will you have to rewrite your existing talk proposal from scratch? Maybe not! Removing assumptions about shared background and goals from a talk proposal could be as simple as changing a sentence like “We all need the web apps we build to work well on mobile devices” to “I needed the web app I built last year to work well on mobile devices”. As a bonus, making the talk more personal can also make it more compelling, because it becomes a talk that only you can give.

Thanks to Stephen Tu, Laura Lindzey, Michael Malis, Julia Evans, and Erty Seidohl for feedback on a draft of this post.