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 F-15: 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 24×7, 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!
Very nice advice. I’m going to review some of my session descriptions this weekend!
Just in time before submission deadline kicks in… Now I need to rewrite everything. Thanks.
@Matt: Good luck 🙂
@Nikola: Which event?
Shred away:
Title: Why I Won’t Be Hiring You
Description: You’re a DBA or SQL Developer and you are looking for a new gig. You’ve trawled the job sites, found a position I am hiring for, and decided that it is the job for you. You spruce up your resume and send it in, hoping for the best. In this session I will go over some critical mistakes that will prevent you from getting a job, such as: Why your resume is an instant turn-off. That thing you said on the phone screen that was flat out wrong.Why the in-person interviewer took an immediate dislike to you
@Nic:
Woo hoo, our first contestant!
Stating with the obvious, the title is a bit jolting. I’m 100% positive you did that on purpose and already know it’s jolting, and it gave me a very nice laugh just now when I read it. But if I were planning a conference I wouldn’t accept it, and if I were looking for a job, I probably wouldn’t attend. Why? Because it sounds like you’re going to punch me in the face when I attend the session, and I don’t like being punched in the face. (Stomach, sure. Face, no way!) Possible to ease it up a bit and still keep it humorous?
Description: I like the audience focus. The tone, again, needs a bit of tweaking. If I read "Why your resume is an instant turn-off," I am immediately on the defensive. I’m not even applying for a job, and literally, when I read that, my brain started saying "no it’s not. Screw you, Nic." Possible to make these things positive rather than negative? "What to put on your resume so that you’re virtually guaranteed a call back" is a lot more enticing, in my opinion. Flies, honey, vinegar, and all of that.
Not sure if you pasted incorrectly but the end seems to be truncated. Do you have a conclusion sentence?
–Adam
There was a conclusion sentence, off-hand I cannot get a hold of it. The SQLSat site nicely truncated it (yay for character limits).
I appreciate the suggestions, I’ll start work on a rewrite that changes it to a more positive thing.
I’m in for review! I’ve been tossing this about in my brain for several months, submitted it to a couple SQL Saturdays with a different abstract, but only given it once. I’m rewriting the abstract for upcoming events and a slight reworking of the approach.
Title: The Heirarchy of Database Needs: A Monitoring Methodology
Level: 200
Do you feel alone, afraid, and in the dark when it comes to the servers in your environment? If we want to know if our servers are healthy, where do we start? Considering that there are hundreds of metrics you can monitor in SQL Server, it’s very easy to feel lost or overwhelmed. This session will review monitoring from a high level, providing a roadmap to attendees for ensuring the critical safety of their operations, planning a monitoring strategy from the ground up, and tools that are available for implementing their approach.
@Mike:
I don’t really “get” the title. At first I thought it was a talk about hierarchies 🙂 … I wonder if you could make it a bit more obvious within the first few words? “Monitoring Methodologies and the Hierarchy of Database Needs” somehow sits better with me, even though I still don’t know what a hierarchy of database needs is. But, I am very curious about it, so I’d read your abstract for sure.
On to the abstract: Again, I’d flip around that first sentence, same reason as above. “When it comes to the servers in your environment, do you ever feel …” This makes people start thinking about their servers right away, and then puts their feelings on top. And that’s where you want ’em to be. Good simple wording in the basic-level abstract, but I still don’t know what a “hierarchy of database needs” is. Answer that, or at least reference it, and add a conclusion sentence to bring it home.
–Adam
Good stuff, Adam! Should be required reading for all speakers submitting abstracts. Looking at the sessions already submitted for review, I’m thinking that you might have the beginnings of a new "service" to the community! Can’t wait to read your hinted at post on the actual presentation development to match the submitted abstract.
Thanks for sharing your thoughts on this topic.
–Nancy
Thanks Adam, I’ll take those into consideration and tighten it up. The title is a side reference to Maslow’s Hierarchy of Needs. http://en.wikipedia.org/wiki/Maslow‘s_hierarchy_of_needs. I can see how that’s not clear, however, and can make that reference a little clearer.
Ok, here is an updated version of the "why I won’t be hiring you"
Title: Hirable and Desirable – How To Make Companies Want You
Description: You are a SQL Server professional and you have decided that it is time to make the next step in your career. You find the position of your dreams and decide to go for it but are unsure where to start. In this session I’ll talk about how to put the wow factor into your resume so you will get that first callback; how you can fly through the phone screen; and how you can land the job in the first 30 seconds of the in-person interview. Applying for new jobs is intimidating, let me give you some helpful tips to make it a little less scary.
@Nancy: “service,” eh? I’ll do what I can, but I’m actually hoping some other people will jump in and help too. As for the other post, well, given that this one took me 10 months to write, please don’t start holding your breath quite yet!
@Mike: Interesting, thanks for the link. I learned something new 🙂
@Nic: Nice title change. Description, great upbeat tone. Now you sound like you’re going to give me a backrub. But I’ll pass. For now.
Ok, I guess I will have to take a raincheck on that back rub then.
Thanks Adam.
Just desire to say your article is as surprising. The clarity in your post is simply excellent and i could assume you’re an expert on this subject.
Great post, Adam. I really liked the idea of crafting a great story with a positive beat in the abstract. I spend most of my preparation time crafting a story around my presentation, even if it is a highly technical, level 400 topic. As you mentioned, we are still humans and it will help a lot if we put our human side in our presentations. But I won’t be able to do so unless my session abstract gets selected. Thanks for writing this. Now to apply these concepts as I write abstracts for the PASS Summit.
WOW, great post, Adam! Especially liked "normal" people definition for people who have a life 🙂
Oh, probably should have called some native writer to proof this comment…
@Nic: Next time we’re alone…
@denise: Thanks 🙂
@Edwin: Reuse the same story! Best of luck with PASS.
@Maria: Thanks, and you generally don’t need the native writer — you’re quite proficient in English. But it never hurts to get a second check done.
Excellent article Adam, the level of detail is amazing. One of the things i have noticed is how short emails are these days lacking the detail, if one took some time to craft the emails we would have less chaos.
Thank you
Very nice article!!! It’s amazing and (incredibly) non-technical.
Please critique:
Level 200
TITLE
T-SQL Throwdown: Is Your Team Ready to Take On Other Teams in a Game of SQL?
ABSTRACT
Join us in a game of SQL where you will compete with other SQL gals and guys, enjoy making new friends, possibly learn some new SQL tricks, and have tons of fun. Create your team for a SQL-off against other teams. The quickest teams to solve 5 timed SQL challenges win bragging rights (at least until next year).
If you can write a SQL query, you have the skills required to play. Each team will need to bring their own laptop with SQL Server 2012 Express Edition (which is free, by the way) pre-installed. Full rules here (link to blog).
Thanks for your post Adam. Actually the way you speak in this article reminded me the judges in AGT, especially Howard =) Thanks again!
@Ramdas / @Fabricio: Thank you for reading!
@Ekrem: Not sure I want to be the Howard Stern of SQL… well, I guess it would have some benefits. I’ll consider it 🙂
@Hakim: It’s an interesting idea as an event at a show, but I can’t imagine a conference accepting it as a third-party session. If you’d like to do something like that, you should really write privately to the event organizers and offer to work with them on creating it and defining the correct marketing/messaging to attract the attendees of the event. I also think you’ll have to get some sponsors for prizes, and somehow make it interesting/interactive enough that non-competitors will want to show up and watch.
Hi Adam – Thank you for so much thought-out detail. I’ll play…!
Title: So You Want To Be A Rockstar Report Developer?
Desc: Why settle for being an average Report Developer? In this highly interactive session we’ll discuss various development, standardization, deployment, and documentation practices that’ll make your SSRS development life easier, your output of higher quality, increase maintainability, and ultimately save you time. Audience participation and sharing of experiences is highly encouraged. Who knows, perhaps even a friendly debate over best practices shall ensue! This session focuses primarily on SQL Server Reporting Services 2012, although some concepts may apply to other BI tools as well. Previous exposure to Reporting Services is helpful.
Level: 100/200
Adam, this post just became a must read and was saved in my favourite list already! I hope that many, no, not many – all speakers out there will realise that they are selling a product, as you said and are not "just presenting", because there is a lot of things that needs to be done before your presentation actually happens(especially true in large events, as you also pointed out!). Thanks again!
@Melissa:
Let’s start with level vs title vs what is a "rockstar?" For me–and maybe it’s just me–"rockstar" means advanced. A go-to guy or gal. Someone I can hand a project to, step away, and it’ll get done. Is that a level 100 person? I don’t think so. I think it’s a level 400 person. And when I read your title, that’s who I think it’s for. So I’m going to ask you: who are you *really* targeting here? Are you targeting someone just getting started (that’s level 100/200 for you) or someone who has some experience already and wants to get to the next level?
Let’s continue on to the abstract. Assuming that you want to actually target the person who already has some experience, your intro sentence is great. But your conclusion sentence is now incredibly confusing. Don’t be wishy-washy. Choose a target audience and laser focus on that target audience.
Other random things:
– I like the second sentence, but as an aside I’m not a huge fan of the "that’ll" contraction. It reads a bit awkwardly in my opinion.
– Audience participation, great. But don’t count on it. Some audiences are more subdued than others. I’d merge the two sentences on that, or maybe get rid of the one about debates altogether. It doesn’t really drive home the desire to attend.
– I think a bit more detail might be nice. After that second sentence, how about a third, listing some of the actual terms used in SSRS, around areas you’ll be covering? (Because, let’s admit it, this is a 300-level talk, isn’t it?)
– Kill the current final sentence and add a proper conclusion. Make people thirst for your content!
@Boris: Awesome–really glad you enjoyed it!
Hi Adam,
Here are the details of my latest session – do your worst/best …
Title- Tracking server activity without slowing it down.
Level – 100/200 (ie its an intro to the tech in question)
Abstract:
All SQL Server DBAs should know how Service Broker and Event Notifications work so that they can implement this very simple feature to make sure they are aware of events happening on their servers. Event Notifications is a very light-weight, asynchronous mechanism for identifying events and taking actions. In this session we will create sessions to monitor for and act on DDL changes, file size changes, index and statistics changes, security changes and more. Attendees will gain an understanding of how they can monitor many servers and stay in control.
Adam,
Excellent points. You inferred an issue I debated on. I had been planning to make it for intermediates looking to go to the next level but a friend reviewed it & suggested I bring it down to basics. So I ended up wishy-washy. I will fix that.
Audience participation – I’m actually delivering it the first time next weekend at SQLSat. Am planning for talkers & quiet people since I don’t know what my audience will be and if I can set them at ease enough to speak freely. We shall see how my little experiment works. My goal is to talk less "at" the audience and more "with" them, but I’m still learning how to make that happen.
Thanks again for taking the time – much appreciated!
Melissa
@Fatherjack:
Title:
– Not properly cased or punctuated. (See the note on Title Case in the article.)
– Tells me what the session is going to be about, but it’s a bit dull. It’s easy to add some personality. For example, "Tracking Activity Without Slowing the Server to a Crawl" says the same thing but uses slightly more active phrasing.
– Are you sure this is a level 100 topic? If someone is already tracking server activity such that they need to worry about not slowing things down, don’t they already know about tracking activity to some degree? What’s your ACTUAL target audience?
Abstract:
– First sentence: Whoa! Slow it waaayyy down. I’m four words in and I’m already somewhat turned off; you’ve not introduced a problem or given me a reason to read, and you’re telling me about something I should know. The sentence also runs on (I think it’s at least two sentences). Finally, it’s important to watch out for plural agreement and similar grammar issues: "DBAs should know how Service Broker and Event Notifications work so that they can implement *this*." This what? You’ve listed two different things.
– Second sentence, okay. Now you’ve introduced a topic from the first sentence. Ideally you’d introduce first and then use the term.
– Third sentence, you’ve used "the royal we." I am not a fan, because "we" aren’t going to create anything. "Fatherjack," the speaker, is going to do the creating. "You," the reader of the abstract, should be doing some learning. So tell readers what they’re going to learn, not what you’re going to do, and especially not what they’re not going to do.
– Fourth sentence: That’s almost a problem statement; why didn’t you tell me that upfront?
Overall: I think it would be in your best interest to reevaluate this session description, putting yourself into an attendee’s mind. "Why might I be interested in attending? What problem can Fatherjack help me solve? What technologies will he propose to help me solve my problem?" In about that order. And keep your tone active, active, active. This is about doing something, making a difference, having an impact.
Thanks for the comments Adam.
I have taken a look at your comments and have made some changes. If you have a moment maybe you could let me know if you think it’s improved at all please?
Title- Tracking Server Activity But Keeping High Performance
Level – 200
Abstract:
Do you want to know when tables or indexes are changed on your server? Maybe you need to audit system changes? Possibly you like the idea of knowing what code will need re-factoring before you upgrade?
Event Notifications is a very light-weight, asynchronous mechanism for identifying SQL Server events and taking actions. Getting Service Broker and Event Notifications working for you will mean you can track changes and spot performance problems easily. In this session I’ll show you how to create sessions to monitor for, and act on, DDL changes, file size changes, index and statistics changes, security changes and more. You will gain an understanding of how you can monitor many servers and stay in control with minimum effort but maximum effect.
@Fatherjack:
Nice changes!
Title: I might change "But Keeping" to "While Ensuring." But YMMV.
Abstract:
– I like the intro a lot
– First sentence after the intro, great. Sparks my interest.
– Second sentence, a bit iffy. You’ve now introduced Service Broker but it’s not immediately clear why. I’d personally not use it at all in the abstract, as it’s not especially important to the prospective attendee that Event Notifications happens to use SSB as its platform.
– "will mean you can" would be better phrased as "will enable you to"
– The final sentence is okay but that "minimum effort but maximum effect" part might need a bit of tweaking. Took me a couple of reads through to fully grok it.
–Adam
Thanks for the 2nd review Adam, glad I made it better.
One thing to note (as I just went to update the submission for SQL Sat Holland), the title is too long for the SQL Saturday website! You’ll need to add that session titles should be no more than 50 chars long in your advice!
Excellent article, Adam. Really good, actionable advice. I’m going to ask SQL Saturday to put this on their speaker submission page.
Otoh, now I selfishly want to request that you do a special 500-level version of this article entitled "Capturing Microsoft’s Attention: Writing Session Descriptions Specifically for TechEd". You’re one of the few speakers I know among the top tier who can consistently get into TechEd.
Great work! Cheers,
-Kev
Tablix – The Rubik Cube of Reporting Services
Level 200 or 300. (i don’t know which)
Did you know that the Table, Matrix, and List controls are all based on the highly flexible Tablix Data Region Grid? So really, they are all one control that can be morphed into each other.
Learn how to get the most out of the Tablix controls in this demo-heavy session. You’ll learn how to best layout data using multiple Tablix controls. You’ll learn how to use parameters to change the layout of the data in these controls to minimize the number of reports that need to be maintained. You’ll learn to create a columnar report that grows vertically as well as horizontally, and you’ll find out about other exciting uses of this highly flexible control.
@Fatherjack: Looks like it’s fixed now. At least mostly fixed.
@KKline: Thanks, would be awesome to have it linked from SQL Saturday! As for the 500-level version, we’ll chat offline 🙂
@Mickey:
Title: First of all, is your target audience expected to know what a "Tablix" is? If not, you have a problem right away, since most people won’t bother reading up, especially after you tell them that the thing is a puzzle. People don’t want ADDITIONAL puzzles to solve at work, in my experience. They already have enough 🙂 … And by the way, it’s a "Rubik’s Cube" (apostrophe S).
Abstract: First sentence. No, I did not know that. But why do I care? What problem can this help me with? Start off right away and tell me what gaps you’re going to fill. Don’t tell me about some technical implementation. Remember, again, you are not your audience. Your audience is probably not a bunch of geeks who care that table and matrix is tablix. Your audience is probably some report developer who is behind on a deadline and is worried that he’s not going to get a very good bonus come December because he’s really screwing up at work. He wants a solution for his problems. He wants a way to do his job more efficiently. Can you help him, or are you going to send him home with a bunch of technical jargon that he’s going to forget as soon as he drowns his sorrows in a bottle of Jack Daniels?
Next part: Same. WHY do I want to get the most out of the controls? You only get to that "why" in the final sentence. (Flexible, vertical as well as horizontal scale.) Pull that stuff right to the start of the abstract. Don’t leave me hanging. "Tablix: The Key to Flexible, Scalable SSRS Reports" … "Want to create columner reports that scale vertically as well as horizontally? Want to quickly roll out ultra flexible reports that will wow your end users?"
Hope that helps.
Adam,
I’m still trying to deal with the fact that I’m probably geekier than my students, but i’ve met those "normal" people so i know they exist.
I did listen and I replaced Tablix with the three controls that are based on the tablix. Only the uber geeks care about the underlying template. Here is my revision:
Table, Matrix, and List Controls: The Keys to Flexible, Scalable SSRS Reports
Want to quickly roll out ultra flexible reports that will wow your end users? Want to learn how to display the data in multiple layouts on the same report? Want to minimize the number of reports that are similar to others?
In this demo-heavy session, you’ll learn how to create a columnar report that grows vertically as well as horizontally? You’ll learn how to have multiple layouts for the same data on the same report. You’ll learn how to use parameters to change the layout of the data, as well as other exciting uses of these highly flexible controls.
Hi Adam,
This is a very useful write-up, of course, and most of this applies to technical writing as well, so this is interesting.
IMO books, articles, and blog posts have a bigger and longer impact – more people will read them, and for longer time. The book that you wrote and we bought in 2007 is still on our desks, and in use. Also you do not have to understand spoken English to understand a book.
Unfortunately, the time spent on speaking is time not spent on writing – and writing reaches out to people who do not understand spoken English and/or will not travel. So, if we concentrate on speaking, we fail to communicate with lots of people.
Having said all this, can you have a look at this draft:
Develop Rock Solid Databases 8 to 5, Go Home, Enjoy Life.
Level 400.
You are a database developer frustrated with too much troubleshooting and bugs fixing? You do not have much time left for new development, and your work-life balance is ruined? It can be helped!
You will learn how to use automated tests to streamline communication, eliminate bugs and deadlocks, and ensure predictable performance. You will also see how to deploy big changes in small incremental low-risk steps.
@Mickey: I’m not sure you’re selling me hard enough in the title. How about putting the key words first? "Flexible, Scalable SSRS Reports: Table, Matrix, and the All-Powerful Tablix" or something like that? The abstract is definitely improved but can use a bit more punch. Try reading it out load and adding emphasis where needed.
@Alex: I agree that writing can have a lot more impact than speaking. For example, this blog post has been read 3700 times or so as of right now; no way ANY of my talks has ever been watched that many times. But remember that there are different learning styles; some people learn better from books, and others learn better from spoken media, so you’re targeting different audiences with various content. And for me personally, speaking is a lot more fun than writing — which is why I do it a lot more often. YMMV 🙂
Now as for your session…
Title: I REALLY like where you’re going with this but I find it a bit choppy. I had to exert a bit of effort while reading it to get what you meant. I wonder if the numbers are hurting it? It might be better to say something like: "Developing Rock Solid Databases and Reclaiming Your Life" … that’s not perfect, but just trying to think of alternate ways to say the same thing minus the numbers and commas. (Also, the period should not be there in a title.)
Abstract: The first sentence is too passively worded (and it’s a bit awkward). Maybe just pull off a bunch of words? Here’s an example: "Spending too much time troubleshooting? Losing entire weekends fixing bugs? Sick of not developing anything new — let alone having a proper social life? It doesn’t have to be that way…"
Second part: First sentence is incomplete. Should say "In this session you will learn…" or similar. Will the automated tests help with all three things? (Communication, elimination of bugs, predictable performance?) That’s how it currently reads; if these are separate topics you need to rewords. I’d like to see some more detail on what, exactly, this talk is about, especially since it’s 400 level. It all feels a bit vague. It might help to use a numbered structure. "First you’ll learn about V and how it impacts W. Then you’ll see why X solves Y. The talk will close with a discussion on Z…"
Also, I highly recommend adding a final sentence to bring things together. "After attending …" maybe referencing work-life balance, getting the weekend back, or whatever.
Adam,
Thank you for a quick response.
Next revision:
"Developing Rock Solid Databases and Enjoying Your Life Uninterrupted by Troubleshooting"
Level: 400
Troubleshooting most of the time and tired of it? Spending your weekends fixing bugs? Sick of not developing anything new — let alone having a proper social life? You can fix it!
In this session you will learn how to develop robust databases that need very little maintenance. First, you will see how automated tests eliminate miscommunications, dramatically reducing number of fixes. Next, I will show how automated tests enable to change databases with confidence, without introducing bugs, deadlocks, and performance problems. Finally, you will use this knowledge to refactor a large live OLTP table without any downtime for users or overtime for developers.
After attending this session, you will learn how to develop robust databases and enjoy excellent work-life balance.
–End–
Regarding 400 level: there is a lot of things to describe, so I would just mention things like "adding an index can slow down a select" or "adding an index can cause deadlocks" or "triggers do not ensure 100% integrity of data". Presumably that should be a known fact, there will be no time to elaborate on things like this. This is why I think the level is 400.
What do you think?
@Alex
I’d cut the words “by Troubleshooting” out of the title. They end it on a down note and make it significantly weaker. I might also cut the word “Your,” so the title would become: “Developing Rock Solid Databases and Enjoying Life Uninterrupted”
That just sounds a lot slicker 🙂
Abstract looks pretty good! Only comment is that I think you need to be careful with tense. “After attending this session, you will learn” <– will you learn AFTER the session, or IN the session? Minor details. Read it out loud a few times and make sure it really flows.
–Adam
Adam,
Thank you for the feedback.
Adam, here is mine after reading your article which was great.
Unreliable Deployment: Consistent Database Release
During your day, you are pushing database code for a release to some database server in some environment, the deployment does not work. Where is the Golden code for the database objects, Production or Source Control? Get the database code for Source Control, deploy in object order with PowerShell. You will be able to deploy from Source Control to any database in any environment, consistently.
@Tom: Glad you enjoyed the article!
You haven’t told me who your target audience is, so I can’t weigh my feedback against how applicable your session description is to that audience, but here’s how I read things…
Starting with the title, I’m a bit confused. You’re going to teach me how to create "Unreliable" deployments? I don’t think that’s what you meant. I think you meant to say "Reliable." Or were you trying to show that you’ll help convert unreliable to consistent? Perhaps reframing it as "Converting Unreliable Deployments Into Consistent Releases" would be better?
For the abstract, a big issue is awkward phrasing and sentence fragments. "During your day, you are pushing database code for a release to some database server in some environment, the deployment does not work." This is both far too passive, and it feels like the final fragment has been tacked on; let’s try rephrasing this in an active tone… "Have you ever felt like it takes an exorbitant amount of time to push out your database code releases? Copying file after file between environments and between servers… Isn’t there a better way?"
The rest of the abstract needs similar work done. This, for example, feels like part of another sentence — I don’t understand how it fits in: "Get the database code for Source Control, deploy in object order with PowerShell."
The final sentence doesn’t leave me with enough meat to make me excited. Tell me why I want to do use PowerShell and deploy. Tell me about time savings, better and more reliable deployments, how much easier my life will be … something!
As I’ve told others here, read your abstracts out loud. If it doesn’t flow, it’s not going to read well either. And then read your abstract to someone who isn’t a SQL Server professional. If that person can’t grasp the key points, chances are good that your core audience won’t, either.
–Adam
Hi Adam,
I used more action words. I hope you like my latest rendition. Thank you for helping out. 🙂
Flexible, Scalable SSRS Reports Achieved through the All-Powerful Tablix Controls
Want to quickly roll out ultra-flexible reports that will wow your end users? Want to learn how to display the data in multiple layouts on the same report? Want to consolidate similar reports while still providing flexibility to your end users? This can all be achieved by leveraging the three controls based on the Tablix template: Table, Matrix, and the List control.
In this demo-heavy session, you’ll learn how to create a columnar report that grows vertically as well as horizontally? You’ll learn how to have multiple layouts for the same data on the same report. And you’ll learn how to increase the usefulness of fewer reports.
–Mickey
@Mickey:
Very nice! Just two small comments:
– Capitalize "through" in the title.
– Put in a conclusion sentence! I can’t stress that enough. End on an up note. Don’t just end.
Thanks Adam for all your help.
–Mickey
Hi Adam,
If its not too late I would like to play.
Title Introduction to Performance Tuning the Database Engine
Level: 200 (Future SQL Saturday Pre-con)
Have you always wanted to dig into performance tuning but weren’t sure where to start?
During this pre-con, you will establish a solid base that will allow you to identify and isolate problems within your SQL environment. You will learn how to identify the SQL statements that are causing performance problems and apply basic concepts to improve your system’s general performance. Along with this, you will learn to implement and efficiently utilize a performance baseline for proactive maintenance keeping you one step ahead of the game. You will be able to identify commonly occurring poor practices implemented by developers and fix them. Next, you will learn to improve the performance of your troublesome queries when you are unable to change the code. You will master best practices that can be applied to your systems to improve performance on the database and instance settings level. Once you leave this session you will have a framework and tool belt to start performance tuning on Monday!
Adam,
Thanks for the post, lots of great points! I have a session that I would love you to review as well if you have a chance.
Title: Capture Change and Apply It with Change Data Capture & SSIS
Level: 200
Summary: Loading and updating data warehouses is a challenge. Auditing changes is a challenge. Change Data Capture (CDC) can help with both and more! Learn what CDC is and how to set it up, then use SSIS 2012 to make it even easier to support going forward.
@John:
Nope, not too late. There is no expiration date on this post 🙂
Title: Serviceable but rather dull. Is there something you can do to spice it up a bit? "Performance Tuning for the Uninitiated" or something similar would be a much snappier way to say the same thing.
Abstract: I don’t know if I like your lead in; it feels a bit wishy-washy. "Yeah, I guess I’m kind of interested in this…" Might try being a bit stronger: "Given its complexity, performance tuning can be tricky to learn; have you ever wished you could get a simplified, distilled vantage point?"
Good list of topics but I’m almost afraid you’ve got too much there. Sure you can do all of that in a single day, especially at 200 level (where you’d be introducing a number of new concepts, explaining things, etc)? I might recommend trimming and tightening just a bit.
The lead out sentence is a great start but can use just a touch of reworking. I’d personally flip it on its head:
"Back in the office on Monday morning you’ll find yourself armed with the knowledge and tools to start performance tuning right away!"
@Steve:
Interesting title! I’m trying to figure out whether "apply" is the right word to use; it doesn’t EXACTLY project ETL for me, but it’s close. Worth spending a little bit of time thinking about. From a title case perspective, "it" should be all lowercase, and "With" should be uppercase. (Anything with four or more letters.) I’d also swap the & symbol for "and."
The "summary" is really just that — not quite an abstract. Do you have a fuller version? What kinds of events are you using this for? I’d like to see a bit more of a story and a bit more detail on the technologies, especially since you’re targeting level 200. (Example, you mention that CDC can help, but you don’t give the reader a brief overview of what it is. A bit of detail can REALLY help capture the attention of your target audience.)
Adam,
Thanks for the feedback, my original title was "ABCs of CDC with SSIS 2012" which I thought was clever from a geeky standpoint, but like you say in your post has too many buzz words that won’t capture people to come to the session. So I was trying to come up with something that said more what it was about. The other challenge is the word limit for PASS Summit, which is being created for and I only have 1 character left for the Title with their limits.
Below is full abstract that I have currently come up with:
Whether you are trying to setup a new data warehouse, keep it updated, audit changes to your databases or quickly load changes to another database Change Data Capture (CDC) is a solution for all the above and can now be setup and supported easily with SQL Server & SSIS 2012.
Change Data Capture (CDC) has been around since SQL Server 2008, but has been underused because it was difficult to fully implement. SSIS 2012 now provides support for CDC with new components that make consuming the captured data very easy to apply.
This session will define what CDC is and with live demos show how it is setup on your databases. Once it has been setup then you need to consume and apply those changes, this will be demonstrated with live demos using SSIS 2012 to create packages that apply the changes.
Thanks again for taking a look at this!
@Adam some great information here already. Thanks for taking the time to help us out!
I’ve changed this one a bit (http://www.sqlsaturday.com/viewsession.aspx?sat=204&sessionid=13116) but I’m not sure if it’s for the better. What do you think?
Title: Hacking SQL Server
The best defense is a good offence. Learn how to practice hacking without going to jail or getting fired. In this presentation we’ll be going over how to exploit weak SQL servers with actual tools of the penetration testing trade. You will learn why the SQL Service is a popular target on your network and how to defend against basic attacks.
Hi Adam, thanks for the original review. Here is the rewrite.
Converting Unreliable Deployments Into Consistent Releases
Level 100/200
Each database is made up of a lot of objects in different environments. When you create an object like a table or stored procedure, you need to get this object deployed into each environment. The deployment process is frustrating; an object is missing or an object is deployed in the wrong order. Together we will discover how to separate each object for proper order deployment while releasing only objects which have changed. Deployments can cause you trouble but we will provide a reliable deployment process.
Thanks Adam for this great post.
Regards,
Hossam Alfraih ( @SaudiGeekNET )
Hi Adam,
Thank you for the great advice! I starting presenting last year, and looking back at my abstracts, they don’t make any sense. I feel lucky people even showed up to my sessions. I could use your help/criticism.
Level: 300
– targeting people who’re familiar with and use SSIS on a regular basis
Title : How to Automatically Generate Hundreds of SSIS Packages in a Very Short Time
– don’t know if a question mark is allowed in the title
– Alternative title: Automate SSIS Design Patterns for Faster Package Development
Description: You’re an SSIS developer or an architect responsible for an ETL project. You need to create hundreds (or even thousands) of packages.
Manually creating these packages could take a lot of time (we’re talking months of development). Moreover, it’s easy to miss something while creating these packages, and source/target metadata could change requiring you to recreate them (more months). You just seem to run in circles. What can you do about it? Automate Your SSIS Development. BI Markup Language – a free plugin – allows you to programmatically generate packages based on metadata. If you need to make changes, you can simply update the BIML code and automatically regenerate them. Join me in this session, and we’ll see how to automatically create SSIS packages using BIML. You’ll learn plain BIML, BIMLScript and it’s building blocks, leveraging metadata, and an approach I call D[ee]MOB that helps you use all of this knowledge for your specific needs.
Thank you in advance for your time.
@SamuelVanga
@Sam Vanga
I like your alternative title significantly more than your other title, because when I read th other title I’m left scratching my head. "Why do I want to automatically generate hundreds of SSIS packages? What will I do with them all?" The second title answers this question. "Ahh, if I automate SSIS, package development will be faster. Score." However, I don’t know what it means to automate a design pattern. I think you mean something else there.
As for the description:
Are you sure most SSIS developers need to create hundreds or thousands of packages? I think that’s the exception and not the rule (based on my own personal experiences). Are there reasons that can be needed? Can you specifically call those out? (While not adding significant bulk.)
The first few sentences of the second paragraph seem a bit wordy. Can you cut it down a bit?
I think you should introduce BIML earlier in the abstract, as well as more directly call out problems that it will solve. This sentence is supposed to be the kicker, but it comes off a bit weak: "If you need to make changes, you can simply update the BIML code and automatically regenerate them." Better would be something like: "Making changes to your packages no longer requires an excruciating tour through wizards and editors; instead simply update your BIML in one place, and you’re a click away from regenerated packages." (Maybe not perfect but hopefully you get the idea.)
All in all I’d like to see a lot more emphasis on problem – solution, and a lot less on the solution itself. I want to know WHY I should attend your session and as a professional ETL developer (which is what I am; exactly your target audience), I’m not really feeling it. I think you should especially focus on building strong intro and clencher sentences.
Hope that helps a bit,
Adam
Thanks Adam! I agree, it’s too wordy.
Can you look at this one? I removed the "hundreds or thousands of packages" piece to avoid confusion, but it’s generally a good practice to create a package for each logical unit of work. So, if there’re 500 tables to be loaded, I’d create 500 packages (generally speaking).
"You create a number of SSIS packages for a typical ETL project. Manually creating them can be time-consuming. Moreover, it’s easy to miss something or source/target mapping could change requiring you to recreate the packages. BI Markup Language – a free plugin – offers a powerful solution. Join me, and we’ll see how to use BIML for programmatically creating SSIS packages. You’ll learn plain BIML, BIMLScript and it’s building blocks, leveraging metadata, and an approach I call "D[ee]MOB" that helps you use all of this knowledge for your specific needs."
Is this any better?
I could start with "BIML provides a powerful…", but i don’t like that. I want to state the problem in the first line.
@Sam
It’s still not powerfully (actively) worded.
Consider this:
"A typical ETL project involves creation of numerous SSIS packages; and each one requires an extensive time and energy investment."
I think the issue in the original sentence is the "you create." For some reason — I’m not exactly sure why — that just kind of flattens things.
"BI Markup Language – a free plugin – offers a powerful solution."
For what? Explicitly call it out!
–Adam
Adam, I’m sorry to take up more of your time. Can you look this one more time? The like "… offers a powerful solution to…" isn’t complete yet, but how do you feel about this overall?
A typical ETL project involves creation of numerous SSIS packages; and manually creating each of them can be exhausting. Moreover, it’s easy to miss something or source/target mapping could change requiring you to recreate the packages. BI Markup Language – a free plugin – offers a powerful solution to <waiting for a punch :-)>. Join me, and we’ll see how to use BIML. You’ll learn plain BIML, BIMLScript and it’s building blocks, leveraging metadata, and an approach I call "D[ee]MOB" that helps you use all of this knowledge for your specific needs.
Thanks,
Sam.
"Moreover, it’s easy to miss something or source/target mapping could change requiring you to recreate the packages."
This sentence is a bit rough. I think the "missing something" is implied by the manual element mentioned in the prior sentence. How about:
"Moreover, a production environments are never truly static; source or target mappings can change and you might be forced to re-create an entire package from scratch."
Aside from that, looking good. Add a clencher sentence at the end. "Attending this session will give you more time, energy, and luck with the opposite sex." Or something true, ideally. Something to end with a bang, in any case. (No pun intended.)
Hi Adam, I’m back with a few changes! Please take a look.
Level: 300
Title: Based on a quick research, most of the talks on BIML have a title similar to my old one, so I’ve changed it. I’m now debating between "Automate Your SSIS Development To Fight Missing Project Deadlines"
and "Programatically Create SSIS Packages When You Return To Work"
Abstract: Manually creating the numerous SSIS packages needed for a typical ETL project can be exhausting. Add to that the system changes – as simple as a column rename – that force you to make modifications to packages and it takes even more time, potentially delaying your project deliverables. In this session, you’ll learn how to use metadata and BI Markup Language – a free plugin – to programmatically generate SSIS packages. You’ll see the building blocks of BIML and a principle I call "D[ee]MOB" that helps you apply this knowledge for your specific needs. You’ll also see how easy it is to make changes and regenerate a package. If you want to create ETL solutions faster and go watch funny cat videos, this session is for you – but just don’t tell your boss.
Thanks again,
Sam.
Adam, very nice job on writing this up – I appreciate the experience, time, and effort you put into it. Thanks for sharing and raising the bar.
So I just submitted this as my first attempt at PASS 2014. I’d love feedback but mostly – just thanks for writing the tips in the first place.
Level 200
Summary: Dive into to full feature set of SQL Server Management Studio. Learn techniques to use SSMS to it’s fullest potential and improve both your efficiency and quality of output as a database professional.
Abstract: Chances are you touch SQL Server Management Studio almost every day. The question is… do you use it to it’s fullest? This session will cover 15 aspects of SSMS that can make you more efficient as a professional. We’ll cover everything from hotkey secrets, to configuring your toolbars. We’ll walk through the debugger, data tips, templates, drag/drop and copy/paste behaviors you may not know about. You’ll learn how to issue queries against multiple connections and differentiate your environments to protect production. Finally we will dive deeper into what it takes to build your own add-ins from scratch.
Prerequisites: Session is for SQL professionals who use SSMS as part of their daily job. 1-3 years TSQL experience helpful for demos. .Net experience helpful.
Woops … forgot to paste the actual title. Make SQL Server Management Studio bark like a dog!
@Sam: It’s looking good but I think you want to reconsider that final sentence. Kind of feels like you’re trying to force some personality in, and it doesn’t tie together nicely. If you’re going to do that you need to introduce the personality first and then revisit it later. Don’t just end with it. Also, you shouldn’t use any nonstandard acronym without calling it out first. You mention BI Markup Language then later shift to BIML. But the assumption seems to be that your readers don’t know either of these terms, so you really need to write (the first time) "BI Markup Language (BIML)."
@Andy: Glad you liked it!
@Russ:
A) Title case. "Make SQL Server Management Studio Bark Like a Dog" (First reaction: Is that a good thing?? But I am intrigued.)
B) "Chances are you…" Remove "chances are." Your audience touches SSMS every single day. That’s who you want to talk to.
C) "do you use it to it’s fullest" –> "do you use it to ITS fullest" … And I might add another clause here, something like "or are you wasting valuable time?"
D) "We’ll cover everything from hotkey secrets, to configuring your toolbars." I don’t like "we" (see above), but maybe you do. I also think this would be more powerful as a list of THREE items. It feels a bit rushed with only two things. And the sentence after seems like another list. Why do you need two lists in a row? Are these two sets of topics somehow different from each other? How about putting them together into a single sentence? Or if they do need to be in two sentences, maybe call that out. "First you’ll learn about XXX: everything from hotkey secrets to configuring your toolbars. Next you’ll see how to deal with YYY: the debugger, data tips, templates, …" Oh, and google "Oxford comma."
E) The final sentence is yet another item that seems like it can go on a list. You could make that sentence significantly more powerful, something like: "The session will conclude with a discussion on how to attain ultimate flexibility by building your own ad-ins from scratch."
F) After that current final sentence you need a REAL final sentence. A closer. Remind the readers why they’re there and about the benefits of attending the session.
–Adam
What a great article for those of us who are just getting started, thank you so much! 🙂
Adam – thanks for the great feedback. Final submission here:
http://www.sqlpass.org/summit/2014/Sessions/Details.aspx?sid=6025
First off, great read, thanks for the post. Next, I’m obviously late to the party, but would you mind shredding my entry?
Title: Encrypt All the Things: A Walk Through Protecting Your Data with Encryption
Level: 200
Abstract:
Are your backups like a stack of cash free for the taking, or a hardened ATM that can withstand an assault? Are your database connections scrambled and safe or are you sending data over the party line for anybody to hear? In this session we will walk through the many ways SQL Server allows you to protect your data using encryption. You will be introduced to the various ways for protecting data at rest, from unauthorized users, and while in transport. Since nothing comes for free, we will look at how much all of this is going to cost you, in time, money, and failure to implement.
@Jason Carter
Nice job!
Title is good in my opinion.
"In this session we will walk through the many ways SQL Server allows you to protect your data using encryption. You will be introduced to the various ways for protecting data at rest, from unauthorized users, and while in transport."
I don’t like the repetition of the word "ways" in the second sentence. I’d change it to: "You will be introduced to methods for protecting data at rest, from unauthorized users, and while in transport."
I don’t like the "we" in the final sentence, but perhaps that’s just me. And in any case, you shouldn’t have a comma after the word "you" in that sentence.
Finally, you need a closing sentence. Maybe something about how encrypting data will keep you in the job, therefore obviating the need for ATM robbery?
–Adam
Love the suggestions, second draft:
Are your backups like a stack of cash free for the taking, or a hardened ATM that can withstand an assault? Are your database connections scrambled and safe or are you sending data over the party line for anybody to hear? In this session you will be guided through the many ways SQL Server allows you to protect your data using encryption. You will be introduced to the various methods for protecting data at rest, from unauthorized users, and while in transport. Since nothing comes for free, you will learn how much all of this is going to cost you in time, money, and failure to implement. After attending this session you will have the necessary tools to encrypt your data, and protect your job which should help avert the need to rob an ATM yourself.
Hey Adam –
I just read through this again and decided to submit a session for Summit – thoughts/opinions very much appreciated.
Title: Communicating all around the Compass
(Ironically, I’m still struggling with communicating this title well)
Level: 100-200
Abstract:
Communicating. We all do it, every day. But do you do it well? How well can you communicate up to management? Can you give management bad news and make them smile while you’re doing it? What about your direct reports? How do you communicate your support for them when or if they muff something up? How do you let them fix the problem without being so involved in it that you hinder them in their solution? Once you’ve figured all this out – how do you communicate your skills out to the world? Do you know that just changing the order of the words in your resume can dramatically change how they’re perceived? These questions and more will be answered, with stories, with humor, and with experience (both good and bad).
@Tom
The title definitely needs work (also, proper title casing). It’s not PROJECTING the nature of the talk. I don’t know what "the Compass" refers to. I think you should scrap it and try again. Try to think about the one thing that you want the reader to think of upon reading your title, and get that in there.
"Communicating. We all do it, every day. But do you do it well?"
Okay, that’s a pretty good lead-in. I wonder, though, if "can you do it better" might not be more ideal. Everyone thinks they communicate well. Most people realize that they can be better, and would therefore be more interested.
"How well can you communicate up to management? Can you give management bad news and make them smile while you’re doing it? "
A few thoughts on these two sentences. First of all, I’m not sure I love the idea of mentioning "management" in two sentences in a row. Can you change "give management bad news" to "share bad news" or something similar? Secondly, does making people smile while delivering bad news necessarily indicate that you’re communicating well? Third (and I’ve just broken this in my suggestion), perhaps another word instead of "communicate" would be ideal? I’d like to see more variety (more synonyms) used so that you don’t have the same word over and over and over in the abstract.
"What about your direct reports? How do you communicate your support for them when or if they muff something up? How do you let them fix the problem without being so involved in it that you hinder them in their solution?"
I don’t think "muff something up" is a good phrase to use in an abstract. It won’t translate well. It’s not clear to me how letting people fix a problem has anything to do with communication. Can you clarify?
"Once you’ve figured all this out – how do you communicate your skills out to the world? Do you know that just changing the order of the words in your resume can dramatically change how they’re perceived? These questions and more will be answered, with stories, with humor, and with experience (both good and bad)."
Change the hyphen to a comma. And I think "your own skills" instead of "your skills." Rather than "Do you know that …" consider "For example, …" Don’t make it a question. Tell the reader.
Finally, close it up. "After attending you’ll be on the road to better, more direct communication, better able to engage all levels of management and blah blah blah…"
Thank you for that insight and your time – very much appreciated. I’ll get to work on that today.
Title: Fill Factor: Performance or Nuisance?
Level 100
Abstract: We will expand on a little known but widely modified feature of SQL Server. Fill Factor is something to look into tuning after all the low hanging fruit has been addressed. This is not a deep dive into the underlying mechanics of how SQL Server works, but a softer more useful approach to this subject. We will be looking into why changing this could be either good or bad for your environments. This presentation is useful for DBA’s as well as developers trying to get a little more out of their servers.
Well I just finished the first cut of the Program Committee Reviews. Although nothing finalized yet, I can’t believe if people just read through this post it would have made my job easier (or rather harder, depending how you look at it) Perhaps this should be REQUIRED reading.
One thing I want to point out is perhaps start out with the 3 Goals first. What is it your attempting to do and explain. How will it help the audience at large? They should be thoughtful sentences, and not after thoughts.
It would also help if you have presented this at other SQL Pass events, namely SQL Saturday. Use the notes section to tell the reviewers that you have presented this x times will get you bonus points at least for me. Select the right level with corresponding pre-reqs.
Keep it short and sweet, and rewrite your title several times until you get that great one. It should stand out above all the rest. This should probably be the last step as everything in the abstract should support it. Put my shoes on looking at a large amount of abstracts and grading them.
If you have attended PASS SUMMIT before, take a look at the abstracts and their titles. The past selections should be models on future submissions.
All the best! See you in Seattle 2015!
@Andrew
Thanks for your comments. I hope PASS will make those three goals absolutely required for all submissions going forward, and will publish suggested formats, wording, and so on. I think the goals should be shown to attendees as well, when they’re perusing abstracts online.
Goals are, in my humble opinion, the foundation on which great talks are written. Too many people try to write their talks, instead, to fit into their clever titles. It might LOOK like that’s how many speakers do it, but that’s just because they have practice — in reality it never works out to do it that way!
–Adam
Very nice article even though just seen it a few years later. It has helped.
Adam, well done! I truly wish I had read this back when you initially wrote it as I had to learn some of your wisdom the hard way! Because of that, I considered creating a session targeted to help folks become new speakers. Would you be opposed to me referencing some of your material (with appropriate credits)?
@Aaron
Feel free! Hope I’ll see you at SQL Saturday Indy later this year?
I liked how couple of times in the past you had tossed my abstracts…Reading this article tells me why exactly. Thanks for doing this Adam. I’m gonna have a much better resolve in submission this year.