So this wrap-up took a little longer for me to write than I had hoped; work had piled up a bit post-con, and finals were going on in the class I teach part-time at Gainesville State College. Nonetheless, I’ve been thinking a lot about what happened at the third SQLSaturday for AtlantaMDF, and hopefully this list will help some of the other groups prepping for their event. Before I get started however, you may want to review my life lessons from SQLSaturday 13 and 25. Go ahead; I’ll wait.
Ready? Before I go too much further, I should note that there have already been a lot of write-ups about the event from the speakers; I’ll try to build a list of them below my notes, but I will be borrowing liberally from some of them (particularly Jen McCown’s post at http://midnightdba.itbookworm.com/midnightdba/blog/post/A-MidnightDBA-in-Atlanta-(SQL-Saturday-41).aspx). I’ll try to give credit where credit is due, but in case I overlook someone’s contribution, please feel free to point it out.
Pre-con preparation
Here’s a list of stuff that I could have managed a little better BEFORE the conference began. Again, I don’t think we did anything bad; I just want to improve it for next year.
Committee Work.
This particular SQLSaturday was a new challenge for me; the previous two SQLSaturdays I had done most of the leg work before the conference by myself, and only really accepted volunteers to help on the actual day of the event. That had pluses and minuses; the pluses were that I became very aware of some of the larger issues associated with putting the event on. The minuses were that I was a raving lunatic for several weeks, including the day of the event.
This year, I tried to put together a committee, and there were some different challenges with that; there was a lot of energy among the members of the group, and that led us to do some things that I wouldn’t have normally tried (good thing), but it also meant that we spent a lot of time debating how to do things (not a bad thing; just something to account for in the future). The biggest plus for me was delegation; the week of the event, I actually had a very small list of things to do, and that was wonderful. Other people on the team really stepped up and took care of a lot of issues for me.
I definitely think working with a committee is much better than attempting to do it solo, but I would still recommend that you have a definite committee leader (someone with veto power). If I were to do it all over again, I’d be much more strict about working with a punch list (more on that in a minute); we had a lot of ideas floating around, and unfortunately, most of them were in my own head.
Start legwork earlier.
I’ll admit it; I procrastinated on this event. My divorce wasn’t final until March 8, and I basically didn’t do enough work on this event before that to make it a smooth project. I think it came off well, but we were playing catch-up for the last month. As the project manager, this was solely my fault; I even had several members on the team to act as designated “butt-kickers” for me. I don’t think it would have changed the outcome much, but it would have been less stressful.
Building a better event guide.
As most of you know, the event guide is the key to a good SQLSaturday. I didn’t deviate much from my previous event guide formulas (schedule on the front page, summary of speakers bios and sessions on the following pages, sponsor logo throughout). In hindsight, there are some things I should have done.
- Jen recommended that we have a map of the rooms; we did. It was on the last page of the guide. I should have made it MUCH more obvious because we were dealing with several tracks.
- We (I) decided not to have a keynote session; we were expecting more people than we had room to hold in our largest conference space. I should have taken the time to write out what to expect and where to go. I answered a lot of basic questions over and over again on the day of the event (what do we do with raffle tickets, where are the extra restrooms, etc.).
- I’m not sure if the speaker bio is as relevant to the session attendance as we think; it may be better to have either a separate speaker book OR simply recommend that speakers do their own bios as part of the session. We could have trimmed the book down quite a bit.
How many people are we talking about?
I completely underestimated the response from attendees, speakers, and sponsors. SQLSaturday has been around long enough that I think everyone is on board these days, and we definitely did not lack anything in terms of attendee registrations, speakers, and sponsors. Our biggest challenge was space; I chose to reuse the Microsoft facility in Alpharetta because a) it’s nice, and relatively close to a tech hub in Atlanta, and b) it was free (Microsoft was a Gold sponsor). Again, not a bad decision, but a decision that had consequences; we could only have 250 attendees in the rooms AND we needed to enforce room counts.
Before the event began, we had 250 people on the registration list and almost 100 people on the waiting list at one point. We did this with minimal advertisement, and I think we could have easily hit 500 registered people if we had done more advertisement. What really surprised me was the number of sponsors that responded as well as the number of speakers that submitted. I made the not-so-smart decision to accept most submissions from speakers (I had a few complain about that; suck it up, Kendal); this meant that many submitters were presenting multiple times, and I was trying to evenly distribute 250 people across 7 tracks. To keep the session count high, I decided to add an extra hour to the day (start early, end late). 7 sessions is too many, so next year I’m going to have say NO to more sessions by speakers. However, I still want to encourage new speakers to apply as well as the more established circuit riders; I love Robert Cain and Kevin G. Boles (and they draw crowds), but I still want to hear from Audrey Hammonds and Julie Smith.
Sponsor participation was amazing (we had 14 sponsors; 6 of them a type of Gold), but I have bad news for my sponsors for next year; if we’re going to have to pay for space, our price levels are going to have to go up. We’ll make it reasonable, but I may have to introduce a Platinum level for larger sponsors. The good news is that while the overall cost will go up, we’ll be able to deliver a larger list of attendees to them and a broader reach. In keeping with the comment above about getting started sooner, I plan to talk to a few of my regular sponsors and get their feeling on what was reasonable and what is fair.
The T-shirt.
I had chosen in the past to NOT do an event T-shirt, and Aaron Nelson (one of our committee members) talked me into doing one this time. My past arguments about the shirt included a) I didn’t want to deal with sizes, and b) most people would wear the shirt for 1 time and then it would become a gardening or paint shirt. We couldn’t do anything about sizes, but Aaron and I talked about a couple of different options for the shirt so that it wouldn’t be a typical wear-it-once kind of a thing. We decided to come up with a geek-friendly saying on the front, and a simple advertisement for the event and the local user group (AtlantaMDF). Here’s one of our happy raffle winners at the end of the day wearing the shirt!
Did it work? Dunno; by the end of the day, all of the extra shirts were gone, and that’s unusual for an event of this type. I had a lot of people asking me if they could grab one for a co-worker, or a youth group, and even a math class. For all I know, there’s a family of four out in Dunwoody somewhere doing yardwork in the shirt we designed, but I hope that a least a few of my fellow data geeks will wear them in public or at work and advertise the next SQLSaturday (and AtlantaMDF and PASS).
The Raffle Tickets for In-Session Drawing.
To me, this was one of the best ideas we had for SQLSaturday, and I am definitely going to keep doing it in the future. We decided this year that we were going to do in-session drawings for swag in order to keep the final session as short as possible (all we had to do at the end of the day was draw tickets from our big sponsors). After a lot of debate on how to do this, we finally decided that we would do the following:
- Hand each session attendee a raffle ticket and a speaker evaluation form. The attendee would fill out the speaker eval form, and use the ticket number instead of a name on the form.
- The speakers would draw for prizes from the speaker eval forms, calling out the ticket number for a winner.
The benefits? Fast drawings for prizes, session feedback was confidential, and the speakers got immediate feedback (no tallying necessary). There were some challenges; attendees got confused by the word name on the speaker form, and were unsure what to write. Next year? Do it more like a claim check, with the number already assigned to the individual eval form. I may have to spend a little money on perforated paper, but it should make it go easier.
Day Of The Event
Obviously, there were things we could have done on the day of the event better; we get a little better each year, but there’s always stuff to improve.
Registration
Our registration staff was AMAZING; unfortunately, there wasn’t enough of them. We should have had more than two lines, particularly since we were expecting 250 people + wait list to show up before 8:30 AM. A good formula is probably 100 people per line, with at least 2 hours of registration time. The good news is that our head registrant (Lorra Newton) is thinking about writing an app to help speed up registration next time; we’ll discuss next time.
Sponsor Pit
We had to stuff sponsors into a relatively small area this year in order to make sure they had power; I know that it may have been an inconvenience, but I think it actually helped facilitate conversations. The small space made the sponsor pit look busy, and busy places draw a crowd.
Better Training For Volunteers
Volunteer participation this year was amazing, and we did a better job than last year of pre-organizing the volunteers. I still think we could do better, and we may need to see about making pre-con meetings mandatory for volunteers in exchange for greater rewards (a custom t-shirt, free lunch, something). We were training people on the morning of the event, and there were a few mix-ups (like the aforementioned speaker eval/raffle claim check).
Lunch Tickets
Like the last two events, we charged a lunch fee in order to keep attendance high; when people pay for an event, they tend to show up, even if the event has only a nominal fee. Unfortunately, we don’t do enough to distinguish between the fee for the event (FREE) and the fee for lunch. I think next year, we’ll need to do lunch claim tickets to allow people to not pay for lunch and still come (bring their own or pay at the door). Of course, we’ve used non-payment of lunch fees in the past to help clean up the list before the event, and we’re not doing that anymore; we do, however, need to find ways of verifying that people will come, particularly if we have space limitations.
Session Scheduling
I need to be more sensitive to back-to-back scheduling for speakers; if I’m going to have them go back-to-back, then I need to put them in the same room. Speaker schedules are always a bear; no matter what you do, you’re never going to get it perfect. I think having a tighter schedule will help, but I still need to get better. We did do a pre-conference survey to determine space requirements (large classes vs small classes), and that helped immensely, but I forgot to check for a balance of advanced, beginner, and intermediate classes during each hour of the day (the last hour of the day I had 1 advanced session, and the rest were all beginners; we had a bit of crowding at that point).
Post Con Activities
No doubt about it, I need to set realistic goals for wrapping up the event. I still haven’t sent out sponsor emails, and I’m just now finishing the writeup. I should have delegated some of these activities to volunteers, but simply didn’t. That’s definitely on the list for next year.
There’s also more work to do, but I’ll save it for another post; I need to compile a list of blogs and photos from the event. Hopefully that will come out in the next few days.
SQL Server Hekaton, Microsoft’s new In-Memory table technology being shipped as part of SQL Server 2014, will completely change the way you think about data management. As a DBA, you’ll need to analyze your memory and storage needs completely differently. All Hekaton data is always stored in memory, and the data stored on disk is basically just a REDO log used to regenerate the contents of your memory-optimized tables. In this full-day seminar, Kalen Delaney (a SQL Server MVP for over 20 years) will show you the in-memory architecture for your Hekaton data and indexes, and discuss what gets written to disk during checkpoints, as well as what gets logged. She will explain how the recovery process recreates your Hekaton tables. Finally, she’ll go into detail on just what it is that makes Hekaton so much FASTER! 
In this session you will learn about SQL Server 2008 R2 and SQL Server 2012 performance tuning and optimization. Industry Expert Denny Cherry will guide you through tools and best practices for tuning queries and improving performance within Microsoft SQL Server. This session will guide you through real life performance problems which have been gathered and tuned using industry standard best practices and real world skills. 
The chances are that your organization has a centralized data repository, such as ODS or a data warehouse, but you might not use it to the fullest. Join this insightful full-day event to understand the importance of having a semantic layer that bridges users and data. In the Microsoft BI world, BISM consists of Power Pivot, Tabular, and Multidimensional. 
Just a quick note; SQLSaturday is coming back to Atlanta on May 18, 2013. This free (lunch is optional) event usually sells out way in advance, so you may want to 