By Riley Major, 2017-11-08

Survey Responses

Back in March the PASSMN SQL Server user group published two surveys– one about the user group in general and one specific to SQLSaturday. We sent the survey invites out in emails to our user group members and to attendees of our SQLSaturday in 2016. We’ve received over 100 responses and as promised we’d like to share some insights.

Our initial email to the user group had a good yield, but the follow-up email to previous SQLSaturday attendees was even more fruitful.

We found that respondents are generally serial attendees of our annual event, but the April batch, which we believe came mostly from last year’s attendees, had a greater proportion of one-time attendees. Because these one-timers didn’t respond to the survey we sent to the user group, we suspect that the event didn’t convert these attendees into active members at our monthly meetings. We hope this year’s event convinced more attendees to visit us in the Microsoft offices in the coming months.

(Shockingly, no one chose the cheeky “What’s a SQL Saturday?” response.)

Why not more?

We think that free SQLSaturdays are the best value in Microsoft data platform training, so we’d like to see everyone take advantage of them as often as possible. We asked why folks didn’t attend more often.

We’re pleased to see that almost everyone agrees with us and likes the format and content of these events. We’re dismayed that most of things preventing attendance we can’t change.

Date Conflicts

The biggest attendance blocker was a “date conflict”. That generic text was designed as a euphemism for “I had something I wanted to do more at that time”. Please don’t take that the wrong way; we agree there are plenty of more important things than learning about SQL Server– family vacations, weddings, birthdays, product launches at work, and even other training opportunities or conferences. For most of those situations, there’s nothing we can do. However, sometimes other activities are flexible and just beat us to the calendar. We can work on that. We could publish our selected date earlier. We could even source date possibilities from the community to pick the one with the least conflicts.

This is complicated by our board structure, where the next year’s SQLSaturday coordinator isn’t chosen until that January. Ideally, we’d establish that before the current year’s SQLSaturday so they could be involved in the current year’s event as an apprentice, and we could transition at the closing remarks along with announcing a tentative date. This requires that the SQLSaturday coordinator always be a second year board member, but that’s probably a good thing.

We took some of these steps this year. At SQLSaturday #682, we reserved October 6th, 2018 in the SQLSaturday system, our venue penciled us in, and we announced the date during the closing remarks. We even have a current board member who is interested in running next year’s event if re-elected.

One other way we could mitigate date conflicts is by having more opportunities to attend– that is, have more SQLSaturdays. However, PASS’s official policy is to allow only one SQLSaturday per year per “city” (broadly defined, in our case encompassing the Twin Cities area). We could hold another during the year if it were BI focused, and we could help a another city (e.g. Rochester, Duluth) host, but as a volunteer board, we’re also resource constrained. This is something we’ll be discussing in future years.

Weekends are Personal Time

