DataBS-Conf planning updates and how scrappy conferences are made
Last week Data Behind the Scenes Conf (DataBS-Conf) planning took a big step by putting out the call for speaker submissions! If you have a story that even roughly fits the theme we've chosen for the conference, please submit something now because there's honestly a decent chance of acceptance, the mechanics of which I'll explain below.
For this week, a bit of a lesson explaining what goes into putting together a scrappy grass roots conference. I want more people to get a peek at how things work so that if they one day have an idea for a conference that they're excited about, they aren't as intimidated by the execution part of it.
Luckily, DataBS-Conf isn't my first attempt at organizing online fun events. Since 2016 I've run that little annual gamedev conference I occasionally mention for about 100 folks each time. I was on the planning committee/team(?) for Normconf that so many of us data folk loved. I even hosted a session or two of "data rants and drinks" ages ago.
So here's lessons on how to throw together a gathering of people on a topic and not lose your mind (or your bank account) in the process.
First: Gauging Feasibility and Interest
The most important thing about hosting any event, whether it's a conference or a dinner party, is having people attend. The big scary question is figuring out if anyone is actually interested in going?
At a high level, this is a kind of product/market fit question, and people with marketing and sales experience have their ways of figuring this stuff out. I'm a hyper-introverted, neurospicy nerd. I don't have any of that knowledge. So instead, I rely on asking my social network of friends – if a decent number of people who I actually want to spend time with show enthusiasm for the idea of getting together around a topic, enough that I wouldn't mind being in a room with just them, then I probably have enough interest to make something happen.
Personally, if I have a conference of maybe 5-10 of my friends who I know have interesting stories, I'm more than happy to do the work of getting them together. Everyone else who I haven't met and attends to contribute their own stories are a bonus for the effort of making such a space.
Set a Topic/Theme
Next to feasibility, the most important thing to figure out immediately is what the theme of the conference will be. It can be as broad or as niche as you and your circle of friends want it to be. But whatever it is, you absolutely need to be clear about who is, and who isn't in the target audience.
Without clarity for who the conference is for, you can't effectively convince speakers to give you clear proposals because they can't imagine what sort of audience they're going to have. They're not going to know whether to expect field experts, beginners, or laypeople with no context nor training. Most critically, those potential speakers won't get that lightbulb moment of "oh, I know exactly what I want to share!" and so they're much less likely to even submit a talk for consideration.
Same goes for people who don't want to speak but want to attend. They're going to look at the call for speakers also and potentially share it with folks that they know and want to hear talks from. So again, allowing them to know what they are getting into lets them help spread the word.
For DataBS-Conf, a bunch of regular members bounced some ideas of what they wanted, and eventually I proposed a "how data stuff really works" concept that people liked. After a bunch of refining, we landed on what the current call to speakers page has.
Prep the little details
Once you've figured out the theme, next you have to start knocking off a lot of little details before you can call for speakers. In no particular order, here's what we dealt with:
- Date and times of the event – speakers need this for planning if they can even attend, same goes for attendees. You need the time for online events because people across the globe may want to apply but can't if the time zones don't work out. We also made sure not to overlap with other major data conferences.
- Will you be charging money – running conferences is a lot of work and involves spending actual money. Small ones can be done on a shoestring budget of a few hundred dollars, but it's never zero. There's no shame in charging something to spread the cost around. There's pros and cons to doing it either way, but you need to decide this up front so that your messaging is clear throughout the process.
- Allowed formats - How much time will speakers have? 5 minutes? 10? 20? 30? Will you allow single, double speakers? What about panels? Obviously not everyone wants to talk for an hour or 5 minutes. In my experience, 20 minutes is a solid time to get to a good point without letting things drag, 30 minutes is very traditional and works. 15 minutes feels surprisingly awkward, while 5 minutes is doable. I like adding a separate 5 minutes for questions and delay buffer.
- Will there be recordings – this again influences who can/cannot speak. It also has some minor influence on whether people are willing to buy a ticket to attend. For physical conferences, recording/livestreaming costs can be very high due to venue contract requirements, but for online events it's practically free and should be the default expectation unless you have a good reason why there shouldn't be recordings. For example, Data Mishaps Night doesn't do recordings to give speakers a safe space to talk about their failures in public.
- Location and platform – even if it's online, you need to pick a software platform. Usually a webinar platform is best for a conference where a dozen-ish people are speakers with an audience numbering in the hundreds to thousands. For smaller gatherings with flatter setups, a big group meeting where everyone attending can speak is also a possibility. Comparing features and costs is a pain, just write it down in a spreadsheet since you rarely need to purchase a subscription to the software until slightly before the event.
Call for Speakers
This is the first "point of no return" where you publicly ask people to give you their precious attention for more than a second.
Writing these isn't easy! Expect to take a while to refine the text. They tend to be long because you need to tell people a lot of stuff (including all the details from above), but they also have to be easy to read so that people on the internet (who notoriously don't read things) will read them.
Also, make sure it's clear what the timeline will be. When will submissions close? About how long should they expect to hear a decision? People need time to put together their talks and you don't want people to lose interest due to uncertainty.
I also spend time providing example talk ideas because themes are very hard to express clearly, so examples help. My belief is that examples also inspire less confident, newer speakers apply because they're less likely to realize that they have stories other people want to hear.
Still, don't let the perfect get in the way of the good. It's better to have the CFS out sooner than later. Give people a month or so of time to hear about the event, procrastinate a bit, then finally put in a submission at the last minute.
Until the CFS period ends, your primary job is to keep reminding people that you're looking for talk submissions. It's going to feel like you're repeating yourself on social media a lot, but you have to remember that not everyone is terminally online, and any given person is pretty unlikely to see just one random post from you during the day. Repetition is pretty key.
Handle other logistics
While the CFS is out, you enter a bit of a quiet period where you can prep other things... For example:
- Do you have a website?
- If you're charging for tickets (or taking donations) are you prepped to handle that? Also, have you spoken with an accountant if you're handling money?
- If you haven't gotten your team of helpers ready, now's the time
- If you're looking for sponsors, now's the time
- You're probably going to need a code of conduct/moderation policy. These are a pain in the butt to write, even worse to enforce, so best start thinking about it sooner than later.
- What's your process for going through and selecting talks?
Make use of the quiet time! When things get busy again, they get really hectic.
Select the Speakers
This is the hard part. You get a bunch of submissions and have to come up with a method for picking out talks to build the conference. It's not quite as straightforward as "just pick the best ones!". I'm sure if you ask ten people how they would do it, you'd get eleven opinions on how. Here's how I usually do things.
- I take all the talks that are on the spreadsheet and make sure I mark all the entries where the same person submitted multiple talks (I usually allow this). That way, I know that if I accept one talk from that person, I cannot accept a second talk from that person.
- Next, I put the submitted topics onto a separate page, separated from the speaker's name. It's not a perfect way to anonymize entries, but helps prevent me from introducing more unconscious bias into an already biased process.
- I very roughly bin the talk ideas into tiers of "how much I like the talk proposal". Some talks I really want to hear, others I'm more indifferent. Some are outright troll submissions. There's no need to formally stack rank everything, just very roughly separate out the gems.
- Next, I pull up my conference time table spreadsheet (you've made one already right?) and figure out how many people I can put into the event, including breaks and setup times, and everything else.
- Pulling from the bins of talks, I try to build out an actual program for the event. While I want good talks in general, I also want the audience to see a balance of topics. Maybe some talks naturally pair well together and should be put back to back. Sometimes there's too much of one topic to accept another one. There's a lot of delicate juggling and art that goes into it. Go with your gut feeling.
- Finally, contact everyone with the results. I use a form email that I paste details into. Make sure to include the accepted talk title/topic in the acceptance email in case they submitted multiple entries, or just need a reminder. Let them know what they need to do now (usually send in profile info) and what to expect.
- Yes, send out an email to the people who didn't get in too.
Bonus Method: Community Voting for Talks
About three years ago, I experimented with having the community vote on talks for my gamedev conference instead of having me decide alone. While the end results were tended to be almost identical to my own personal preferences, it made the process a lot more transparent. Here's how I tend to do that.
- Once submissions are in, I make a new google sheet that can be viewed publicly.
- On the shared sheet, I put a hash identifier code for every submission, along with provided talk details. The same stuff a reviewer would see.
- I then publish a poll using OpaVote that lets the community submit their preferences via ranked choice voting. It costs some money to use but is one of the few ways to do a complex RCV system.
- Once the poll closes, I use OpaVote's system to run the election, then remove the winner and run another election, until we get a stack ranked list of talks.
- Once duplicate submissions and obvious troll talks are removed, use that to build a program as usual. I do not publish the ballots. People are aware that as the organizer I can step in and add/remove a talk despite the vote results if there's good reason (again, trolls).
Yikes we're already at 2150 words? I'll stop here and get into the big runup to the event another time.
Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.
Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.
"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.
About this newsletter
I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.
All photos/drawings used are taken/created by Randy unless otherwise credited.
- randyau.com — homepage, contact info, etc.
Supporting the newsletter
All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:
- Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
- Send a one time tip (feel free to change the amount)
- Share posts you like with other people!
- Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
- Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!