Doug Lane

SQL Server Entertainer

  • GitHub
  • LinkedIn
  • Twitter
  • YouTube
  • Blog
  • About Doug

7 Reasons Why Abstracts Fail

May 15, 2013 by Doug Lane

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.

Yoda
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.

Filed Under: PASS Summit, Presenting

T-SQL Tuesday #41: My Love of Presenting is Nothing New

April 9, 2013 by Doug Lane

TSQL2sDay150x150Bob Pusateri is hosting this month’s T-SQL Tuesday, and he’s decreed the topic be how we came to love presenting. I say presenting is really the same thing as performing, and my love of performing stretches back to my elementary school days.

I did a lot of performances when I was young. Nothing commercial, mind you. Skits at the Cub Scout Pack meeting (Den 4!). Chester the cat in a play-reading of Bunnicula. Playing alto sax in band. In junior high (it’s called middle school now, I guess), our concert band went on tour through elementary schools in Anchorage. In high school, our 90-piece symphonic and stage (jazz) bands toured small towns in Alaska and Canada. I got to mangle perfectly good music do improv solos and I loved every second of it. That’s the closest parallel I have to the feeling I get when I present. Which makes sense when we consider what the two have in common.

Like presenting, improv relies on a framework (key, tempo, measures) and the rest is filled in on the fly. The more you practice, the better you can express your ideas. Your comfort level with the fundamentals (scales, whole tones) allows you to be more free-flowing with your ideas while sounding like you’re playing coherent, complete thoughts. You learn tricks that you can re-use in other solos – my favorite was C-E♭-C-E-C-F-C-F#-C-G, surprisingly easy to play fast on a sax – in the same way you can re-use information, techniques, or jokes across different presentations.

With all this in mind, it’s no surprise I enjoy presenting, as it picks up where I left off nearly twenty years ago when I last played in a band. What got me started presenting was the realization that I had learned enough to stand in front of people and share my experience with a modicum of confidence. This blog post by Brent Ozar had a lot to do with it too.

I got – and still get – nervous when I present. It doesn’t bother me much, though. It’s like an old friend, a companion I’ve known for a good thirty years. I wouldn’t want to be without it.

Filed Under: Presenting, T-SQL Tuesday

If You’re Not Sure About Submitting an Abstract

April 1, 2013 by Doug Lane

The 2013 PASS Summit Call for Speakers ends in less than 48 hours. If you’re on the fence about whether or not to submit an abstract for the Summit (or any other event, for that matter), here’s what I say:

DO IT! DO IT! DO IT!

Get started here. Time’s running out!

UPDATE: If you’re having trouble getting your ideas in writing, try using one of these submitted abstracts as a template. I have no idea if they’ll get chosen but they’re very well written.

Kendra Little: How to Tell When Storage is a Problem

Brent Ozar: Why is SQL Server Slow RIGHT NOW?

and here’s one of mine: The Missing Manual for Data-Driven Subscriptions

Good luck!

Filed Under: PASS Summit, Presenting

A Conversation About Abstracts Between Committee Me and Rejected Me

June 7, 2012 by Doug Lane

Last year, I submitted abstracts to the PASS Summit for the first time. I sent in four abstracts and all four were rejected outright. I took the rejection pretty hard, especially considering all four were rejected for no other stated reason than “max sessions allocated for track” — in other words, simply not good enough. This year, I served on the abstract review committee for the AppDev track. I not only wanted to serve the SQL Server community in this way, but I also sought a better understanding of how abstracts are selected, and what makes an abstract a winner. To ease the sting to those who are going to be rejected for this year’s Summit (or were rejected in years past), I thought I’d share with you a conversation between last year’s me (the rejected applicant) and this year’s me (the committee member).

Rejected Me: I suppose you know why I’m here.

Committee Me: First, let me tell you, very sincerely, I’m sorry you didn’t have any abstracts selected this year.

"Well, we still have the call for Lightning Talks."

Rejected Me: Thanks, but I’m still pissed about it.

Committee Me: I understand. I’ve been there. I wasn’t on your track’s committee, so can you tell me your reasons for rejection? Maybe I can help you understand.

Rejected Me: I don’t know, all they said were “Max sessions allocated”.

Committee Me: That just means you wrote adequate abstracts, didn’t leave anything incomplete, that sort of thing.

Rejected Me: Duh. I was thorough. I spellchecked and filled in all the required info.

Committee Me: It also means, for whatever reason, all the accepts and alternates were better than yours in the eyes of the committee.

Rejected Me: Can’t they tell me more than that?

Committee Me: I know it stinks not getting better feedback, but keep this in mind: three volunteers took time to evaluate as many as over 200 abstracts. Most of them are complete and halfway well-written. They don’t have time to give full critiques to each one.

Rejected Me: But that doesn’t help me. How will I know what I need to do better next time?

Committee Me: I don’t want to sound harsh, but it’s not their job to counsel you on why they didn’t like your abstracts more. Read the abstracts that were accepted and you’ll see commonalities. Learn from those.

Rejected Me: Fine. But why does [this person] always get to speak? Why not let some new people get a chance?

