How SQLSaturday could be better
I've been to a lot of SQLSaturdays. They are great events to attend – from a community standpoint, from a learning standpoint, and from a speaker growth standpoint. Who could ask for more, right? Great sessions, from passionate speakers willing to both teach and learn, fantastic networking opportunities and lunch. All for free, or at a very low cost – some events need to recover costs and charge $10 for lunch. Still a phenomenal bargain IMHO.
But we all know that these events aren't perfect… there are sometimes failures in process or communication that lead to frustration for attendees, speakers, organizers and volunteers. And most of these failures occur during the period leading up to the event, not on the actual Saturday.
So I have just a few minor suggestions that might help.
Speakers: don't overwhelm the organizers.
I know some of you think you have 10-15 sessions that you could deliver equally well, but all you're doing is making their job harder, and I don't think it benefits anyone. I find it hard to believe that the quality of all 15 would be similar, regardless of how experienced a speaker you may be. Pick your top three or four, and cap your submissions there. If you can't narrow it down because you think all 15 of your sessions are completely awesome, check the list of existing submissions, or contact the organizers to find out the areas where they need more coverage (they are listening at [email protected], where N is the SQLSaturday number, e.g. [email protected]). If it's too early in the submission process, then either wait, or be sure to cull your list closer to (but before) the submission deadline. I'm not in favor of the latter, though, because if you submit 15 sessions but only want to seriously consider 3 or 4, you may have prevented other speakers from submitting their session on a topic too similar to one you didn't intend to present in the first place.
Speakers: don't double book.
While you might like to have a back-up plan, this almost guarantees that you'll have to cancel on one of the events. Since you don't know which event will finalize their list of speakers first, I don't think it's fair to invite two or three girls to the prom, and end up going with the prettiest one who says yes. I suggest you pick the event you're most likely going to be able to attend, and leave your second- and third-place choices for the next time they have an event. Or pick the one with the earliest submission deadline, so that if you don't get selected, you will still have time to submit to your second choice. As above, if you wait instead of submitting five minutes after an event is announced, you can get a good sense of how many sessions and what topics and speakers you're up against (these aren't kept secret, on purpose).
Speakers: cancel promptly.
Even if you don't follow the above two suggestions, have the courtesy to cancel the minute you learn or decide that you won't be able to make the event. The longer the organizers are fooled into believing you're going to make it, the harder it's going to be for them to fill your slot(s). This goes for cancelling your regular attendee registration as well: since you are automatically registered when you submit to speak, if you're not going to be there, you're potentially preventing someone else from attending. I've heard of several cases where speakers cancelled the day of the event, or shortly before, or didn't bother letting the event know at all. Having attendees show up to an empty room with no speaker just downright sucks for everyone. I realize that some cancellations are unavoidable, and I'm not suggesting you should skip a funeral to honor your speaking commitment – but as soon as you know, let them know.
Organizers: don't delay notifications.
Speaker selection should happen as close to the submission deadline as possible. I know of at least one event where speakers changed their travel plans to be sure they would be in a certain city on a Saturday, only to find out much later that they weren't being selected to speak. Letting them know earlier will allow them to change their plans appropriately, whether that means staying home, attending a different SQLSaturday, or maybe even just spending one less night in the hotel because they won't need to be there Friday night for the speaker dinner. Now again, I realize that sometimes you can't control how early all of your speakers will want to book their travel, or exactly when you can get together with the other volunteers to make the final selections. But as much as possible this should be part of the planning process when picking the submission deadline in the first place. I think the selection should have to occur at least one month prior to the event, and in a lot of cases two months would be ideal. This would allow remote speakers that are chosen to book flights and hotel without paying last-minute premiums, and for speakers that are not chosen to make alternate plans.
Organizers: have a healthy balance of local and remote speakers.
Obviously you want to have top-notch speakers for your audience, but at the same time, you want to help groom local talent and propel them in the community (one of the founding goals of SQLSaturday). I don't think there's a way to apply a blanket rule or percentage for this, as different locations have different pools of local talent, but organizers should have some familiarity with their local speaker pool and should be able to ensure that an appropriate mix is selected. In some cases this may mean that you have to decline a better remote speaker, and I'm not suggesting in any way that this job is easy (or that you should always pick lesser experienced speakers with bad abstracts just because they're local), but I think there could be some better effort here.
PASS: minimize the number of events on a single day.
I realize it's impossible to give every event their own dedicated Saturday, but keep in mind that in addition to encouraging double booking by some speakers, and precluding others from attending one city in favor of another, you're also spreading sponsor dollars thin and making it less likely for a sponsor to step up to the level that gets a table and allows them to send a representative or two. If a SQLSaturday doesn't succeed here, the organizers and volunteers might be a little gun-shy about trying next time, and everybody loses. As with a couple of other suggestions here, it is difficult to set a hard and fast rule here – one proposal I heard was to allow only one SQLSaturday within a 350 mile radius, but geography alone is more of an issue for the local speakers and less of an issue for remote speakers and sponsors.
[Edit: In other words, I'm not convinced that a hard-coded mile radius rule, be it 350 or 400 or however many miles, is valid. 350 miles in Massachusetts or D.C. is very different from 350 miles in New Mexico or Montana. I also don't even dream of considering imposing a "no two events shall happen on the same Saturday" rule – even though I tried to make that clear above, it seems my suggestion is still being misinterpreted. I am not trying to indicate that there is some perfect rule that everyone is overlooking. I'm just suggesting that we shouldn't want to see another 5-event SQLSaturday, and should do whatever we can to prevent it from happening.]
PASS: put some policies in writing.
While some of these suggestions could be enforced through code on the SQL Saturday site, I realize that you can't just wave your hands, snap your fingers, and have the code in place. But in the meantime I don't think this should be a barrier to formalizing policies that could eliminate some of these problems. I think most are common courtesy / common sense items that don't need to be technically enforced, but posting some of these policies on the specific event site (or on the main SQLSaturday site) should be enough to help the community police this behavior. If you state, for example, that there is a cap of four sessions per speaker, there is no excuse for speakers to submit more than four, even if the site would still allow them to do so. This can also place some onus on the individual organizers to respond to those speakers and tell them to whittle down their list, or you'll remove all of them. It's a little tougher for organizers to discover that a speaker has submitted to other events as well, but I think both of these examples are things the speaker should be more responsible for anyway. You don't always have to actively *prevent* a behavior to curb it – sometimes people just need to be told how to do something right rather than get slapped every time they do it wrong.
Once again, I will stress that these are not perfect or even directly implementable answers, and I don't have any illusions that these will make SQLSaturday perfect. But I do believe they are areas that have caused some frustration in the past and that deserve further consideration – the sooner, the better.
Great post, Aaron. I have noticed the same few eager beavers submitting tons of sessions to various SQL Saturdays. I've always thought that was a little weird.
You also hit my favorite pet peeve. Having too many events on the same day. I would support the idea of having some more oversight when it goes to assigning the dates for SQL Saturday.
Personally, I would rather have fewer events of a high quality, than more events of a lesser quality.
I think most people can easily figure out which few speakers are habitually submitting 10-15 abstracts to every event. Personally, I think doing that is a little silly. It is pretty much impossible to deliver more than 4-5 sessions in a single eight hour event due to the laws of physics.
Even if you could, why would you want to? Presenting back-to-back sessions gets tiring pretty fast, not to mention that you would be monopolizing the available slots at an event. I would not want to do more than two sessions at a SQLSaturday, and one is perfectly fine.
I would rather have time to talk to other people and watch some other presentations during the day.
Thanks Tim,
The reason I suggested a session limit per speaker is simply because organizers have no idea how to narrow that list down. If someone submits 17 sessions to your SQL Saturday, what confidence level do you have that you could pick *any* four of those sessions, and they'll be presented equally as well as any other four? While you can do this for the PASS summit, there is no way on the SQL Saturday site to indicate whether you've given this presentation before. 16 of the 17 could be ideas you have for sessions that you've never presented and will throw together only if selected.
As for the double-booking, I'm sure many events have still done ok even though certain speakers have had to cancel one. I have heard this complaint from more than one organizer where speakers have cancelled because they liked the other girl better. But my point here was not from the organizer's pain point (I addressed that under cancel promptly), however, but from the speakers and sponsors. The more events that happen on a given day, the more events that a sponsor has to potentially say no to, and the more events that a speaker like me – who flies to most SQL Saturdays – has to turn down. I've already curbed my SQL Saturday attendance significantly this year because I got burned out on it last year and I got a little tired of having to pick. The day with 5 events was the straw, I think.
Aaron, good post, and I agree on most of your points.
Regarding the suggestion that PASS implement rules for a maximum number of events per day, geographical distance, maximum number of submissions per speaker, etc., I'm not very excited about this part. Granted, there are some things that seem to be pain points for more than one SQL Saturday event.
However, I think what we need from PASS is some systematic notifications and potentially constraints, to be defined at a per-event level, that would allow each event's organizers some control over those things. For example, as an event organizer, I might want to permit more than 4 submissions per speaker. I would certainly want to know if a speaker is double-booking him/herself. It would be useful to keep track of speakers who had cancelled. But to set in place those limits globally would be difficult. Who decides on the parameters? Personally I don't want PASS – an organization that does a good job at running large events – being in charge of the constraints of my locally-run, locally-funded small event.
The issue of double booking dates is more difficult. I agree that an arbitrary mileage limit isn't reasonable, for the reasons Aaron stated above. Further, even though this *seems* like a pain point, I haven't heard any complaints from event organizers that they didn't get enough sponsors or speakers simply because another city had booked a SQL Saturday on the same day. Perhaps this is a problem that we eventually grow into, but from my seat I don't see this as a major issue for now.
The bottom line is that the success of SQL Saturday has been in its grass-roots, locally run model. The more ingredients we throw into that recipe, the greater the chance that we disrupt a great thing we've got here.
Excellent stuff, Aaron.
Another personal pet peeve of mine would say…
Speakers: Be Considerate of Organizers
I've witnessed speakers behaving inconsiderately, arrogantly, or cruelly to event organizers. Remember, these people are enthusiastic volunteers, not professional event organizers. And they're doing this for the good of their own community, certainly not to stroke your ego.
(In full honesty, I only ever acted inconsiderately toward a SQL Saturday organizer and despite many apologies, I still feel terrible about it).
"Are there SQLSaturday rules about min/max date offsets from the event date for open/close of speaker submissions?" –> Unless things have changed in the past few months, very shortly after a SQL Saturday goes live on SQLSaturday.com, the call for speakers e-mail seems to automatically go out. The call for speakers automatically is open at that point, and there is a default speaker close date that can be changed. I like your idea about min/max date offsets, even if they are defaults that can be changed. That way, the speaker call doesn't open too early for a city who is planning their event many months out. It, also, gives the event organizers a chance to post on the site more details related to what they are looking for in submissions, before the speaker call is open.
Are there SQLSaturday rules about min/max date offsets from the event date for open/close of speaker submissions? In other words for a given event date the call for speakers should start at x months before and end at y months before, and speaker notifications no more than z days after y? Would that help standardize things by getting both organizers and speakers used to a known schedule? The only variable then becomes the event date itself, and everything else is just an offset from it.
Jonathan, I think you could do an event on $1500, and I'd like to see more people try. Lunch/drinks can be billed to the attendees ($10 or so) and you can skip speaker shirts, a paid for party, etc. I have to say that most of the events in the last year have done more than I expected as a speaker.
Really it ought to be the cost of the venue. Food can be paid for by attendees at a flat rate. Speakers and volunteers can help deliver content, but there was never an intent that they be entitled to more.
Aaron, you raise good points about sponsorship, but I've see so many events get a little lazy and go to the same 5 or 6 sponsors for all events. I'd like to see more local sponsors, maybe with some local companies getting sessions to deliver that teach people, but showcase their technical talents. I'd like to see 5 every weekend in different places, and all survive at different levels.
===
Overall, our intention was to build local events, not nationally sponsored or organized events. We like less rules, more decisions by the people in the cities. The vast majority of people coming to these events don't come to user groups before they go, and they don't get training. I think there's tons of room to do 200 events or more a year. The events have to evolve to not depend on sqlSentry, Red Gate, Quest, Idera, and Confio. They need more local help or partnerships.
Kristin, I already tried to explain above that my point about the 350 mile radius is that it *doesn't* necessarily work. 350 miles in New England is very different than 350 miles in New Mexico.
As for "next year's date," I think if a city hasn't reserved a date, PASS nor anyone else should assume that the date is automatically reserved for the next year. And that's not what I was suggesting either.
PASS has the ability to say no to any SQL Saturday, or to say no to a specific date and suggest they pick another. Therefore PASS can fully enforce the "rule" however they want to interpret it. I'm not trying to suggest that I have the perfect answer for what that rule should be. I'm just trying to suggest that they use better judgment than they have in the past (ref: the 5-event Super SQL Saturday).
If a city wants to pull off their own event and not use the SQL Saturday umbrella, then my suggestion doesn't really apply anyway, right? In fact this whole post is irrelevant for that scenario (although you may still have to deal with speaker submission issues, you may still want to attract remote speakers, and you may still want to hit up non-local sponsors).
You're arguing with me about something that has not been stated in any absolute terms. I'm suggesting that they do better than they did last year on that very crowded Saturday. They may very well have been doing much better all along, in which case I am just reinforcing. I don't want to fight about the specifics or try to defend my opinion – it's merely an opinion that if you put too many SQL Saturdays on the same day, speaker dilution will happen, sponsor dilution will happen, and brand dilution will happen. To what degree? I have absolutely no idea.
"That point was mostly to suggest not repeating the day last year where there were FIVE concurrent events." –> This is a excellent point, but how would this be managed and what kinds of rules would there be for enforcement? For example, if there is a rule where there can't be two SQL Saturdays within 350 miles of each other on the same day, how do you handle a case where a city has been established to hold a SQL Saturday on the same weekend each year, but another city within the 350 miles asks to reserve that date for the following year? Would the already established city get asked if they are planning another SQL Saturday for the same date before the new city got approved?
Even more, if a group has the right regional support, they might still hold a SQL conference without it being a SQL Saturday, especially if it is their first attempt to get together a SQL conference. Oklahoma City very nearly had an Oklahoma City SQL Techfest instead of a SQL Saturday last year. Oklahoma City, a city whose SQL group at the time was not a PASS chapter, had great difficulty last year getting approved to hold a SQL Saturday. PASS (pre-Karla) told us no on having a SQL Saturday twice, even though noone else had a SQL Saturday booked for our preferred date. I don't fully recall what the reasons were, but I believe they were mostly related to us not being a PASS chapter. Given our regional connections, we quickly got a location sponsor, a location booked, a date picked with Steve Jones committed to do a keynote, and a couple of regional speakers willing to speak. Techfests.com, also, was committed to allow us to use the TechFest brand. Eventually, several people outside our chapter talked to key people at PASS and got our event turned into a SQL Saturday. This secondary point is that events may still happen, even if they aren't a SQL Saturday, although in our case if there had been another SQL Saturday in our region on the same date, we would have most likely picked a different date.
Side note: Oklahoma City's chapter became a PASS chapter at last year's SQL Saturday. Karla got that to happen
Kristin, you'll notice that I didn't say never allow multiple events on the same day. That point was mostly to suggest not repeating the day last year where there were FIVE concurrent events. While you may not have any trouble procuring sponsors for your event even though there were others on the same day, are you sure all of the other events on the same day had an equally easy time? Or got as much sponsorship as they could have? Are you sure that holds true for all other Saturdays with concurrent events?
The more events that occur simultaneously, the more difficult choices speakers and sponsors have to make. An attendee or organizer might not notice the difference, as you said you had decent speakers and enough sponsors. But as both a speaker and a sponsor I can assure you that others do notice the difference between two events and five events on any given Saturday. As a speaker, I mentioned this on Twitter yesterday, I've only been to one or two SQL Saturdays that I didn't have to fly to. So geographic proximity is not high priority decision criteria, but that decision gets tougher when I have FIVE choices. As a sponsor, my company is based in Charlotte, and if you think we only get pitched to sponsor the SQL Saturdays that occur in the region (there has only been one in Charlotte), I can assure you this is not the case. When FIVE SQL Saturdays approach us to sponsor their event and they all occur on the same day, it becomes very difficult to say yes to all of them (never mind at the same level). It also becomes increasingly less likely that we can't send a representative to take advantage of that sponsorship – since obviously a sponsor gets a lot more out of being there and interacting with people at their booth than they get from having their logo printed (or not even printed, as has happened to us) on the flimsy bag that gets thrown away by 99% of the attendees.
Now again, I'm not suggesting that there should only be one event on any weekend, which is how most people seem to be interpreting my point. I'm merely suggesting that as SQL Saturdays become more popular and less incremental work for each city, it shouldn't get out of hand. FIVE events on a single day is, IMHO, out of hand, regardless of where they are geographically.
Anyway, it's just an opinion and an observation. I think SQL Saturday can still be successful, can still have multiple events on the same day, but can spread those around enough so there aren't 4 or 5 events on the same day.
"However, I hope a few people keep doing the 250+ events so I can keep going to them." –> So, Grant, will Redgate only send you to events expecting 250+ people? The math doesn't seem to work out on that. Last year Oklahoma City's debut SQL Saturday had 200 attendees. We had 3 tracks. That would provide an average of 67 attendees per track. An 8 track event with 500 attendees, like the Dallas size, would, thus, have an average track attendance of 63 attendees per session. As a result, both events would have about the same number of attendees per session. Of course, there would be less people overall to visit a sponsor booth at the "smaller" SQL Saturday.
On the "smaller" event note. I heard some great feedback about SQL Saturday OKC while at SQL Rally. One speaker even mentioned liking the "smaller" size of event, BUT we weren't on a $1500 budget. Our event cost several more thousand dollars than that. Of course, we were paying for a location that required food to be catered. The facility did a lot of day of work for us, though. With the success from last year, our goal is to have a medium size event this year.
Having been to SQL Saturdays in both OKC and Dallas, I've found both event sizes to be a lot of fun. I agree with most of your post, except the "PASS: minimize the number of events on a single day" section. Omaha had a SQL Saturday the same day as Oklahoma City last year, and that didn't seem to impact our capability to get sponsors. Some couldn't send a rep to the event, but they still sent a prize, raffle tickets to collect contact information, and information about their product to put at a booth. As for speakers, we mostly drew from the Texas speaker crowd, since we had already built relationships with them at prior regional PASS events. They could all easily drive to our event, about 3 hours from Dallas, but Omaha would have been a flight for them. Although they were from Dallas, many of them would be considered national speakers that just happened to live in Dallas. In addition, we had a speaker from Utah fly in because he either had some friends or family in Oklahoma. Thus, he preferred submitting to our event because of his connection to our state. Another speaker went to Omaha because his wife was from there. In the end, both events had a solid set of speakers.
Steve and Aaron, you hit upon something that Karla and I have talked about. Andy W., when he first laid out the original vision of SQL Saturday to me, wanted it like Steve has cited. However, SQL Saturday has morphed. For instance, the original intent included giving new and inexperienced speakers a chance, but there are some SQL Saturdays that choose against this.
I think it goes back to PASS, who owns the brand, defining what SQL Saturday should be and then, like Aaron indicated, putting it down in writing and then enforcing the rules. If you don't want to follow SQL Saturday rules, then you can run your own event, it just can't have the SQL Saturday brand attached to it. That's a fair trade off.
Aaron,
Thanks for the post. As an organizer and a speaker it has been an interesting ride on both sides of the fence. These are points that have been on many of our minds and in our discussions. Thanks for getting it out there for us to comment on.
As an organizer we have been blessed to have a great mix of speakers. We have been able to coordinate with some local things in town and have some great national/international speakers. Some of those people also happen to be local to the region so we somewhat luck out.
Speaker over submission can be a little much but most of the time I noticed that it is done based on a session track. When we look at these we know we are going to pick one or two presentations and pick topics that we feel are missing/lacking from our lineup.
Steve,
From an organizer prospective it would be really difficult to put on an event on that budget. I would be very open to discussing it though. It would probably allow us to put on specialized events and tailor the to different segments like DBA/Dev/BI. I look forward to chatting about it the next time we get to meet up in person.
I realize that SQLSaturdays are considered local events; however, the Portland, OR and Redmond, WA events are intentionally tied to other events that bring in well-known speakers from around the globe. Redmond usually holds it's SQLSaturday in conjunction with the MVP Summit at Microsoft and Portland usually holds theirs immediately preceeding the SQL PASS Summit. This ensures them a very big pool of great speakers.
Some events are quite purposefully not local events.
one piece of advice I often give to new speakers is to only submit the number of abstracts they are comfortable actually doing. I tell them to imagine if all of their abstracts got accepted (has happened to me one time). If you're not comfortable doing more than 2 or 3, submit only 2 or 3.
It seems logical to me. Don't offer to do more than you are actually willing and able to do.
Brian, I agree, the numbers are confusing and I mix them up all the time.
Steve, it might be fine that the *intention* of smaller events is to have more local speakers and sponsors, but the reality is that they still seem to want to have the same caliber of speakers, and they still hit up the national sponsors.
Well written, and most of this is the spirit of what we were intending. I have a few things in a scheduled post, which now I'll amend and link over here.
The one item I'll add on the speaker submissions: if you are trying to decide if you want to attend event x instead of event y, contact the organizers. I am usually invited to many events, but if there's one I want to attend, I'll contact the organizers and ask if they will have me speak. That way I don't submit to more than one ever.
I disagree on the minimize the events per day. If that was the intention, then you'd be limited to 50, or maybe 100 events a year (based on 1-2 per Saturday. Realistically, there are probably 10 weekends a year based on holiday timings that are off limits.
The intention was not to build 300-400 person events that suit national sponsors. Those are good, but we, or at least I, was hoping to see more 100 person events, that are run with budgets of $1000-1500 and include more local sponsors. I'd like to see budget events going that don't try to duplicate a conference. Come together and teach people locally, with more local speakers when you can.
I do agree that the community can police some things.
I'd like to see a shift to Twitter hashtags that give some context to the location of the event. I can't keep up with which event is given which number, so therefore I constantly see tweets for which I have no idea which event is being referenced.
Good stuff, Aaron. I have my own blog post cooking on some of these topics.
What I don't get is if one or two speakers are causing headaches for lots of event, why do organizers continue to reward that behaviour? It just makes it worse for the next event…or next year.
Great post Aaron. I think the concrete piece that all parties should focus on are written speaker submission policies. To date that hasn't been necessary, but now that SQL Saturday has grown to the point where we ahve 3-4 a month, it definitely needs some process around it to make it a better experience for all parties.
Funny, kind of like a startup moving to be an established company. 🙂
Adam, I've recently, just this past week, had the talk with one, and he has agreed to just submit 4 or 5, but then contact the organizer to let them know they have others to choose from. But I don't know who all the others are, but will glady chat with them as well.
Aaron, I think your post was perfectly well said on most all accounts. I think overall more communication needs to be happening, that seems to be the solution to a lot of the recurring issues.
Karla
Excellent post. I agree with all of what you're saying. Funny thing is, I wrote up a little post about SQL Saturday that's going live tomorrow. We agree. I just drill down on one point more.
I think it's inevitable that these things actually shrink. I think from a community standpoint, we're going to see more smaller ones. However, I hope a few people keep doing the 250+ events so I can keep going to them.
The sad part, in my opinion, is that the first three issues are being caused by only one or two people. It's just that those people are doing it so much and so carelessly that they're causing everyone else lots of headaches. Perhaps the easiest solution is for someone to have a chat with them. (Not sure who that someone is.)
"I don't think it's fair to invite two or three girls to the prom, and end up going with the prettiest one who says yes" –> Great, couldn't have said better! 🙂