A photo of someone grading papers. I did not actually give anyone an A+. Nor did I get the chance to write “see me”.

Since last fall, I’ve been pitching (and giving!) talks at tech meetups and conferences. So far it’s been an excellent way to hone ideas, meet new people, and learn more about the things I thought I knew. (Nothing like the stress of having to tell people what you know about something to make you really study up!)

This month, I marked an additional milestone: I was given the opportunity to be a conference session reviewer. I read hundreds of pitches over three categories for an upcoming conference, and what I learned about what makes a good session pitch both surprised me and didn’t.

  1. Titles REALLY matter. I’m a sucker for a pun or just a clever title. A boring title, on the other hand, can prejudice reviewers against otherwise great content!

    But a title that is clearly just pasted on also doesn’t work for me. I know there are people who decide up front that their talk is going to be, IDK, Avengers themed, and so they come up with a title that references the Avengers and then try to shoehorn their talk into the theme. Maybe some people are into that, but it’s not my thing.

  2. There’s a sweet spot for submission length. Maybe about 300 words, including a bunch of bullet points? I saw presentation pitches that were one or two sentences long, and I saw presentation pitches that were so long they caused a major vertical scroll on an otherwise pretty compact review page. Too much information can actually be a negative.

  3. Please, run spellcheck before you submit. I tried not to deduct points for submissions that contained spelling errors, grammatical mistakes and misplaced punctuation, because certainly people present differently than they speak, but it’s a pretty easy thing to fix and doesn’t reflect well.

  4. Tailor your presentation to the venue! Many conference submission platforms let you store reusable talks. This is great and it can save you a ton of time to start from a non-blank page. But you shouldn’t just hit submit blindly. After copying the talk to your submission, make sure that it’s a fit for the specific RFC.

    • Did you submit a day-long workshop for a conference only accepting 30-minute slots?
    • Did you propose a frontend talk for a conference focusing on backend?

    These examples are perhaps obvious, but there are less obvious ways your content might not be a fit (or could be a more obvious fit with some tweaking).

    Let’s say you want to give a talk on hidden features in your favorite IDE. If the conference is Javascript focused, the examples you give in your bullet points should call out features that work with Javascript. If the conference is dev tooling focused, maybe you have examples that span languages (and you explicitly point out that your talk is language-agnostic).

    These are small tweaks that shouldn’t take a long time when you’re putting together your proposal, but make it obvious to reviewers that you’ve thought about why your talk is a fit for this specific conference.

    Another example: if the conference is language-agnostic, you need to sell us on why your talk on a specific framework is relevant now. But if you’re pitching a talk on React to React Conf, you probably don’t need to tell us why we should be using React.

  5. A technical talk proposal doesn’t need to get so far into the nitty gritty at the proposal phase. The best ones I saw simply included the what (a language, framework or idea), the why (this language/framework/idea is more popular this year because of X), and a handful of takeaways, usually in bullet point form. Again, 300 words felt like the sweet spot.

  6. It’s really difficult (I think) to pitch an advanced language-specific talk to a generalist conference! But if you do, you need to explain why people should attend your talk. Forget the conference attendees – the people reviewing your pitch might not be experts in the thing you’re pitching, so to even get accepted, you might need to include enough background information to get your reviewers up to speed!

  7. I saw a handful of framings that kept popping up, some better than others.

  • Here’s how to get started with Thing. This can work, if you explain why attendees should want to get started with Thing.

  • 7 mistakes I made trying to do Thing. Numbers in a title, as journalists will tell you, are always good. It doesn’t have to be 7. The mistakes help though.

  • Some Thing you thought was bad is actually good, and here’s why. This framing is catnip for me. I always want to hear how I’ve been thinking about things wrong.

  • What’s new with Thing You Already Know About since you last learned it. I saw a handful of talks with this angle at Frontrunners this winter and I’m so into it. I always learn something.

  • I built A Thing and intentionally limited myself to doing it the hardest/most oldschool way possible, to prove it can be done/demonstrate the benefits of some technology. This can be interesting but there’s only room for a few talks like this at a conference (IMO).

  • If you know Thing 1, here’s how to apply that knowledge to Thing 2. This is really hard to do at a generalist conference, because it presumes knowledge of Thing 1, but could work well at a conference that specializes in one language or framework.

This was such a rewarding experience getting to “peek behind the curtain” at what goes on during proposal selection, and I’m so glad I did it. Also, stay tuned for more exciting conference news from me soon :)