Committee Me: It just so happens that experienced speakers tend to be experienced abstract writers. Like I said, learn from the successful ones.

Rejected Me: I submitted three of my four abstracts in the same subject area. Surely they could have picked one of them.

Committee Me: Not necessarily. It could be they thought the target audience would be too small, or they already had it covered by another abstract — one that was better written.

Rejected Me: Is it me? Maybe my abstracts weren’t the problem.

Committee Me: Could be. Your experience does factor in, but we do want some newer speakers in there too. How many events have you presented at before you submitted to the Summit?

Rejected Me: Two.

Committee Me: Hmmm, that’s not many. Did you do well at those events?

Rejected Me: My feedback was good, so I don’t think I’ve got a bad reputation.

Committee Me: Certainly no reputation is better than a bad one, but neither case is very helpful. Keep speaking when you can find the opportunity. You’ll be much more established by this time next year, and that can only help.

Rejected Me: I suppose.

Committee Me: Try to remember this is the world’s largest SQL Server conference and the people that speak here have earned their way up on stage by building a history of successful presentations and writing good abstracts. Hang in there. Work to improve your content, delivery, and abstract writing, and you’ll get the call eventually.

Rejected Me: Thanks. But why didn’t they like my abstracts this time?

Committee Me: Well, if it’s any consolation, it could be someone on the committee really liked one, but it wasn’t enough to float it up high enough to make the cut. So it may not have been unanimously rejected. Apart from that, I don’t know what else to say except I’ve been in your shoes. I know exactly what you’re feeling.

Rejected Me: I don’t even know how close I came. Can’t they publish the final rankings or comments?

Committee Me: That’s an interesting idea, but one with a lot of complications. First, this is done by committee, so it could be one member writes glowing comments but the other two rate it low enough that it doesn’t make the cut. You end up with great comments and a lower ranking. To me, contradictory feedback is worse than no feedback. Another problem is that we simply don’t have time to comment specifically on each abstract. It’s hard enough to try to rate them all fairly. I even went so far as to make sure I wasn’t hungry, tired, or mad about something before reviewing a chunk of abstracts because I wanted to be in an equal frame of mind across them all. (Proof there’s a rational basis for doing so.) Also, if we posted complete rankings, we’d get a lot more questions from people wanting to know why they were ranked so low. It’s the committee’s job to rank abstracts, not to publicly defend the rankings. Sorry.

Rejected Me: This still sucks.

Committee Me: Yes. Yes, it does. I hope I’ve helped a little.

Rejected Me: A little.

I hope I’ve helped a little. Hang in there.

Filed Under: PASS Summit, Presenting

When Your MacBook Won’t Detect a Projector

June 1, 2012 by Doug Lane

Experiencing a major technological disaster is a rite of passage among presenters. At SQL Saturday in Madison, I had my first presentation laptop failure. Surprisingly, it happened with my MacBook Air. (I’ve had two MacBooks with zero problems, versus three HPs with a combined twelve hardware failures.)
 
With ten minutes to go before my presentation, I could not get the laptop to recognize the projector. I checked and re-checked the cable, the DisplayPort<->VGA adapter, restarted both projector and laptop. A few other speakers tried to help, as did the room monitor. Five minutes into my session time, I plugged in a copy I had on a USB drive to the room’s PC and began my presentation. Not long after, the IT person in charge that day took my laptop to another room to see if he could get signal there. He couldn’t. I continued on, blowing past the three VM-based demos I had lined up. Fortunately, the presentation went well enough without the demos.

"If it were an HDMI connection, I would have found it hours ago."
Last week, I finally took the laptop down to the Apple Store and got some answers. What happened? In short, the chunk of memory that stores information about display connections became corrupt. With about sixty seconds of work, the guy at the Genius Bar got it to recognize both Apple and generic VGA monitors. Here’s what he did to clear the memory.
 
First, he reset what he called the Power Management Unit (PMU) using these steps:
  1. Shut down the computer.
  2. Connect it to AC power.
  3. Press the left shift + command + option + power button.
Second, he reset the Parameter RAM (PRAM) on the computer using these steps:
  1. Shut down the computer.
  2. Press the power button to turn on the computer.
  3. Immediately, before the gray screen appears, press and hold command + option + P + R. Hold the keys down until the machine restarts and you hear the second startup sound.
If your MacBook ever refuses to recognize a projector or VGA connection and you’ve tried everything you can think of, try resetting the PRAM. It may save you from having to dismember your presentation at the last minute.
 
You can find a little more about PRAM here:

http://docs.info.apple.com/article.html?path=Mac/10.6/en/26871.html

http://support.apple.com/kb/PH4405

Filed Under: Presenting Tagged With: DisplayPort, MacBook, PRAM, projector, troubleshooting

  • 1
  • 2
  • Next Page »

Subscribe now!

Don't miss new posts as they publish. Enter your e-mail address to subscribe!

Your e-mail address will stay quietly between us, like that time I set the carpet on fire by accident.

Copyright © 2025 · Outreach Pro on Genesis Framework · WordPress · Log in