One of my favorite things about a SQL Saturday event is the speaker room. Sure, there is always some good gossip going on, but you also get to take part in some really good conversations. I’ve heard people talk about doing stuff with SQL Server that I never dreamed would even be possible. And the storytelling that goes on is always fun.
As someone who likes to speak at these events, one of my top priorities was to take care of our speakers. Sure, we had a dinner the night before, and we had a little gift for them in addition to the event shirts. But I wanted to let them know that I appreciated them. Speakers give up a good chunk of their weekend to volunteer at these events. Often times, they do it on their own dime. So I wanted a little treat. I called on the good folks at Sweet Cupcake Bakery in Boston. The cupcakes are both delicious and beautiful. As the day progressed, I spoke to our sponsors and told them that we had cupcakes in the speaker room. I don’t think we threw away any cupcakes.
Don’t be surprised if we do that again next year.
One of the best decisions we made very early on was to enlist the help of Paresh Motiwala to coordinate our volunteers. That man kept me sane.
The backbone of a successful SQL Saturday event is the volunteers. They do everything from picking up the coffee to staffing the registration tables to helping people find the restrooms. And we had an amazing group of volunteers.
Being completely honest here, I’m not sure what Paresh did or how he did this. I just know that he had the list of things that needed to be done, the list of people willing to volunteer, and he made the rest happen. Paresh is a natural leader, and he’s incredibly organized and process driven. Getting him to lead our volunteers is something I hope to do again next year.
There is one thing that I did that I will never regret. I enlisted the help of one of my closest friends, Andrew Mannone. He’s not part of the SQL Server community. That also means he didn’t care about seeing certain speakers, and it meant that he could stay close to the registration desk all day. I introduced him to Paresh, handed him my credit card, some cash and said “Whatever you guys need, just take care of it. Don’t ask. Just do. And get me a receipt.” Those are the friends you know you can count on. And it worked well. Next year, I’d like to get a few more volunteers from outside the community for the registration desk. That will mean our volunteers can sit in on sessions as well.
Hard as this is to believe, the worst part of organizing a SQL Saturday event wasn’t raising money from sponsors. And it wasn’t securing the venue. It wasn’t even the stress of the day of the event. The worst thing was speaker selection. Speaker selection became my own personal hell.
We had an incredible list of sessions from a very amazing pool of speakers. We had locals, MVPs, sponsors, and Microsoftees. How did we narrow several sessions down to the few that would make the final list? How did we strike the right balance of celebrity DBAs with local gems? And how did we get the right mix of beginner sessions and really advanced topics? How did we avoid speakers who might cancel? How do we match the demand of the session with the size of the room? It wasn’t easy.
Our goal was to give our user community the best day of training we could give them. And how do you do that? You turn to your friends. I knew we could count on Tom LaRock (blog|twitter), Adam Machanic (blog|twitter) Grant Fritchey (blog|twitter), and Allan Hirt (blog|twitter). They’re all local, and they’re all MVPs. And I asked Adam Machanic to do our keynote. By starting there, we had a recipe for success.
There were some speakers who submitted that were going to have to travel, and that could conflict with a late season snowstorm, either here in Boston or in Chicago. It seems that every connecting flight goes through Chicago. That made me nervous. So we limited the number of speakers coming in from distant places, which would make it easier to fill in gaps.
And to be honest, we got really lucky. Our event was the weekend before the PASS Business Analytics conference. That meant Peter Myers was flying into the US and offered to speak at our event. We also had Stacia Misner (blog) doing a session with Joey D’Antoni (twitter). We also got lucky that Christina Leo (blog|twitter) had recently just moved to Boston.
We also have an amazing group of local speakers like John Miner, Michael Corey, Paresh Motiwala, and Brandon Leach. They’re what make SQL Saturday events great, being able to use your local talent. These guys give some great sessions! We were also fortunate that the folks at Pragmatic Works, one of our Gold sponsors, submitted in force. We got some great content from Chad Churchwell, Bradley Ball (twitter), and Dan Clark.
I know that I offended a few MVPs who wanted to speak in Boston when we didn’t accept their sessions. It really sucks to turn away an MVP, but we have a ton of them locally. I told them that we were trying to focus on local talent where we could. Most of them understood. Most, but not all.
How did we get it right? I’m not sure we did. We had some big names that didn’t fill big rooms, and we had some local speakers who had standing room only in smaller rooms. I think the lessons learned here are to put sessions in rooms based on the content and not the speaker. And next year, we need to make better use of the schedule builder tool on the SQL Saturday website.
The one thing I KNOW we got right was asking a local big name to do the keynote. Adam Machanic is an amazing speaker, and if he were doing a session on tying your shoes, I would go, just to hear him present. He’s just that good. He gave a killer presentation on the future of database careers, and the feedback we got says that he was one of the best sessions of the day.
If there is any one thing I screwed up with SQL Saturday Boston, it was the coffee. And you never want to mess with someone’s morning joe.
A few days before our event, I called the Dunkin’ Donuts nearest our venue and ordered 20 boxes of Joe and 15 dozen donuts. That was supposed to be enough for our event.
Saturday morning rolled around, and I walked into that Dunkin Donuts to make sure everything was in order. Needless to say, I was beyond shocked and horrified when I learned they didn’t have our order. I called a few more Dunkin’ Donuts locations in the area only to realize that nobody had our order. And to make matters worse, the number of the location I called wasn’t on my phone–I had called in the order from my office phone. With the belief that someone had lost our coffee order, we ordered another 20 boxes of Joe and another 15 dozen donuts.
The whole order wouldn’t be ready for another 30 minutes, so we had our volunteers retrieve what was ready. That’s when my phone rang. It was the Dunkin’ Donuts in Harvard Square, telling me that our coffee and donuts were ready. It turns out I had ordered our coffee from the wrong location! We now had twice the coffee and donuts we needed. We sent another set of volunteers to Harvard Square to get the coffee and donuts.
In the confusion of where we were getting the coffee and donuts, we forgot to send our volunteers back to the Kendall Square location to get the rest of the coffee and donuts we (re)ordered.
In retrospect, it’s kind of funny. And we had a budget contingency for just such emergencies. Somehow, it was a hidden blessing. We had plenty of donuts, and we didn’t throw out a lot of coffee. Lesson learned: Make sure you document which location you get something from. That number will be important later. If that’s the biggest thing we messed up that day, we must have done something right.
Every once in a while, it’s a good idea to step back and take stock of where we are in our careers. What works? What doesn’t? And what isn’t going to scale?
In the environment I manage, we started with about 20 SQL Server instances, and the day I started, I was sent a spreadsheet with instances, ip addresses, and passwords. When we built a new instance, someone would email the updated spreadsheet to the whole team. Clearly that doesn’t scale.
Today, with more than fifty instances and a much larger SQL Server team, we have a SQL Server database that we use to track machines, instances, credentials (now encrypted with certificates) and other critical information. This scales better than the spreadsheet. Our next step is to integrate it with the system we use for our Oracle environments and then integrate with our CMDB. Then we’re going to automate it to know SQL versions, builds, invalid passwords, product versions, etc. THAT will scale.
I’m looking at my own life and realizing that the Cranky DBA name isn’t going to scale for me, either. When I first started talking about SQL Server, nobody knew who I was. Cranky DBA was something people could remember. But will that work for me if I ever want to start my own consulting business? And what if I get my dream job, working as an evangelist for a technology company? Would they want me out there selling their products as the Cranky DBA. Probably not. What do I have that will scale? My name.
Over the past couple years, I’ve started getting my name out there in the SQL Server community, and people know me by name now. Mike Hillwig isn’t a stranger anymore.
If you look at my blog, you’ll see that references to Cranky DBA are starting to disappear. Instead, things are starting to live at mikehillwig.com. This comes along with a new WordPress theme. It needs a little more work, but I think it’s something that will scale better over the next few years.