When I first started submitting abstracts to conferences, I wrote bland, technical descriptions of what I’d be talking about.  Later on, I thought being a good speaker meant having lots of people in my sessions, so I wrote spammy abstracts:

“SUNDAY SUNDAY SUNDAY!  COME SEE THE MOSTEST SPECTACULAREST DISPLAY OF SKILLZ EVER!  EVERY SINGLE DATABASE PROFESSIONAL – NAY, HUMAN BEING – SHOULD BE IN MY SESSION!  I PROMISE YOU’LL BE AMAZED AND DUMBFOUNDED AND BETTER LOOKING!”

Over time, I figured out that the goal of writing an abstract isn’t to get as many people into the room as possible.

The real goal of an abstract is to keep people out.

My abstracts need to communicate what I’m teaching, who should attend, and who should not attend.  When I’m communicating what I’m teaching, I try to use the coolest, most creative wording possible.  I use tricks from ProBlogger to craft appealing headlines and session titles, but that’s where the spam ends.  When I’m dealing with the last two needs – who should and shouldn’t attend – I lay things out in crystal clear language.

I know what you’re thinking, because I used to think the same thing: you think every single DBA should attend your session.  You think you’re going to craft a perfect balance of junior and senior material so that there’s something for everyone.  That rarely works, and instead, try to focus.  Focus is saying no.

Focus is picking exactly one person to be your target audience, and then completely satisfying that one person.  Figure out how to get that person into your audience, and how to keep the rest of the people out.  Let the others go see a session that’s more relevant for them, because if you don’t, they’re going to give you bad feedback.  They’ll say your material was too junior or too senior.  That doesn’t mean your material is bad – it means your abstract is bad, because it didn’t weed those people out of the audience to begin with.

To help, I’ve written a set of profiles for people who attend database conferences.  As you read these, think about whether they should sit in your audience.

Developer Profiles

Oliver Klozoff is a fresh-out-of-college developer.  He majored in Computer Science because he thought it’d make him rich.  He has no passion for technology – his skills are more C– than C++.  He lucked into his first job as a C# developer, is learning his way around Visual Studio, but he’s never opened SQL Server Management Studio.  His code barely works on his own machine, let alone in production, and he has no concept of whether the code is fast or slow.  He’s just finished his first application with LINQ and doesn’t understand why people think SQL Server is hard – mostly because he thinks LINQ handles it all for him.

Seymour Butz’s business card says he’s a Senior Developer, and that’s mostly true.  He’s got five years of experience, but he’s the only developer at his shop who hasn’t quit due to the abusive managers.  He enjoys what he does, reads programming blogs every now and then, and does a pretty good job of catching exceptions in his code.  He can identify when a query is running slow, and he’s comfortable adding tables and views in SSMS, but he relies on the Database Tuning Advisor to add indexes for him.  He doesn’t know whether 10 indexes on his tables are good or bad, but he’d like to learn.

Amanda Hugginkiss is the sharpest of the C#.  She’s one of those people who was born to develop.  She was contributing to open source projects before she got her high school diploma, and by the time she dropped out of college, she’d coded for three different startups.  She documents her code even though it explains itself, and she writes unit tests before she starts coding.  She knows when to use LINQ, when to switch into stored procedures, and how to read a basic execution plan. Every employer wants Amanda Hugginkiss.

Database Developer Profiles

Mike Rotch used to be a Java developer, but he gradually moved into database development.  His company builds Java apps with a SQL Server back end (yes, it actually happens) and he was always the first guy to understand whether problems were due to Java or the database.  It’s not that he’s a SQL pro – he’s just naturally curious, enjoys learning, and knows how to use Google.  He’s process-oriented: when there’s a problem, he troubleshoots methodically.  He’s comfortable writing T-SQL, reading execution plans, and makes good judgment calls about when to add an index or when to fix the query.