“I don’t like giving up my weekend.” We hear you. Yes, it’s called SQLSaturday but the truth is it can be on any day. In fact, our first two SQLSaturdays (#58 and #99) were on Friday. One respondent commented “I definitely attended more when it was on Friday”. But consider this from Steve Jones, one of the founders of SQLSaturday:

I’ll say this from having worked on events on weekdays and weekends. A percentage of people won’t get a day off during the week for a free, or paid for, event. […] I have no issue asking people to invest in their careers, but some will, some won’t. Likewise, a group of people won’t come to an event on Saturday. I absolutely appreciate spending time with family, and I certainly make choices about that regularly. I make some events in Denver, skip some, usually because of family.

I have a big problem with employers not providing training opportunities. It’s one thing not to pay for training, but it’s downright insulting to make people use vacation days for taking the fundamental steps be successful in their careers. The value proposition for the business is clear, especially in this tight technical employment environment, and regardless, it’s the right thing to do. So I’d like to see us push back as an industry against this trend. We shouldn’t have to schedule user group meetings during evening family time and conferences on our weekends.

But the reality is, the folks early in their careers– who need training the most– have the least bargaining power with their employer. So having an event on the weekend lets them stay productive at work in the short term, preserve their vacation time for actual vacations, and still build the tools they need move on to a better job.

Plus, it is SQLSaturday after all.

Too far?

So we can’t really do much about the two biggest individual reasons folks can’t attend, but the third is “Too far away”. That we can address. Or can we?

There’s not much differentiation, but the Twin Cities proper seem to have the lead (and importantly the lowest unfavorables). Still, though, there are folks who simply won’t attend if it’s in one of those cities (3 for Minneapolis, 8 for Saint Paul). I get not wanting to fight rush hour traffic and pay for premium parking during the week, but this is a weekend. It’s not that bad. I think I agree with one of our respondents:

Question #3: I find this question odd. The Twin Cities isn’t that big. For a one day, free, conference, are people really that concerned about geographic location?

But regardless, we are disheartened to have disappointed 8 of our respondents, as we selected Saint Paul for this year’s event.

No, really, too far.

One comment cuts to the quick:

out of metro..like Rochester or Mankato or other places

We call ourselves PASSMN — The Minnesota SQL Server User Group. But we are clearly focused on the metro area. Out state options were deliberately excluded from our survey question after we as a board decided we didn’t have the resources to support a SQLSaturday in a more distant locale.

While we’ve worked to set up a chapter in Rochester, that has since fizzled.

I hope that in the future we can better serve greater Minnesota, or help them better serve themselves, but that’s not in the cards for now.

D’oh!

There’s one more area we can help. For those who cited not registering in time or forgetting about it, we will be sure to advertise, remind, cajole, and ensure that we have a large venue with sufficient capacity for everyone to attend. We’re also considering some advertising with other user groups and conferences.

But there’s only so much the board can do. There are 6 of us, but thousands of you. Spread the word!

Venue

We’d love if everyone were as flexible as these respondents:

Don’t really care about the venue, more the presentations.

Seriously, if we can get the space for low enough cost, I don’t care if it’s a tent.

But we believe that the venue does have an impact on the success of an event.

We’ve hosted SQLSaturday at a casino and a church, but one of the benefits of the event being on a weekend is that educational and corporate spaces are more readily available.

For a few years, we had a connection at the University of Minnesota which allowed us reasonably priced access to some classrooms and hallways, and that worked pretty well. But it wasn’t perfect, as we’re reminded by one respondent:

Works best when the event rooms are relatively close. At the U of M it could take close to 10 mins to walk between rooms.

Nonetheless, we think classrooms are the ideal space for the traditional SQLSaturday session and survey respondents agree.

So when we lost economical access to the U of M, we moved to the downtown Minneapolis campus of St. Thomas. It’s a beautiful venue, but expensive. Also, we were a bit spread out, with the sponsors on two different floors.

This year, we chose Saint Paul College next to the Cathedral and not far from the Minnesota State Capitol in Saint Paul.

After this event, we hope everyone agrees with this respondent:

Technical College Campuses are “Perfect!”

Yammering on…

Historically, I remember most SQLSaturday time slots being 75 minutes, but we’ve noticed a trend of 60 minutes, which is what we chose last year.

I personally believe that the traditional session format is a better fit for a taste of a subject and that long term learning can only take place with far longer sessions (with breaks forcing a head clearing and reloading), paired with hands on work. Therefore, I think longer classroom sessions are wasteful, in the sense that they encourage a depth of coverage which won’t be retained. Better to get some exposure to more concepts than try to learn something deeply with a traditional session length. So I would support shorter sessions of 30-45 minutes. But the community has spoken:

(Apologies for calling the 75 minutes a “deep dive”. In retrospect, I agree with the respondent who said “Question #5: The extra 15 minutes (75-60) is not a differentiation for ‘normal’ talk versus a deep dive.”)

While the 75-minute option was most favored, we chose 60 minute slots for SQLSaturday #682, in order to fit in a sponsor session and more networking time. That time is important.

All talks, no interaction?

If all you were doing was sitting in a room listening to someone speak, there would be no reason for everyone to physically gather in one place. Just watch some training videos and call it a day. The whole point of the event is to interact with your fellow Microsoft data platform professionals. We think this respondent put it well:

I’m really sad that more people don’t [take] advantage of the after-even[t] gatherings. Seeing sessions by great presenters is amazing, but getting to chat with them over beers is AMAZING.

The survey stats bear out that lack of appreciation for after parties.

While traditional sessions are the clear favorite, we’re pleased to see the recognition of the value of talking with your peers.

We must admit surprise that spending time with sponsors was almost as popular as getting prizes. That’s good, as they pay the bills, and the event simply wouldn’t occur without them.

What else?

SQLSaturday events follow a tried-and-true pattern of sessions interspersed with short breaks and a lunch. However, we wanted to focus on building our community by fostering more interpersonal interaction. Our survey asked about a variety of mechanisms to get people talking, such as themed lunch tables, extended breaks for networking, an after party, open spaces, and even a board game night. We were a bit disheartened to see little traction for these ideas. Surprisingly, folks were more interested in hearing from sponsors than each other.

Admittedly, this was discouraging. We scrapped any plans for a board night. However, an after party is a SQLSaturday tradition, so we decided to preserve it.

Also, while respondents weren’t interested in extended networking breaks, they aren’t the only party involved. Sponsors appreciate the extra time to talk with attendees, and sponsorship is what makes these events possible. So we adjusted our plans by reducing the time between sessions and consolidating those savings into an extended afternoon break. That made room for a dedicated time slot for our platinum sponsor in appreciation of their support. Vendor sessions were well regarded in the survey– and the talk was well attended– so everything worked out for the best.

The tepid interest in an “Open Spaces” / Unconference concept threw us off the idea for this year. I’m a big fan of That Conference, which dedicates what seems like a third of their session event space to the concept. And I’ve had a good experience convening a session on local technology user groups and learning from other attendees in a more interactive model than a traditional session. So I think we’ll revisit this in future years. But it only works with willing participants, so we might have to sell the idea before attempting it.

We were not surprised at the strong showing for Paid Pre-Conference Sessions. They have been popular in the past, and they provide welcome additional funds to help improve the main event and make up for any sponsorship shortfalls for meetings during the rest of the year. Some of this year’s set were not as well attended as in years past, but we heard good things from attendees and speakers alike. We’d like to give a big thanks to board member emeritus Paul Timmerman for his organizing assistance.

We haven’t had a proper keynote for a few years, and given how many folks are first time attendees each year, we thought we’d have a sort of introductory session where we explained the event, our group, and PASS. We wanted to jump start some networking and inject some energy into the crowd to get the day started right. It worked.

The Panel Discussion, however, didn’t. Or rather, it didn’t even happen. Despite it being the second rated feature in our survey, basically no one came to the panel. In fairness, it was combined with a single lightning talk (we had 4 and only 3 fit in our slots). When that quick session was done, folks in attendance had no desire to talk to our panel, so the moderator instead gave a condensed version of a talk they had scheduled for later in the day. In fairness to the concept, the panel’s topic might not have been interesting to most attendees. We invited folks to talk with the board about the group and how to get involved. I still like the idea of a panel and they seem to be engaging for audiences, but despite our pleas, no community members came forward to moderate, so we decided to do one as a board. This is something we will likely revisit in the future.

Despite the low interest in our survey, we did set up themed lunch tables– or rather, we brought in experienced speakers in our community to host lunch conversations to get people talking. Unfortunately, they weren’t well attended. That might have been due to their placement at lunch or a general lack of interest. We’ll have to consider whether we want to try this again in the future.

The most requested feature was electronic evaluations. 13% said they were a “must-have”. 71% overall wanted them. Only 6% rejected the idea. And yet. And yet… I’ve been a strong proponent of electronic session evaluations for SQLSaturday events in the past. I think it’s silly that as data professionals– people who aggregate data for a living– we collect feedback in a way that actively frustrates analysis. But the harsh reality is that despite purported attendee interest, and despite us having our noses buried in our screens, and despite being technology professionals, the slight friction of pulling out a device to leave our comments causes participation to plummet. The overriding purpose of session feedback is for speakers to improve. Numerical analysis isn’t what drives that– it’s reading the written comments of attendees, and there would be far fewer of those if they had to be tapped out on a touchscreen. So we decided to ignore the call of these survey results and stick with paper evaluations this year. Some day, I hope they’re no longer necessary, but for now, it’s still the best tool for the job.

Developers, developers, developers!

What a SQLSaturday is able to offer as far as topics is heavily influenced by the sessions which are submitted by potential speakers. This year, despite the strong interest from the community in development topics, we didn’t see many abstracts in the category. It’s a shame, as the event session attendance reflected this survey’s results, and some complained that there weren’t more developer-focused options. Next year, we will consider reviewing abstract submission topic counts against interest evidenced by surveys to see if we should make more targeted appeals to our community of speakers.

We were surprised by the strong interest in Business Intelligence– both in the survey and at the event. Our sponsors had a heavy involvement in the BI space as well. There’s a growing demand for business intelligence content. Perhaps one SQLSaturday isn’t enough for everything.

Another SQL Server Conference?

As we mentioned, we can only have one traditional SQLSaturday per year, and it should probably be on a Saturday. However, based on the growth of data analytics and data science, and this high level of interest in business intelligence topics, maybe the Twin Cities can support an additional BI-focused SQLSaturday. Perhaps we should be partnering more with the Microsoft BI User Group of Minnesota (also PASS-affiliated). There are a variety of other data-related groups in town which might also be open to this opportunity. Expanding our coverage also opens up another pool of potential sponsors. But we only have so many board resources, and we don’t want to undercut our flagship annual event, so we must be careful not to over-extend. This is a topic we’ll explore in the future.

SQLSaturday events are always free. That’s part of what makes them special– their accessibility to anyone willing to put in the time to learn. But what about additional, reasonably-priced, local Microsoft data platform conferences during the week? One of the reasons PASS limits SQLSaturdays is to prevent sponsor overload. But if attendees are paying their own way, sponsorship becomes less important. Other technical ecosystems have paid, weekday conferences in the $250 range (e.g. MidwestPHP and MidwestJS). Perhaps there’s room for a MidwestSQL. But that’s a lot of work and risk, so we have no plans to do anything like that at this time.

What (else) do you think?

Opinions. You’re full of them. And believe it or not, we want to hear them. Tell us what you think in the comments here or by contacting PASSMN.

More Surveys?

Remember we also ran a user group survey and we’ll be also covering those results in a future post.

We also plan to report on the evaluations for this year’s event and any surveys we send to its attendees.

Thanks!

We thank those who filled out this survey and gave us the insights which allowed us to put on a successful event this year. We’re already discussing ideas for next year’s SQLSaturday.