An increasing number of SQL Saturday events are adding pre-conference seminars the day before the main event. Having run five of these at this point, I’ve picked up some tips you may find helpful. This is going to be a rather long post, because there are a number of things to take into consideration as both an event planner and as a presenter. I’m splitting this into separate posts, but you may wish to read both, regardless of your role. Each party benefits from awareness of what the other is going through.
Adding pre-cons to an event adds a lot of extra work. So, before getting into the advice, let’s get the ‘why bother?’ question out of the way.
It’s kind of a big deal. Adding an extra day for one or more day-long classes specifically for day-long seminars really adds to the overall benefits attendees receive. It opens up the type and depth of training provided by your event. There are a variety of topics that simply can’t get the treatment they deserve in a one-hour timeslot. Start-to-finish workshops and deep-dive seminars are key examples.
Money. Being a free event, many SQL Saturdays can use another avenue for raising needed cash to pull off their events. I’ve seen events where the planners got the pre-cons sponsored (great work on their part, btw), but these are traditionally paid events. Whatever’s left after covering the costs can go toward the main event, and to speakers to help offset travel costs and loss of billable hours. Warning: it’s usually not a lot of money. I’ll cover that in the ‘Cons’ section, below.
1. Time and Effort. Adding pre-cons to your event just piles more work on what is normally a very busy time. You may need to find another venue because the place that lets you run your event on Saturday is open for normal business on Friday. There’s a separate registration process. People cancel and want refunds. You must also plan for food and refreshments, but for a much smaller group than on Saturday, so catering can be a hassle. That’s a lot of extra work for a rather small subset of the folks who will attend Saturday.
2. It’s a major commitment. People are paying money to attend, so expectations get a bit higher. You’re making a bet on a single speaker for the whole day. If a speaker is a no-show for a pre-con, you will be hard-pressed to find a replacement. Attendees often attend a pre-con for both the specific topic and the speaker presenting it. There aren’t too many folks out there with pre-cons prepped and ready to go. If the bad news hits two months before the event, you can likely switch topics easily, because few folks register for these things that far out. If you find out the day before, you’re toast. Canceling a pre-con has serious time, scheduling, effort, and financial costs to rolling it back. Depending on how late the cancelation happens, there will be costs that must still be paid, such as location fees, catering reservations, and printing. Once all the refunds go out, a cash-strapped event team can quickly go into the red. That money has to come from somewhere, and that somewhere is somebody’s pocket.
3. The money may not be that great. Factoring all of the costs (location, catering, travel, printing, processing fees), what’s left may be a rather small number. I ran my first pre-con in a hotel conference room near the SQL Saturday location. They required that I use their catering service. I ate their lunch and they ate mine. Outside of booking a marquis speaker (noted authors and lecturers who could show up at any time and fill a room), any geographic area has a limited pool of people who would attend. In my experience (as a non-marquis speaker), pre-cons tend to attract 5%-10% of the number of people the Saturday event does. I’ve seen an event do way better than that, but they started their marketing early and invited speakers who were either nationally recognized or had spoken in that location several times and had decent name recognition.
Despite the downsides, events that have hosted pre-cons usually do so again the following year. It would seem that those who have been through it see the benefits outweighing the costs.
If you’re still reading, I hope that means I haven’t scared you off yet. Great! Let’s get into specifics.
As an event planner, there are a number of questions to answer up front. You’ll recognize some of these questions from when you started planning your SQL Saturday, but you get to ask them all over again.
What topic(s) shall we host? Just like planning event tracks for the main event, you have a variety of options for pre-cons. Instead of drawing more people to the event, overlapping topics generally just compete for attendees out of the same pool. Keep it simple and spread it out – something BI and something DBA is a good place to start. The first time you have pre-cons at your event, you may also want to limit your speaker choices to people who have a reputation for pulling off a successful class. Picking pre-con speakers usually doesn’t go through the normal Call for Speakers process. Networking at other PASS events is a popular avenue – if you would like a particular speaker to present on a certain topic, just ask them. I wrote one of my pre-cons specifically because I was asked to present on that topic, and I’m writing another one for that same reason. Other than that, you can put a note on your event page on SQLSaturday.com that you’re having a pre-con call for speakers, and those interested should email details. Some events have even established guidelines for submitting pre-con abstracts, which is a good idea if you’re opening up the process to the community at-large. These guidelines include such items as having presented at a minimum number of events, having already run a successful pre-con, or being a certified trainer with a minimum number of full-day classes taught.
Where can we host it? This is the same process as picking a location for your main event, but there are some twists. First, the place you got cheap for Saturday may not be available on Friday, or the price may jump a lot. However, because each class takes a full day, you can host two pre-cons in two different locations. Hotel conference rooms work well, especially if it’s the event’s recommended hotel, and can usually be had for a decent rate. Beware their rules about bringing in food, though. You must also check on a projector and screen for the room. These may incur an additional cost.
What about catering? As you’re planning for a much smaller audience, your options here open up a lot. The key is finding an event location that will let you bring food and beverages in, or will provide catering at a decent rate. Be warned about hotel catering: the price you get quoted won’t include mandatory gratuity and hotel/tourism taxes that easily add 35% or more to that number. The two main goals here are keeping it under $30 per person and finding a place with the shortest lead time, so you can leave registration open as long as possible. Just like the main event, look for food that won’t put everyone to sleep after lunch. Be prepared for vegetarian and gluten-free requests. Along those lines: Will there be breakfast food? How about an afternoon snack? Even if you’re not running pre-cons to make money, catering is the primary factor in calculating the break-even point.
Determining the location and catering will get you two important numbers: fixed cost (location, projector) and per-attendee cost (food and beverages). You’ll need those for the next set of questions.
What shall we charge? What is the minimum number of registrations needed to run the event? What is the no/no-go date? These questions all work together. The usual charge is in the $99-$125 range, with $99 being the ‘early-bird’ rate, and enough of a bump after that to encourage folks to register with it, but still keeping the standard rate low enough so folks who missed the early-bird rate will still register at the higher rate. In my experience, at least 30% of SQL Saturday pre-con attendees register during the final week. The early-bird rate is to encourage folks to register early enough that you can look at the count leading up to the event, compare it to the fixed and per-student costs, and decide if that pre-con should be canceled. Be sure to factor in 30% additional registrations for the late crowd – more if you’re making this decision more than two weeks before your cutoff date. Unless you’re running one of the rare events that’s over-sponsored and you’re trying to burn money off, don’t lose money running pre-cons. That cash is better spent on your main event.
What’s the event/speaker split? It’s customary to split what’s left over with the speaker. The split point varies by location and event budget.
How shall we handle registration? EventBrite (www.eventbrite.com) is pretty much what everyone uses for SQLSaturday pre-con registration, for a few good reasons:
- Free to sign up for an account and set up an event. EventBrite makes their money on a per-ticket fee.
- Includes registration website with a custom URL (whateveryouwant.eventbrite.com)
- For a small per-ticket fee, they handle credit cards.
- Site visit reports, attendee lists, etc., including an iPhone app for signing people in. It scans the barcode on the tickets it emails to attendees and checks them in.
- Several ticketing and pricing options, such as creating discount codes, 3-for-2 and other bulk options, changing prices over time for ‘early bird’ specials, etc. It’s pretty easy to set all that up, including having it automatically switch from early-bird to standard rate at a set time.
- Refunds may be processed with just a few clicks.
- Here are a few example EventBrite sites from pre-cons I’ve run in the past:
The big drawback to EventBrite is that they will not pay the registration money out until one week after the event. That makes it a little hard to spend that money on your SQL Saturday. I have some ideas for getting around this, but I’m going to run it past some folks first and blog about it later. Update: They now have a PayPal option that eliminates the wait. Very cool. Hat tip to Adam Machanic (@AdamMachanic) for the tip.
Anyway, just use EventBrite.
Decisions to make before setting up the registration through EventBrite:
1. Who controls the site? AFter the event, EventBrite will either PayPal, direct-deposit, or mail a check for the funds to the account/person specified. This is usually controlled by the SQLSaturday organizers. The expenses for the event are generally paid by the SQLSat team or by the pre-con speaker. Whoever is doing most of the setup and paying deposits generally runs the registration and pays the split minus expenses to the other party. The party handling room and food arrangements usually needs more accurate counts. I’ve had it both ways – three times with the event team running the site and mailing me a check after the payout, and twice where I did everything including booking the room and arranging catering, so I ran the site. In order to get paid, you need to enter PayPal account or bank account info for the transfer. That detail means you likely won’t want to share login and control of the registration site.
2. When will registration be cut off? Arranging food and printing has lead times. Don’t allow registrations to come in after a firm number has been sent to catering. This is a delicate balance if printing is involved. Not everyone prints books for their pre-cons, so that’s often not a concern. I discuss printing in part 2 of this post, which is for speakers.
3. What is the maximum class size? This number varies by the size of the room in which each pre-con will be held and individual speaker’s personal preferences.
4. Will there be an early-bird deal? This often takes the form of $99/seat until 2 weeks before the event, $125 after that, or something to that effect. That encourages people to get their registrations in early. Early registrations are the key to deciding if you need to cancel the event, so success requires a good percentage of attendees to get registered before the critical ‘go/no-go’ date. In other words, the answer to this question is “yes”.
5. What will the refund policy be? Registrants won’t have an automatic ‘cancel and refund’ option. It’s handled by them emailing the organizer, who will go to the website and grant a refund. Refund options make people more comfortable registering earlier. I’d suggest something to the effect of 100% refund up to 3 weeks before the event, 50% for the next two weeks, then no refund in the final week. Because it’s not part of the user options, spell this out clearly with the event description text.
6. Who pays the fees? There are two separate EventBrite fees of a couple dollars each per ticket: the EventBrite fee and a credit card fee. Either or both of these fees may be paid by the organizer, cutting into the payout, or by the registrant, raising the amount paid to attend. Most SQLSat pre-cons pass both on to the registrant, but I’ve eaten the EventBrite fee and had the registrant cover the credit card fee.
7. When does the party receiving the EventBrite payout pay the other party their end of the split? When and how will the funds recipient pay out, and how much expense documentation should go with it to justify the amount paid (or will it just be a raw split)?
8. Would the presenter like to have attendees take a survey during registration? That’s an easy thing to do. For example, before my pre-con in Chicago, I asked attendees how long they had been DBAs, how long they had been working with SQL Server, their primary roles (DBA, developer, etc.), did they have any special dietary requirements like gluten-free, and so on, and I got a full report of that with the attendee list.
At least the EventBrite website is easy to use.
Total time commit to set everything up and maintain it is about an hour initially and maybe an hour over time.
If you made it this far through this FAQ, I’m guessing you’re still interested in hosting a pre-con at your event. Please feel free to hit me up on Twitter (I’m @eddiew), I’d be glad to answer questions and help your pre-cons be successful. I’d also like to interest you in one of my DBA or performance pre-cons if you haven’t already picked your speakers.
If you’re a speaker interested in writing a pre-con, check back soon for part 2 of this post.
Link to the zip file here: SQLSAT122 – Waits Precon
The next Louisville SQL Saturday will be held on Saturday, July 21. (Full details here) This time, the event planners have added FOUR full-day pre-conference seminars on Friday, July 20:
- A Deep-Dive Into Waits-Based Performance Tuning by Eddie Wuerch
- Leadership Skills for IT Professional – Kevin Kline MVP
- Practical Self Service BI With PowerPivot – by Bill Pearson – MVP
- SSIS – Live it, love it, Learn it – by Dave Fackler
These seminars are only $99 – a heck of a deal for a full day of training.
A Day of Waits
My seminar is basically the full-day version of the “Find Performance Problems by Reading the Waits” session I’ve run at several SQL Saturdays and last year’s SQL Rally. The most-frequent comment I received was that the session should be much longer so I could dig into the different wait types, provide more detail, and demonstrate examples of them occurring and different fixes for them. I always felt that myself, and I’m thrilled for the opportunity to spend a whole day on this.
So, with a whole day, what will be covered?
The Waits and Queues Method
We’ll start here, with an overview of Waits in general, and go over different ways of capturing Wait info, including new ways of going about it in SQL 2012. The seminar won’t be too 2012-specific; most of what will be covered is applicable to SQL 2005, 2008, and 2012. If you’re not using this approach to tune performance, then you’re flying blind. If you’ve looked at Activity Monitor and seen all those crazy codes like CXPACKET, PAGEIOLATCH_SH, LCK_M_IX, ASYNC_NETWORK_IO, WRITELOG, SLEEP_BPOOL_FLUSH, and so on, and wondered what they mean and what to do with that info, then this seminar is for you. Those cryptic codes are the key to finding and resolving performance issues with the least amount of effort.
We’ll also cover ways of examining disk I/O and CPU usage information, as these are also important to performance tuning.
On to the Waits!
The bulk of the day will be spent running through a long list of wait types, spending much more time than in the short session. For each of them, I’ll dig into what they are and what causes them. In most cases, I’ll have sample code so we can see them in action. Then we’ll fix the code/configuration/whatever is broken to eliminate the wait.
What You’ll Take with You
When you’ll leave this seminar, you’ll have:
- Scripts you can begin using immediately to start solving problems
- Scripts for setting up base lining and monitoring, and scripts to analyze the results
- A book with all of the information covered, that can be used to assist in performance troubleshooting
- Some new tricks in your trick bag for quickly and easily solving problems
Hope to see you in July!
Whoop! Just a few weeks to go until the next SQL Saturday in Chicago. If you haven’t signed up yet, you can do so and get all the details (including info on two different full-day pre-cons!) here.
I’m presenting, but in a first for me at a SQL Saturday, I won’t be presenting a technical session. Gonna be weird talking at a SQL Server conference without blathering on about latches. Although my session won’t be technical, it will be on a topic about which I’m rather passionate: building and delivering technical sessions. It’s in the last time slot (4pm), and I’m up against some great speakers with terrific topics who are presenting at the same time, but I’m still rather excited to be presenting this topic.
The session is called “Join Us! Getting Started as a Technical Speaker”. The target audience is folks who have either never given a public presentation, or have done one or two and are looking for additional tips from someone who’s done a lot of these and actually been through a fair degree of training on the matter. Or folks who have already seen the other stuff going on at the same time and wondering how long I last before I say “latch”. (I hear the current line is 17 minutes)
Here’s the pitch: have you ever watched a speaker at a user group or tech conference (such as SQL Saturday) and thought, “Hey! I can do that!”? Well, it’s not for everyone, but if you have the itch, I really want to encourage you to scratch it. Speaking is a blast. It’s rock and roll for nerds. And just like picking up an instrument and writing a song, although you could sit down and learn it all yourself, you’ll save a lot of time and effort, and get better results, if you take some advice from those who have gone before you. That’s where I come in. There’s a big difference between practicing in your room (or coding at your desk) and getting on stage.
I should warn you up front: getting more involved in the SQL Server community and presenting at technical events are both very addicting. In both cases, you’ll find a lot of folks who are very welcoming and way more than happy to help you get started. You may get stuck doing a duet of show tunes at a karaoke dive, but, hey, Jäger.
Here are some of the things I’m going to cover:
- Finding a venue to get started
- Picking a winning topic
- Writing a killer abstract
- Building your chart-topping presentation
- Preparation (practice, practice, practice!)
- Warm-up and pre-flight
- Nailing the presentation
BTW, never miss a chance to network or spend some time getting out of your shell and getting in front of a crowd. Even if you don’t attend my session (seriously, there’s some awesome sessions also going on in that time slot), don’t miss the afterparty. We’ve been promised #sqlkaraoke…
I hope to see you in Chicago on May 19!
Since my earlier rant kicked up a little dust, I feel I should follow up.
First, I was pleasantly surprised by the number of comments I received on Twitter. Some folks commented that they couldn’t leave a comment on the blog post itself. While that would have greatly enhanced the conversation, I’m fine with that. The last time I enabled comments, the site was overrun with spam posts.
Jen McCown (Blog) took the time to blog a full reply, which I appreciate. She offered some solutions to my problem of what to do about multiple events on the same day, with the same Call for Speakers cutoff date. This one really caught my eye:
“Better yet, is there anything wrong with getting a feel for the likelyhood of your being accepted? Meaning: Just ask.”
Well, there you go. That’s why I’m glad I blogged about it, and another reason the SQL community rocks. This simple solution was evading me. The weekend about which I was complaining has three events to which I’m basically nobody, except maybe as the guy who keeps singing “Piano Man” at Bush Gardens, and I’m kinda hoping they don’t make the connection on that one. Once I knock the idea around a little longer and whittle it down to two of the events, it will be time to make an introduction. Still it seems a little odd to tell folks right up front I’m on the fence about their event, especially given the voracity of one of the comments that follows Jen’s post.
As to the other points:
“What’s more, once a SQLSat’s call for speakers has gone on a little while, ask the organizers what kinds of session submissions they’re lacking. If you have more than one kind of session, you can be a real lifesaver to a planning committee that’s overrun with sessions of type A, and scraping the barrel for type B.“
That one plays well into one of those useful life rules: get outside your comfort zone. Ask me to talk about a variety of performance topics and I’ll just grab the presentation and run with it. If I don’t have one ready that I’ve already given at a user group or SQL Saturday, I’ll likely be able to have a serviceable session together in 10-15 hours, prepped and rehearsed. Ask me to talk about replication or XEvents or other things that I’ve done but by no means consider myself ‘presentation ready’, and you’ve dropped a challenge into my lap that will require a lot of research and preparation. There’s no way I could get out of it without learning new things, which is cool. Something I say to folks when encouraging them to start speaking: If you think you’re good at something, offer to speak to a room full of strangers about it. If you have any dignity whatsoever, you’ll spend a lot of time getting even better. Of course, that’s only for things I’d actually care to learn – it’s best to not ask me to do an hour on LINQ, nHibernate, or Entity Framework. I doubt a session titled “What the F*** Is Wrong with You People?” would go over well…
And the other suggestion:
“Solution 1: Pick another weekend. […]Eddie gave the example of four SQL Saturdays on one weekend. Couldn’t you submit to the most likely of those, and if it falls through, submit to another later in the year?“
Well, I’m going to do that anyway I go to a lot of these events. Last year, I spoke at nine SQL Saturdays, running pre-cons at two of them, and SQLRally. This year’s goals are 11 SQL Saturdays, running at least two pre-cons, and a slot at the Summit. This is both my hobby and a potentially important step for my career, but it’s primarily my hobby. I’ve made so many new friends and have so many great memories as a result of getting hooked on speaking that I don’t plan on stopping anytime soon. In fact, shortly after that weekend is a different type of the same problem. September 15 has at least three events in new locations for me; lots of new people to meet. But two weeks later, September 29, has two events in the U.S. (Orlando and Minneapolis), and I’m torn between them for the opposite reason – I know a lot of people at both of them, some quite well, from several events. Whereas September 15 is a strategic decision, September 29 is a personal one. For September 15, I’m choosing which event would be best for me to try and attend. For September 29, I’m choosing which one I will least regret missing, because I really want to go to both. Big difference. I’ll eventually pick one and submit abstracts. I’m reasonably confident that I’ll get picked up for at least one session. If I don’t then it will be too late for a slot at the other one, so I’d likely attend anyway, volunteer for other tasks, and let the planners know I’m ready to pinch-hit if there are any speaker cancelations.
My post was rather one-sided from the speaker perspective; Pam Shaw provides a great reply from the event-planner perspective.
To wrap it all up, I’d like to restate that I’ve never double-submitted, and have no intention of doing so. I needed to do a little thinking out loud – a personal blog post about a professional topic.
After losing everything in my blog, it’s good to finally post something again.
There’s a current debate happening on Twitter (well, I think it’s already done), and my take on it won’t fit in 140 characters, especially after including the @handles of everyone I’m copying. Thought I’d just blog a larger comment.
The debate centers around speakers submitting abstracts to multiple events that occur on the same day. These are in-person events; one person cannot speak at two SQL Saturdays on the same day.
There are a number of things affecting this from all sides:
- SQL Saturday is a terrific event, and its popularity continues to grow. As a result, multiple cities will host this event on the same day (I’m looking at you, September 15).
- Speaking at these events is a blast. Meeting everyone at these events is a blast. Getting felt up by the TSA sucks, but, hey, #firstworldproblems.
- Planning and running a SQL Saturday is a LOT of work. Selecting sessions from all the abstracts and building an event schedule that provides a rewarding day for a variety of attendees is hard, time-consuming work. After going through that, getting snubbed by a speaker is a real kick in the shorts. It’s not just a matter of grabbing another session to fill the hole – if you specifically picked a session to ensure a topic was included (say, a new SQL 2012 feature), and balanced the other sessions on the schedule for that, then your pool of available non-selected abstracts gets very small.
- Nobody likes to be told they weren’t the first choice, either as a planner or a speaker.
Having been both a speaker and planner, I get it.
Here’s my take as a speaker:
First, I’d like to say I’ve never submitted sessions for more than on event on any given weekend. I just can’t imagine the shame of writing the “thanks for picking me, but I’d rather go to the SQLSat in another city” email, should I get picked to speak in multiple places on the same day. I fear that day may be coming. I was passed over for the first two events to which I submitted in 2012. I don’t know why, but I can guess there were some good reasons for that:
- I’m far from a first-time speaker. One of the stated goals of SQL Saturday is to grow the speaker community, encouraging local new speakers to step up and get involved.
- I’m also still a regional speaker – there are places with people that know me and lots of folks will attend my sessions, but I’m just another name in many others. There’s no eval-reporting system in SQL Saturday. Many event planners have no idea how I perform as a speaker. Why should they roll the dice on me? (This is not a complaint about a lack of a centralized eval system – that would be a massive undertaking) Both of those events were in locations where I have never spoken.
- I’m not an MVP. I doubt I’ll be one anytime soon. I’m a production performance DBA for a very large, very busy system. Meetings and work preclude me from paying too much attention to #sqlhelp and message boards during the day. My community involvement is rather limited to speaking on the weekends.
While I enjoy repeating at locations where I have spoken, I’m still trying to build up my personal brand. I want to speak at the Summit. As becoming an MVP is unlikely, I see my only options are to keep building my cred or put dick jokes in my session titles. I’m sticking with the former.
Enough preamble, let’s get back to the original conversation: speakers submitting to multiple simultaneous SQL Saturdays. Here’s an example of my dilemma as a speaker: September 15. There are three, possibly four events that day:
- St. Louis, MO
- Providence, RI
- San Diego, CA
- Austin, TX (still listed as a proposed date)
I have spoken in none of these cities. They all are compelling locations – I can’t decide which is better – St. Louis is closest and I’ve met some of the folks at other events, I haven’t presented in New England or Texas, and San Diego will let me catch up with the folks I met at the Huntington Beach SQLSat and continue presenting in that area. That’s four events I’d like to attend. Good kind of problem to have but I still need to decide. The three that are officially on the schedule all have the same closing date for the Call for Speakers, making it impossible to try to hit one, and then shoot for another if I don’t get picked.
So what do I do about September 15? I have three choices:
- Pick one, submit abstracts to it, and stick to it. If I don’t get picked, I’m SOL for the weekend. By the time that event notifies me I’m not picked, it’s too late to apply anywhere else.
- Submit abstracts to multiple events. If I get picked at more than one of them, I’ll have to pick one of them and trash my reputation with the rest.
- Pass on the whole mess, book a flight to Mexico, and read the tweets on a beach with a beer.
Item #3 looks pretty good, actually.
This conversation was triggered by event planners asking speakers to cancel abstracts at other same-day events. Ballsy, but likely effective. To be fair, should I ever cross the line and double-submit, and you ask me to commit to you, then you damn well better commit to me. You may feel insulted by my submitting elsewhere, but please know that if I applied for your event, then I want to speak at your event. I’m not paid to do this, I’m not even encouraged to do so by my employer, and I cover all the costs myself. I apply nowhere casually. There are very few reasons why I would want to speak at one event over another on the same day – the only one I have right now is choosing Indianapolis over Sacramento because I’m part of the Indy team, and I won’t have to pay for a plane flight. Beyond that, the bigger pulls for me are personal cost and who else will be there.
After griping my way through this blog post I ought to get to a proposal. I can’t come up with an elegant solution, but at least I’d like to pitch something:
It all comes down to the closing date for the Call for Speakers (CFS). The first event on a given weekend that completes all of the paperwork and gets on the schedule as an official event gets the earliest CFS closing date. The next event must pick a CFS some interval behind that, like 7-10 days, to allow time for the first event to complete their selections and notify everyone. Not a great suggestion, not even sure it beats what’s in place now, outside of letting planners know that there will be speakers who simply like to attend SQL Saturdays, and when their events are on the same days as other ones, overlaps will occur.