Jacques Strap is the kind of guy you want around when things start to get dangerous.  He’s fresh out of the field – well, maybe “fresh” would be the wrong word.  Let’s be honest: his code smells.  He used to be a salesman, but he kept writing more and more Crystal Reports for the sales managers, and next thing you know, his stuff was all mission-critical.  He understands what data means to the business, and he’s able to think like a user.  He knows how to prioritize, which is good and bad: his first priority was satisfying the business report needs, and his last priority was making it run fast.  As a result, he’s got thousands of lines of T-SQL in production stored procedures, but none of them are quick.  Nevertheless, he’s got a never-say-die attitude, and the business people love him.  He wants to look like a hero in their eyes.

Database Administrator Profiles

Hugh Jass was working happily in his cube as a systems administrator for years until the company decided to buy SharePoint.  They handed him the DVDs, told him to get it implemented, and didn’t give him any training or consulting budget.  He did typical Microsoft installs – setup-next-next-next-finish – and things started humming along.  He turned his back, and next thing you know, he’s an accidental DBA, and all 1,000 company employees are storing documents in SharePoint.  He isn’t comfortable in SSMS, let alone T-SQL or DMVs, but he knows the bejeezus out of hardware and Windows.  He knows there’s a problem because CPU is averaging 95%, the hard drives are smoking, and the users are whining, but he doesn’t understand what’s going on inside the black box of SQL.

Drew P. Wiener loves to say that he’s got ten years of experience as a DBA, but what he doesn’t realize is that it’s the same one year over and over.  He’s been managing the same twenty SQL Servers the whole time, not really improving anything dramatically, just making sure the trains run on time.  He’s got one cluster and one transactional replication setup, so he puts clustering and replication on his resume, but he doesn’t really understand what makes them tick or how to fix them if they explode.  He’s perfectly comfortable with T-SQL, but hasn’t learned the new stuff like CTEs or TVPs – he just doesn’t know what he doesn’t know.

Ivana Tinkle can take a quick look at a server and have a pretty good idea of what’s going on.  She’s mastered Ozar’s Hierarchy of Needs, and now she’s teaching her junior DBAs how to do the same.  All her servers are well-protected, stable, and part of a master plan.  She attends one or two conferences per year, and she’s getting ready to put on her first presentation for the local user group.  She knows what she knows, and knows what she doesn’t know – but she’s on a mission to reduce the latter.

Manager Profiles

Yes, managers actually attend conferences.

Rolo McFlurry is a sweet, lovable guy who means well, but he’s incredibly destructive.  He knows enough to be dangerous, and he doesn’t know just how dangerous.  He kills SPIDs when they block his queries, remembers the SA password because it’s the same as the Windows admin password, and he violates all the standards while he tells his DBA team to enforce them.  He hasn’t even begun to track metrics like uptime or data size.  He just wants the CEO’s reports to run fast, and he wants to go home at 5:00 PM.  He attends conferences to get out of the office, and whenever he sees the presenter doing something, he’ll try the exact same thing in production when he gets back.  He loves pointing out how the MVP presenters all run as SA, so why shouldn’t he?

Ollie Tabooger spent years in the trenches, working his way up as a database administrator at a global financial firm.  After fifteen years of dedicated service, managing first Sybase, then SQL Server, then a little Oracle too, he became a team manager.  He has a dozen very talented direct reports who all respect his dedication and technical prowess.  He attends conferences to see what’s coming next, to learn new tricks to manage SQL Server at large scales, and to network with vendors who all want to get into his pants.  (For his wallet, you understand.)  He likes sessions that explain the why, but not the how – he hates seeing demos.

The Moral of the Story

Don’t ever, ever, ever say your session has something for everyone.  You might get a lot of attendees, but your evaluations will be spectacularly poor because the attendees will feel like you wasted their time.

If you liked this, check out How to Deliver a Killer Technical Presentation, Dealing with Presentation Criticism, and How to Pick Blog & Presentation Topics.