I had my first opportunity to review session abstracts for a regional tech conference (CodeStock), and I learned some things I’d like to share. Hopefully my suggestions will help people improve the likelihood of having their sessions accepted.
Given the session abstract is the speaker’s pitch, I was surprised how many didn’t meet my expectations.
Some context:
- This list is not exhaustive, and the reasons aren’t in any particular order.
- I’m not including titles, names, or any quoted material from the sessions I reviewed.
- I was asked to consider sessions based on my team leader role.
Let’s start with some heuristics about why I disqualified sessions (as those are more deterministic) and tips to improve. Next, I’ll list some traits for sessions I prefer to see at conferences.
How to Get Rejected
Not proofreading
I’m a paid proofreader for an international fitness company, so my radar is well-tuned. Pay attention to grammar, spelling, capitalization, and punctuation. Some abstracts looked like the author hadn’t even reviewed it before hitting Submit. If you’re sloppy on the mechanics, what does that tell me about the quality of your presentation?
Tips:
- Copy/paste your abstract into https://ttsreader.com/ and hear what it sounds like read aloud.
- Ask the most detail-oriented person you know to proofread your abstract.
Using the clickbait technique
We’ve all seen the BuzzFeed approach to get clicks — using shock or surprise, including non-round numbers for lists. This manifested in things like “3 ways to improve your unit tests” or “X is dead; long live X”. Yes, your abstract should catch my attention, but people also have a strong sense of knowing if they’re being baited.
Tips:
- If you use numbers in your title, have your abstract list out those things. For example if your title is “3 tips for better communication”, make sure you have something like “empathy, active listening, and using cameras when remote.”
- Your job is to pique my interest, not give me gaps that can only be filled by attending your talk.
Too brief
There were several that were one or two sentences, and at least one that was just a clause. Yes, be succinct; however, if you don’t give enough context, I don’t know what to expect from your talk. An example was something like this: “We’ll cover the basics of making your app secure.” What kind of app? Secure from what? Maybe I already know the basics, so what’s your version of “basics?”
Tips:
- Tell me what I’ll get by listening to your talk. This is the thesis statement (https://owl.purdue.edu/owl/general_writing/the_writing_process/thesis_statement_tips.html) we were taught about in high school.
- How are you going to help me? Will you teach me something? Inspire me?
Too long
As I mentioned in the introduction, this is your pitch. They’re called “elevator pitches” because you only have as long as a brief elevator ride with the busy boss to convince them to give you the green light. Some submission forms already perform this function for you with character limits, but the lack of a character limit may lead you to believe that more is better.
From a practical standpoint, long abstracts take more time to review. If I have 600+ paragraphs to review, and I see your 3-page submission, I’m predisposed to make a judgment after the first two paragraphs. Some other reviewers will outright disqualify long submissions. I tried to at least read them to see if they contained worthy content.
Tips:
- Be aggressive with your editing; you likely need less text than you think. See if you can cut your first draft word count by 30%. Now cut that version by 30%.
- The abstract is your “hook.” Get me interested without walking me through everything in your talk.
Too dated
This comes down to knowing your audience for a particular conference. Yes, there will be beginners in the audience who haven’t seen Azure DevOps, but I’m not attending the talk “What’s New in X” when X came out two years ago.
Tips:
- Look at the previous year’s session list for what talks were given to see where they fell on the adoption curve (https://en.wikipedia.org/wiki/Technology_adoption_life_cycle).
- If you’re targeting beginners with tech that’s mature, use verbiage to attract them. For example, “A Tour of X for Newcomers”.
The sales pitch
CodeStock is a generalist conference, meaning not everyone uses Microsoft products. The big tech vendors typically have their own trade shows to highlight their new products. My method for evaluating was comparing the abstract with the speaker bio. Changing the names here, but this is how it manifests: “New JIRA Workflows for DevOps” presented by a tech lead from Atlassian (who produces JIRA).
Tips:
- If you work for major vendor, work with someone in the community that uses your tools and ask if they’d like to give a talk about your product.
- Ask if the conference will let you sponsor a booth so you can showcase your products to attendees.
Submit all the sessions!
As a speaker, I realize there’s value and practicality in repeating presentations from other conferences. My reviews called out two patterns. The first appeared to be that the speaker submitted every talk they’d ever given. The second was essentially the same general talk, but targeted toward slightly different audiences (e.g., developers, managers, data scientists, testers). The shotgun approach didn’t impress me. I know from a speaker’s perspective, a higher number of talks submitted may lead to a higher number of talks accepted. From a practical perspective, this means more sessions that need reviewing, leading to longer review times.
Tips:
- Focus on what trends this conference’s attendees are likely to be interested in.
- Reach out to the organizers or other speakers for feedback on which of your talks would be better received.
Material I could find myself
With the advent of online learning programs like Pluralsight or Udemy, and the higher bar for documentation for frameworks and tools, we can learn things on our own schedule. Why would I spend an hour on a Saturday listening to you give me content I could get at a more convenient time at my own pace?
Tips:
- Find a way to leverage your knowledge to give me something I can’t get online.
- See the “How to Get Accepted” section below.
It’s not clear what I’ll learn
Your abstract needs a thesis: the one reason I will benefit by going to your talk. This issue manifested by having too many topics in one talk, where I was unclear how they were related. Another instance used concepts too broadly. For example “security” means different things to developers, IT/engineering, corporate policy; what will we focus on for your talk?
Tips:
- Have a solid, unambiguous thesis. Every slide in your talk should be helping the audience tie back to that thesis.
- Ask a colleague to read your abstract and tell you what they think your thesis is. If they fumble or don’t know, you need to refine the text.
Too much jargon
You can expect a certain level of technical knowledge from attendees; however, terminology shifts quickly in this industry. Remember that your job when submitting abstracts isn’t to sound smart; it’s to convince me that you’ll help your talk attendees in some way.
Remember that some people may be using certain practices, tools, or workflows but don’t know what others call it. For example: “Moving from Monolith to CQRS”. Maybe I’m a new dev and don’t know what a monolith is. Is that an Arthur C. Clarke joke I don’t get? What’s a CQRS and do I have to pay to use it?
Tips:
- Briefly define terms in parentheses to put your readers at ease.
- Look at other conferences and see how widely your terms are being used.
How to Get Accepted
For me conferences are about networking and getting content I can’t get anywhere else. Not every company covers ticket prices and time off for people to attend, so the value of the conference talks should be high. That said, here are talks I like to see.
- This vs. that. The compare-and-contrast approach helps me make decisions that would take me more time than I have to evaluate on my own.
- Here’s my story. Humans share knowledge through stories, and no two people experience things the same way.
- Analogies. For example, how teaching group fitness helped me lead more engaging meetings.
- Something unexpected. For example, everyone said X was easy, but for me it wasn’t and here’s why.
- Where we are going. Things move too fast in this industry to keep up with every area. Give me the executive summary of what’s dying, what’s being reborn, and what I should pay attention to on the horizon.
- Devil’s advocate. I think my approaches and paradigms are still best practice; is that really true?
Wrapping Up
Being a reviewer was an enlightening experience to see things from another perspective. It helped me learn what passionate people are interested in and looking to share with the wider community. And it’s helped me as a speaker and peer-reviewer of other speakers to improve the likelihood of sessions being accepted.