This is going to be a long post; definitely the longest I’ve written in a while, and probably longer than anything I’ve ever written. So long, in fact, that I’ve toyed with the idea of breaking it into separate chunks. However, I decided to keep it as one piece because I felt like someone out there may want to print it out, and I thought it would be easier if it were one post. Before I get too deep with this, I have a few caveats; first, I am not an expert on SQLSaturday, nor am I the authority. I’ve done one, and while I feel like it went well, there is always room for improvement. If you really want to get to know about SQLSaturday, you need to contact Andy Warren and get a copy of his infamous checklists on things to accomplish. I just wanted to write out some of my experiences and ideas in the spirit of sharing. Second, my experiences may not jibe with your experiences, so don’t try to emulate me too closely. I just happened to be in the right place at the right time for a lot of this, and you are probably in a different place (and most certainly a different time).
Anyway, on with the list; first, a little background. SQLSaturday #13 was held April 25, 20009, at the Alpharetta, GA offices of Microsoft. I first started talking about a SQLSaturday in September of 2008, and began actively planning it in January, 2009. I did have a lot of emotional support (and opportunities to bounce ideas around) from the leadership of AtlantaMDF (as well as Andy Warren), but I did most of the logistical legwork myself. I say this not to brag, but so that you understand how it came together. Being the primary planner for this event was helpful to me because it let me understand where I could do better with delegation in the planning stages; I do need to say that on the day of the actual show, I had a huge team of volunteers who went above and beyond anything I could have asked. I may have planned the attack; the volunteers carried it out.
Speaking of that, let’s talk about planning for a SQL Saturday:
1. General principals
One thing I wish I had done a better job of was to keep asking myself the question: “How does this build the local SQL Server community?” I think we had a great event, with great speakers, and great attendance, but if we didn’t build up the community, we wasted a lot of effort on a single day. The point of a SQLSaturday (or any user-driven community development event) is that the local technical community should be built up AFTER the event is over. Connections need to be made, networking should increase, new speakers should be encouraged to grow. We accomplished some of that with SQLSaturday #13 (more on that later), but more could have been done. Ideas include:
- promote the heck out of the sponsoring user group; make sure that every attendee walks away knowing who the user group is, when they meet, where they meet, and how to contact them.
- include Twitter/Facebook/LinkedIn directories as part of the event registration
- have chalk-talks, ask the experts, or coding contests throughout the event to encourage people to share, and not just sit and listen.
2. Delegate, but have a single decision maker
There are several roles that need to be fulfilled, both before the event and during the event; I’ll try to detail some of these, but always remember that you need a single decision maker at the top of the food chain. During the event, when things happen, it’s far better to have someone make a quick (and accurate) decision than it is to try and negotiate or look to find someone who knows how it’s supposed to be handled. In other words, if there’s a question about how prizes should be handled, and your prize master doesn’t know, they should go straight to the top. So here’s my short list of roles, including a description and a time frame for their duties:
Event Coordinator: The event coordinator is the person in charge; they delegate authority to everyone else. They need to be in on the process from the beginning of the planning stages, and they need to be familiar with all of the issues associated with implementing the show. Where is the event going to be? What date will it be? What are you going to serve for lunch? Are you going to have a lunch fee or not?
Sponsor Wrangler: This role is the money role; they’re responsible for two things: 1) find sponsors, and 2) keep the sponsors happy. You keep sponsors happy by making sure that they feel like they’re getting a good value for their sponsorship (ideas on that later). Sponsor Wranglers are also responsible for making sure that the sponsors keep up their responsibilities; your sponsors will have other obligations, and just like you can let something slip if you’re not careful, they can too. Also remember that some sponsors will want to donate goods instead of financial support; it’s up to you to decide if that’s OK, but if you accept goods, the Sponsor Wrangler needs to make sure that those goods arrive in time for the event.
Speaker Wrangler: You gotta have talent for the SQLSaturday, and the Speaker Wrangler role lines that talent up. Make sure you pay attention to point 1 above; you want to bring in enough talent to have a successful show, but you also want to foster community. The Speaker Wrangler needs to seek out a mix of experienced and new talent, as well as try to get local and regional (or even national talent). This role also needs to think about things like the speaker dinner, the speaker shirts, and getting the slides and code from the speakers after the event is over.
Volunteer Wrangler: No matter how many people you have helping you plan the event, you need a small army of volunteers to actually run it. The Volunteer Wrangler needs to coordinate with the Event Coordinator to find people to do things like help set up, stuff event bags, place signage for the event, manage the registration desk, collect feedback forms, and handle prize distributions. I actually had a couple of wonderful volunteers who stepped up the day of the event to handle event registrations and be my prize manager; I told them what I wanted, and they did it.
Note that you can have multiple people fulfilling one or more of these roles; you just need to have these roles fulfilled.
3. Event day issues.
Here’s a list of stuff to think about:
- Always have a health plan. Midway through the first session, a volunteer found me and asked “do we know where the first aid kit is?” I shifted from relief to panic in at lightning speed. Turns out someone had a minor cut, it was really nothing, but I didn’t know where the first aid kit was. You should also know where the local emergency rooms are, as well as the address of the facility in case you have to call 911.
- Pack a tackle box of supplies. You’ll need paper, tape, scissors. You may also want to keep a printer handy in case you need to print badges on the fly.
- Have a plan for non-registered “showups”. See the bit about printing badges on the fly.
- Even with a lunch fee, some people won’t show up. I kept thinking we were gonna have 100% attendance since people ad already paid for this, but we still only pulled about 85%. That’s kind of sad, given that we ha to turn away people from the pre-registration because of fire code. It really meant we needed a larger facility.
- You have to buy lunches for everyone; over-order veggie meals, and figure out something to do with the extras. You can send them home with attendees or donate them to the local fire department. Just have a plan, cause you WILL have leftovers (see the point above about no-shows). Make sure that you have a list of who gets a veggie meal at registration, and stick to that list (some meat-eaters change their mind).
- If you have to change rooms between sessions, make sure you have plenty of time to do so. We had a large room that could be separated into 3 rooms; we had plenty of time to make the change before the lunch speaker, but I didn’t leave enough time after the lunch speaker to change configurations. We made up the time, but something to think about in future events.
- Don’t expect to attend more than 1 session. I like learning, and you probably do to. However, one of the sacrifices of putting on a conference like this is that you don’t really get to attend the conference. Spend your time networking with the speakers and sponsors who aren’t speaking. Hang out with the attendees; just don’t plan on attending too many sessions. DO PICK ONE, however, and go to it. You deserve it.
- Eat well before the conference. You probably won’t have time to do so during the conference, unless you eat BEFORE the lunch break. Our case, sandwiches were delivered at 11:30 for a 12:00 lunch; I should have grabbed one out of the delivery guy’s hand and eaten it then. I tried to eat during the lunch break, but was busy resolving issues.
- Get a room. If you live more than 10 minutes away from the conference location, you probably ought to consider getting a hotel room nearby the night before. Get as much sleep as you can before the conference, because you’re gonna be bone-weary the night after it’s over. I live 30 miles away from where we had our conference, and I almost didn’t make it home without falling asleep.
- Schedule space by the speaker, not the topic. I tried to have smaller rooms for more advanced topics, and leave the larger rooms for beginning topics. I had a popular speaker giving an advanced topic in a small room, and it was overflowing. People like to hear good teachers speak on something even if the topic may be more advanced than the audience.
- Try to fill every block of your schedule with something to do. I had a couple of gaps late in the day because I thought there would be some attrition. I was wrong, and ended up with overloaded sessions.
I think that’s it for now; I’ve still got a lot left to do in the coming days, but I think this should suffice for a write-up for now. If you’re thinking about hosting a SQLSaturday, do it. It’s a great experience, and it’s an incredible way to connect with the database professionals in your area. If I come up with more ideas, I’ll write an addendum to this post.
