Capturing Attention: Writing Great Session Descriptions

Adam Machanic — Fri, 22 Feb 2013 14:00:00 GMT

One of the best ways we can differentiate ourselves and further our careers is to get out of the office… and onto a stage. Presenting can give you name recognition; open doors to new opportunities; help you gain a deeper understanding of technology (teaching a topic often forces you to learn it at a much deeper level); and for many people it's simply a fun and satisfying pastime. Each year there are dozens of speaking opportunities available to you: brown bag talks at your workplace, local user groups, online (virtual) user groups, community events, and conferences, just to name a few.

Virtually every speaking engagement, no matter how large or small, has something in common: attendees want to know, in advance, what is you're going to be talking about. They want to know whether they should spend their valuable time watching you, watching some other presenter, or perhaps staying at home and catching up on some sleep. And attendees will make this decision based upon an all-important document, the session description.

I've been speaking publicly and running events for just shy of 10 years now, and in that time I've read thousands of session descriptions. Some were decent, some good or even excellent, and most were very, very bad. I've also seen a lot of potential speakers--many of whom had extremely interesting topics and content--get rejected by events because they made basic mistakes in their session descriptions.

Writing a great session description is hard work. There's no way around it. But it's work that you need to do if you want to become an accomplished public speaker, especially at competitive events like large conferences. I like to think that I've done pretty well in this area, so in the interest of reading much better descriptions at upcoming shows, I'd like to share what I've learned over time: what matters, and what doesn't, when it comes to describing your sessions.

Overview

To begin with, what is a session description? I struggled with this one a bit; I wanted to talk about abstracts, titles, and levels all in one go. I decided to group them together under the umbrella name "session description." For the rest of this post, when I refer to that term I'm talking about all three parts. When I want to talk about only one of the components, I'll refer to it separately. Let's do that now.

An abstract is a paragraph that is supposed to describe what you're going to talk about in your session.

A title is a small number of words that are supposed to describe what you're going to talk about in your session.

A level is a number that's supposed to help guide who should (and should not) attend your session.

Another definition is also in order, and that's for the word great, which I've used in the title of this post. Greatness is, naturally, highly subjective. So for the purposes of this post I'll define a great session description as one that, for the correct people, captures their attention, whets their appetite, and makes them actually want to see you talk. That's kind of the point of the whole thing, right?

Your Audience and The Real Goal

Before you begin working on your session description, it is important to realize what it's going to be used for. Your session description is for attendees. It's for the event organizers. And it's also for you. It has three purposes in life! These are not necessarily conflicting purposes, but you should weigh each of them carefully before writing.

Attendees will use your session description to decide whether they want to attend your session.

The organizers will use your session description to decide whether to give you a speaking slot.

And you can use your session description to set expectations and keep yourself constrained.

Your session description is, first and foremost, a piece of marketing collateral. You are selling a product: your session. You must first sell it to the organizers. Then you must sell it to attendees. Then you must deliver what you sold. If your text underwhelms you will fail to get the chance to deliver or fail to attract an audience. And if you oversell you will end up creating promises that you can't keep or risk attracting an audience that may not appreciate your work.

Sales is all about understanding the needs of the people you're selling to, and solving their problem. To sell to the organizers, try to understand the mission of the event and fill appropriate gaps. To sell to attendees, try to understand the audience you're targeting, and write a session description that will help them. These two things are not at all independent of one another. Submit sessions to events that appeal to the attendees you hope to speak to; there is no real benefit in attempting to get yourself booked for inappropriate venues.

You Are Not Your Audience

Remember this always: most normal people attend technology events on the premise that doing so will make their lives easier by helping them learn to do their jobs better. Most people who work for a living do not care about technology for the sake of technology. They want to solve problems at work so that they can collect a nice paycheck and enjoy life outside of work. Most people are not at the event because they're ubergeeks. Most speakers are ubergeeks and forget this. If you're reading this you are probably not normal.

What does this mean for your session? As a presenter, you're much more likely to have a successful run of things if you target the majority of the potential audience, rather than a small niche group. This means helping all of the "normal" people. Don't get me wrong; these may be very technical people who are advanced technology users. But you won't attract them with pure geekery. They don't want to check out your cool technology, no matter how cool it is, just because it's cool. You need to appeal to their sense of purpose.

Tell a Story

How do you appeal to your target audience? Easy:

Figure out who they are
Figure out what problems they need to solve
Help them understand that you know who they are
Help them understand that you appreciate their problems
Help them understand that you can help them solve their problems

