As someone who frequents a number of user groups and meetups, and who ran one for half a decade, I’ve seen a variety of different methods leveraged by the group leadership to capture community folks (the people who use the product or solution) to come and speak on their experiences. I then realized that this may be somewhat interesting information for those looking to either speak at a user group or find speakers for their own user group. This post will contain some of the good and not-so-good methods to help tickle your brain. I’m also open to other ideas in the comments section that has been working for you.

Limited Scale

I’ll start with some of the legacy methods to find speakers that doesn’t scale well and seems to have limited success. The first culprit is relying upon word of mouth to find someone who is brave enough to come up and pitch a topic. I see this one used a lot because it requires little to zero effort on behalf of the group leadership, placing all of the burden on the potential presenter. The issue is that it requires the person to hunt down the leadership team and shoot ideas into the dark. Even if the member of your group gets that far, a lot of time and confusion results from an email thread as topics, abstracts, and biographies are fleshed out.

Due to the Curse of Knowledge, it can be tough to remember that first time speakers have little experience drafting a session topic and attaching an abstract. They likely have never written a short form biography of themselves, either. It’s in the group’s best interest to lay all of these items out, with descriptive details on what they are used for (plus examples), to help properly guide the contributor. This turns a relatively scary endeavor into something that is more comfortable and exciting!

The other pitfall is a lack of desired subject matter. I often hear a broadcast to the members of a group stating “tell us about anything.” This can result in The Paradox of Choice. All well-run events use some sort of landscape of open topics and issue a Call for Speakers, Call for Proposals, or Call for Papers to review ideas. This helps narrow the choices down to a few major topics that should align with what the group’s members are looking to learn about. The group leadership can (and should) poll a few ideas to see what the members find valuable before building the call to action using the winning ideas.

All of the pain points I’ve covered above are really just about building a process that feeds a workflow. They also sound fairly common sense. Sadly, I stumble upon these scaling issues frequently.

Proactive Leadership

Let’s start by addressing my first concern from the previous section: building a workflow to receive speaker ideas. I’ve worked with a few groups that have this nailed down nicely. The Melbourne VMUG is one of them: they use a Google Form. It asks for all of the pertinent details and is easy to read. It contains links to helpful bits of data. It’s beautiful! And I doubt they would care if you copied it as a starting point for your group – it’s for the community, after all (but still ask). The only thing it’s missing is a list of focus topics to help narrow down the scope of submissions, but the header information is fairly clear about what they want. Honorable mention to the Netherlands VMUG, which I haven’t attended as of yet but had a similar submission process for my community session proposals.

Another idea that I learned the hard way as a leader of the Chicago VMUG is rigorous abstract review. Some groups do this using a blind vote that leaves the speaker details off (to avoid favoritism), others limit their submissions to non product-specific sessions, and others try to mix them together with some sort of lab activity. As long as the requirements are clearly stated as part of the submission process, life should be good. Do keep in mind, however, that it’s perfectly possible for vendors to present on community topics.

I recently attended a Singapore VMUG session on monster VM virtualization presented by Michael Webster that had a lot of neat nerdy details but didn’t mention his company at all (beyond the title slide with speaker info). Be wary, of course, but keep in mind that channel and vendor folks can bring interesting content to the table, too. 🙂

Summary

In conclusion, it’s best to …

1. Build an electronic method for capturing speaker proposals.
2. Narrow your scope to a few major presentation topics (that match member expectations).
3. Issue a call to action for presentations with a clear deadline.
4. Closely review abstracts and notify speakers when they are selected.

Although I point to the VMUG frequently in this guide, it should be relevant to other groups as well (such as the very well run Docker and Chef meetups I attend in Austin). I spend a lot of time at VMUGs (because they are awesome) and have the most amount of experience with their events, hence so many examples. 🙂

Cheers! Again, if you have other pitfalls or proactive ideas to share, please drop them into the comments.