7 Reasons Why Abstracts Fail

I just wrapped up my second go-round as a member of a PASS Summit Abstract Review Team, and I want to share some of the missteps that torpedo an abstract’s chances of being selected.

Last year, I reviewed the Application Development submissions; this year, I was the lead for the Professional Development Team. Between my work on these teams and reviewing abstracts for SQL Saturday here in Denver, I’ve read and re-read about three hundred abstracts. While I’m no Adam Machanic (who’s read thousands of them), I’ve read enough abstracts to recognize where many of the rejected ones stumble.

Although the call for regular sessions has closed for this year’s PASS Summit, there’s still the call for Lightning Talks (ten-minute sessions) yet to come, and there are always SQL Saturdays to submit to. I’m hoping that by reading this, you get a better sense of what may be holding your abstract back and have a better shot at getting chosen for future events.

(Also, if you submitted a professional development abstract for the 2013 PASS Summit and it’s rejected, you’ll get our team’s comments in addition to the standard reason for rejection. We hope it’ll be useful feedback for you.)

Here’s what I’ve seen in abstracts that don’t make the cut, and how severe the damage can be to its chances:

1. Spelling/grammar errors

100% preventable.

Potential damage to abstract: Catastrophic.

Avoid these errors and a successful writer, you will become.

2. Rambling

Some abstracts, given the chance, will go on at length without really saying anything of substance and to a reader it is at first a mild irritant, later progressing to restless tedium followed by disdain and slight regard, until finally the reader can take no more and…we’ll discuss XQuery bas

[Truncated by character limit, which went unnoticed because author copy-pasted from elsewhere and didn’t check it after pasting.]

Potential damage to abstract: Catastrophic.

3. No examples of what I will learn.

How do I know if I already know the things you’re presenting?
By giving very specific examples of what will be presented, you’ll accomplish these three things:

  • You’ll weed out potential attendees that would say your material was too basic (and therefore rate your session lower).
  • You’ll help differentiate your abstract from others covering the same topic.
  • You’ll attract people who are looking to answer that very question, and will likely rate your session well because of it.

Saying you’ll cover “how to manage transaction log sizes without truncating” beats “transaction log management” every time.

Potential damage to abstract: Heavy.

4. Hash tags

They seem out of place when I see them in abstracts. I’ve been to numerous sessions where the presenter asks how many attendees are on Twitter. I’ve never seen more than half the audience raise their hands. What does a hash tag mean to people who aren’t on Twitter? Do they see hash tags and think they’re temp table names?

Potential damage to abstract: Light. May screen out some non-users of Twitter unnecessarily. More so if the hash tag is obscure or ultra-specific.

5. You don’t understand my pain

Cheesy as they are, infomercials work for a reason. They nearly always start by asking a quesiton acknowledging a painful situation you have: “Do you suffer the embarrassment of explosive and uncontrollable belching?” Immediately you share a bond with the narrator; you’ve both suffered this problem and you understand each other’s pain. You ┬ánod and say, “Oh yeah, I know exactly what that feels like. I burped my wedding vows full blast.”

Evoke that same connection with your readers. Tell them you’ve been there, suffering as they are now, and you can help them. Skipping this step puts you at a disadvantage.

Potential damage to abstract: Moderate, by omission.

6. Details that aren’t really details

Unless elaborated on, these words don’t create a picture of what the session will be like:

  • Interactive
  • Hands-on
  • Fun

Interactive could mean saving the last ten minutes for Q&A, having an audience volunteer run a demo for you, or polling throughout the session. I need to know what that means.

I don’t get excited about the word “fun” in an abstract because my experience has been that the speaker is who’s fun, not the abstract. Certain speakers like Buck Woody and Matt Masson bring the fun no matter what the topic. Speakers like them earn a reputation for being fun; they don’t turn it on and off for certain topics.

Potential damage to abstract: Light to moderate. This is most damaging in abstracts where details are absent and there’s heavy emphasis on the fun/interactive part.

7. Takeaways that aren’t takeaways

Unless elaborated on, these words don’t tell attendees they will learn:

  • Lessons
  • Skills
  • What to do/what not to do

Imagine for a moment that you’re at a power tool conference and the sessions are a la carte — that is, attendees are paying for each individual session they attend. You have to choose between two sessions:

Session A states: “You’ll learn the skills you need to operate a nail gun successfully.”
Session B states: “You’ll learn how to operate a nail gun using best safety practices, how to remove a cartridge jam, and how to tell when you need a separate pressure regulator.”

Is there any debate which abstract will get your business?

Potential damage to abstract: Devastating. It’s highly unlikely an abstract with vague takeaways will get selected.

These are only my opinions. I don’t speak for any of my associates on any review team I’ve been a part of. Other reviewers have their own ideas about what works in an abstract, so don’t take what I say as a blueprint that guarantees success with any review process. However, by avoiding pitfalls like the ones I’ve outlined, I’m certain you’ll become a more successful abstract writer.