In other words, relate to your audience, and let your audience know that you relate to them. People like hearing from other people who share similar backgrounds and experiences. And people like hearing stories. Humans have been listening to stories for tens of thousands of years. It's how we're wired. Weave a compelling story and people will want to come and listen to it.

A great session description is a small story. It's a prelude to the larger story that you'll tell later in your presentation. It's the dust jacket on a great book, or the trailer for a new movie. Each of the three component parts should work together to draw the audience in, get them interested enough to want to keep going, and leave them wondering how the main character is going to escape the fire breathing dragon. A truly great session description will leave each member of your target audience with the understanding that he is the main character, and the fire breathing dragon is the problem he faces at work each week. Accomplish that and audiences won't be able to stay away from your presentation.

A common question asked by new speakers is "what should I speak about?" (Alternately phrased, "what should I write a session description about?") The answer, truth be told, is that it really doesn't matter. Or at least it shouldn't matter. Choose topics that you know well, are passionate about, solve a problem for you, and, most of all, about which you can tell your story. Chances are excellent that other people out there feel the same way (or your great session description will compel them to feel the same way), and you'll have no trouble finding an audience.

Your Session Description and the Relative Importance of its Component Parts

Earlier I introduced the three component parts: The title, the abstract, and the level.

In theory each of the component parts would be digested together by your audience (attendees, organizers, and/or you) and considered as a single piece of work. In reality that's not what happens. Each of the component parts has its own relative merit, depending on what stage of the game your session description is at.

Here's how things usually work:

You, if you're like most speakers I know, will spend some time writing the abstract, then throw in the title, and will hastily tack on the level as an afterthought.

The organizers will judge you on the title and level (based on what they need for the event) and if sufficiently interested will take some time to read the abstract. Let's assume that 80% of the abstracts get read at this stage.

The attendees? Depending on the event, many of them will never see your abstract at all, and may not see the level. If you're the only presenter at a user group one evening, most of the attendees will probably at least have the chance to read your abstract. But, you know, TL;DR. People can't be bothered to read a big paragraph full of, like, words.

The bigger the event, the worse it gets. The majority of attendees decide where to go based on the little printout or booklet they receive when they show up. These usually contain a schedule in a grid format, with only room enough for session titles. Usually levels don't make it to that schedule, and some events don't even include the speakers' names. That means that the entire decision is based on those few words in your title. I would estimate, based on interactions I've had, that only 25% of attendees ever bother reading abstracts.

The title is the only thing read by everyone, guaranteed. It is, therefore, the most important piece of your session description. The abstract is the next most important, and the level the least important. That said, you should determine the level first. Why? Because the level drives the language used throughout the rest of the description.

Levels of Confusion

Session levels are, on the best of days: stressful, vexing, misinterpreted, mostly worthless, improperly used, and entirely subjective. Most attendees don't understand what they mean, most speakers don't understand what they mean, and most event organizers don't leverage them very well. The central problem is that a topic that's really difficult for me ("level 500") may be dead simple for you ("level 100"). So what's the point?

Session levels don't have to be completely useless. They can help you figure out who your audience is supposed to be, and help you properly target these people by using appropriate language.

Most events--at least in the Microsoft space--use five levels. 100 is supposed to be for the most basic stuff, and 500 for the most advanced stuff (some events, like Microsoft's TechEd show, max out at level 400). Personally, I compress things down and try to focus on three basic levels:

Level 1: Material for people who don't know much about what I'm talking about (a.k.a. level 200 or so)

Level 2: Material for people who've used what I'm talking about but aren't experts (a.k.a. level 300 or so)

Level 3: Material for people who want in-depth details on what I'm talking about (a.k.a. level 500 or so)

Each level determines not only the content I'm going to present, but also drives the terminology I'll use in how I describe things.

Consider a talk on SQL Server AlwaysOn. Both the session description and the presentation itself should be aligned for the audience target.

At Level 1, the talk would describe the basics, starting with what the terms "high availability" and "disaster recovery" actually mean. Perhaps a brief high-level review of various technologies that solve these problems, and a look at how AlwaysOn tackles some of the key areas. The problem this talk would helping the audience solve is how to make sure that databases and their data are available whenever users need them. The story is a tale about technological advances and how easy it can be to keep the data flowing, even in the face of disaster.

At Level 2, deeper and more in-depth language would be used. How do "availability groups" work, and what general architectural choices should be made? What are the pros and cons of "synchronous" vs. "asynchronous" commit modes? The problem in this case is understanding the complexity of actually using AlwaysOn. The story is about connecting features and options to real-world use cases.

At Level 3, focused and specialized language is applied. Both the session description and the talk could reference "listeners," "quorums," "replicas," and so on, without any need for explanation. At this level we're usually targeting fellow ubergeeks, so there may be no real problem we're helping to solve. But--as always--it's very important to tell a story to help engage your audience.

In each of these cases, the appropriate language should be used in both the title and the abstract as needed. This enables each component part to communicate something about the level to the reader--without the reader ever having to actually read some arbitrary number.

Designing Your Title

So you've decided that you want to do a talk on the brand new, supercool, game changing feature that's going to be released next month. We'll pretend that it's called "Hekaton." (Sorry, but it's not really going to be released next month.)

To recap, the goal of your title is to:

Reflect upon the appropriate audience level
Draw in the correct audience
Create enough excitement to make them want more

The average session title submitted for SQL Saturday events (based on a quick perusal of the archive) is around 5 to 7 words long, and that's probably not enough. One of the biggest mistakes I see new speakers making is thinking that a short and succinct title is great. So they submit sessions with titles like:

"Hekaton in SQL Server v.Next"
"Hekaton for OLTP"
"Using Hekaton for Faster Transactions"

The problems abound...

These titles all use a code word, Hekaton, which only certain—and very specific--attendees will actually know. And they're probably not your target audience, because most normal people don't know the term. (Again, "normal" refers to non-ubergeeks, i.e. people who have a life, i.e. the people you probably want to reach.) At the average conference, attendees can sit through maybe five or six talks each day. So committing to a mystery topic? Think about it this way: If you're looking down at your schedule grid and you see one of these sessions, with a term you don't know, and it's up against a session that appears to solve a problem you do have, which option are you going to take?
These titles feel vague and too general. If someone already knows what Hekaton means, chances are good that he won't bother attending these sessions, because he won't be likely to learn anything new. Furthermore, these session titles don't appear to help anyone solve a problem, with the possible exception of the last one. And that one sounds a bit like it's going to be a sales pitch.
These titles are boring. Seriously. I fell asleep while writing them. If your title bores me, chances are good that your talk is going to bore me. And I don't like being bored. No one does.

So what do we do here?

First of all, since this is a brand-new feature that still uses a code word, this talk can't possibly be advanced. Even if you've been in a special early adopter program and have in-depth knowledge, there probably won't be an audience for you. So this is going to be a beginner-level talk, and the code word has got to go. Hekaton is an in-memory database solution designed to help speed up transactions. Can you pull a something from that description to explain the feature in just a few words?

Second, you need to clearly identify the problem you're going to help attendees solve. Which attendees have problems with transactional latency? Probably those with lots and lots of concurrent database users. And it's probably a good idea to help the audience identify itself as it reads your title.

Third, you need to get these attendees interested enough to either read your abstract or--for the 75% who won't read it--actually show up at your session just on the merits of the title. This means adding a bit of verve: showing some emotion, exposing your excitement, displaying your personality. Something a bit non-technical to indicate that this session isn't going to be nap time.

Putting it all together, we can come up with some pretty decent titles that do a much better job:

"In-Memory Solutions for Massively Concurrent Database Dilemmas"
"100,000 Users and Going Strong: In-Memory Transaction Processing Done Right"
"From Cessna to F1: Moving Your Heavy OLTP Workload to Memory and Beyond"

The code word has been eliminated. The audience can identify itself (those with "massively concurrent" databases, those with lots of users, or those with heavy OLTP workloads; all the same audience, just different ways of addressing them). The titles project a problem and hint at a solution. And each of these titles reads like a human actually put some thought and effort into them. (Well I think so. Nothing like painting a target on my back!)

The key to all of this? Relate to your prospective attendee. Don't bore them. Help them. And don't be afraid to use a few words to get there.

As an aside, there's this thing called title case. It's a set of rules for how to capitalize your title, and you should learn it. Failing to properly case your title makes you look like a total amateur.

Writing Your Abstract

At this point you've identified your attendee target, established a level, and drawn up one or two potential titles. (Write a few of them if possible; don't constrain yourself!) Now it's time to write the biggest portion of the session description: the paragraph-long abstract.

First things first. All of the rules already described apply here. Tell a story. Use appropriate language for your audience target. Don't be dull.

A well written abstract should expand upon, and complete, the narrative that the title started. It's the same message, but you have a lot more room in which to deliver it. When I read an abstract I look for organization, flow, and depth. All things that can help me decide whether the session is worth my time. If your abstract is disorganized, doesn't convey a starting and end point, or isn't at the right level, it's going to translate into the audience thinking the same about your talk.

The biggest sin when creating an abstract? Failure to even try. I've read countless single-sentence abstracts, especially those submitted to small community events. If you can't spend more than 30 seconds writing your abstract, how can I trust you with 75 minutes of my time?

Don't do this:

Attend this talk to learn how to use Integration Services in SQL Server 2012 to help with common ETL tasks.

Did I mock this up? Kind of. I just grabbed a real SQL Saturday abstract (on a different topic) and changed the words around. So yeah, this is essentially real, and every time I see it I cry a little bit, because no one should have so little enthusiasm about his topic and an expectation that he's going to make any audience care. This abstract probably won't fly at SQL Saturday, and it definitely won't fly at a conference. Just don't do it.

So what should you do?

Reflect upon the title. Re-state the problem, but in more words. If possible, refer to the audience. Draw them in.
Describe how what you're going to talk about is going to help address the problem. Give them a hook.
Conclude, re-stating the problem and re-affirming the hypothetical solution. Seal the deal.

A good abstract should, in my opinion, be at least five or six sentences long. Not too long, mind you--you're not trying to write a book--but long enough to thoroughly set expectations.

Start by reaffirming that the reader is the correct reader. For a beginner-level SSIS talk similar to the one indicated above, I might begin by describing a familiar scenario:

You have loads of data sitting in flat files, Access databases, and Excel spreadsheets. How are you going to get it all into one centralized database?

Now, hopefully, some readers are nodding their heads. They're saying, "you're right, I do have loads of data sitting around in various forms. And I really am having a lot of trouble getting it into the database." Now I've drawn in my target audience. I've reminded them of their problem. And I haven't used any jargon; remember, it's a beginner-level talk.

Also notice that I am directly addressing the reader ("you"). This is done very much on purpose: I want to reinforce that my talk is for my target audience, and that I'm thinking about and talking to my target audience. I'm not writing this abstract for some random group of people I don't know and don't understand. And it's certainly not for me (or the "royal we"). I'm writing this abstract for a very specific group of people I want to help.

Next we get into the hook, the section designed to make readers interested in your solution for their problem. The solution, in this case? Integration Services, which, in theory, is a great way to tackle the problem. But why is it great? Tell the reader.

SQL Server Integration Services (SSIS), first introduced in SQL Server 2005, is a comprehensive tool designed to help ease all of your data loading headaches. In this session you will learn the basics around how SSIS is designed and how to manipulate both the logic and flow of data in your load processes. You will see how simple, yet effective, the SSIS user interface can be, and the ease with which even complex problems can be tackled.

Now I've answered several questions for the reader:

"How am I going to solve my problems?" By using Integration Services.
"Well I'm running SQL Server 2008, not 2012. Can I still use it?" Sure you can. It was added to the product way back in 2005.
"What are you going to show me?" How to use the Control Flow and Data Flow. Oh wait, I didn't say that in the abstract. That's because it's an abstract for an audience that hasn't used SSIS, and those are jargon terms. Instead I mentioned that you can control logic and flow of data. I didn't even use the term ETL, because I want to target the absolute beginner. Anyone with a basic understanding of databases will understand what I'm getting at. Anyone who is knowledgeable in SSIS is going to read this abstract and immediately know that this talk isn't for them. And that's the goal.
"Is it difficult to use?" No, it's "simple, yet effective." I said so right in the abstract!

In addition to answering these questions, I've kept most of the tone active. Active voice is one of the keys to a great abstract. It tells the reader that there is value to be had here, that this will actually impact his job and his bottom line, and that he shouldn't expect to attend and sit there, mouth agape, drooling and waiting for the bell to ring.

I could leave the abstract as-is at this point and call it a day. But I like to end on a really positive, upbeat note. I want my reader to walk away excited by the prospect of attending my session. So I seal the deal with a conclusion that restates and ties everything back together.

There is no reason to allow a data mess to ruin your day; after attending this session you'll have the necessary SSIS knowledge to easily extract data from virtually any source, transform it into whatever shape you need, and quickly load it into the database of your choice.

If I've done everything right, the target audience member has finished reading and is saying "wow... that's exactly what I want to do."

What Not To Do in an Abstract

Over time I've noticed a few things that don't quite work:

Bullet points. Bullets are a great way to organize information into small digestible chunks. I've used plenty of them in this post. I'm even using one now to talk about why you shouldn't use bullet points. Oh, the irony. Anyway, the fact is that once you submit your session description for an event, you usually have no control over its formatting. And events botch the formatting all the time. Usually abstracts are compressed down to a single paragraph, so I recommend that you write your abstract as a single paragraph. Bullet points will tend to get rendered into something like this:

This is my abstract about some cool new technology! I'll be covering such issues as - Using the technology - Installing the technology - Making friends with the technology - Harassing enemies with the technology - Formatting and line breaks using the technology This technology will change your life so attend today!

Using your own name in your abstract. Some people like to say things in their abstracts like "In this session Steve will show you why it's great to be a farmer." This works, in very limited cases, but most readers are going to say "Steve? Steve who?" They're going to think you're a deranged egomaniac, and they're not going to want to attend your session. If you've read this far you know that I like to think about the normal people; the ones who aren't plugged in to the community 24x7, because they have something better to do with their time. They probably don't know who you are, even if you include your last name. Sorry.

Insulting the reader. Never, ever, ever assume that you're the smartest person in the room, unless you're alone in the room. And be very careful with assumptions about your target audience. Sometimes I'll see abstracts that say something inflammatory, like "if you're a .NET developer creating a data model, you've no doubt screwed up several key aspects." While this may be true in your mind, and might even be true in reality, what you're doing is alienating the reader. A better way to phrase this would be something like "due to various differences between the platforms, .NET developers attempting to create a SQL Server data model may encounter a number of tricky situations." Now the reader can think back, realize that he has hit one or more of these, and become interested in your content. And that's a win.

The Aftermath

If you've written your session description with only 15 minutes left before the event closes its submission period, you're pretty much in the same boat as everyone else. Oh, and you're doing it totally wrong.

The very first thing you should do after you complete your work? Read it yourself. And then read it again. Read it slowly and carefully, word by word. You will find a typo. You will find a grammatical error, or a phrasing problem. If you don't, you're not looking hard enough. And run it through a spell checker. There is nothing that says "careless" more than a glaring error -- and, again, a glaring error in the session description is indicative of lots of glaring errors in the actual talk.

The next thing you should do is to pass the session description around to some people you trust. Preferably one or two people who are in your target audience, to tell you whether you've created something of interest. Preferably one non-technical person, to screen it for jargon and do a second copy edit. If the non-technical person is just a bit lost, that's okay. If the non-technical person is totally lost, chances are most technical people will be, too. Clean it up.

If you're writing in English and you're not a native writer, find a native writer and have him proof your work. Neither event organizers nor attendees care about why your abstract is full of grammatical errors. You probably write in English a lot better than I can write in your language, and I have massive respect for you, but you're still out of luck if your work can't be properly understood by English language audiences.

After that, paste the abstract into the web form, hit Submit, and ... wait.

Submission for larger events is a painful process. You put your abstract in and sometimes have to endure 90 or more days of wondering before you get your answer. Oftentimes the answer is nothing more than a "yes" or a "no." It's okay to ask for an explanation if you've been rejected, but it's also okay for the event to tell you that they don't have time to provide one. If you're going to start speaking regularly, prep well, build up a nice thick skin, and get ready to endure some rejection. Don't worry. Keep practicing, keep trying, and you'll get there.

Of course you also have to write the presentation. And as you do so you absolutely must use the session description you wrote. You've set attendee expectations; make sure your actual session will live up to them. Your presentation should cover everything you said you were going to cover and, if your session description was properly worded, not much that you didn't mention. Naturally, writing the session is an entirely different topic for an entirely different blog post.

Summary

A great session description is a short yet compelling story designed for a very specific reader. The reader is the protagonist, his problem is the antagonist, and you are the narrator, helping the reader through his quest for glory. Know your target audience, understand its problems, help solve them, and your session description will be wildly successful. Remember that most readers only look at a very small part of the story, the title, so make sure to spend plenty of time there. And remember to always keep things moving and interesting; there is nothing worse than a boring story.

I'm sure many of you have opinions that differ from what I've expressed here. I look forward to hearing from you in the comments section below. Likewise, for those of you who have questions I may not have covered above. Finally, I would like to invite readers to post their own abstracts for public criticism. (Constructive!)

Thank you for reading, and I’ll see you on stage!

Search results matching tag 'presenting'

Capturing Attention: Writing Great Session Descriptions

Presenting at Montreal SQL Server User Group

SQL Saturday #39 in NYC