At PyConLT 2019 (Lithuania) we just had a 10-person meeting on “how to start a new PyData or Python meetup” with existing organisers and some potential new event organisers. The night before in the conference bar Radovan and I had spent an hour helping someone from Latvia figure out their plan to start a new Python meetup. Given that I’m a co-founder for PyDataLondon and after 6 years we’re at 9,500+ members, I have some opinions. Maybe sharing these will help others. All going well we’ll see a new PyDataVilnius start with what looks like a 7+ person volunteer group, all organised at PyConLT.
I’m pretty sure that the key to starting a meetup is to have:
- lots of marketing (I can’t stress this enough – to kick start a new event you have to help relevant people find you)
- regular meetups (e.g. monthly or e.g. every 3 months – whatever fits your community and your level of engagement)
- high quality speakers
- the same venue every month (it is easier for attendees and much easier for the organisers to have a fixed venue)
None of the above are “magic”, they each help. Regular meetups mean people put them into the calendar. High quality speakers mean people get used to turning up because “they’ll either learn something or meet other interesting attendees” – I’m really proud of the quality of speakers we’ve had consistently over 6 years at the PyDataLondon meetups. The same venue means there’s no confusion about how to find you for the attendees and there’s no extra effort for the organisers to have to keep finding and negotiating new venues.
For the first few months keep your life simple – get setup on meetup.com (if you’re doing a PyData you can email NumFOCUS to ask for an official PyData branch to be created) or have a landing page (/blog/mailing list/facebook page). Find a couple of good speakers – ask around, you’ll quickly be surprised at how good your existing network already is. Choose a regular date (PyDataLondon is “the first Tuesday of the month” and we’ve rarely broken that rule). Find yourself a couple of co-organisers – 3 co-organisers is great, 1 is too much of a burden for 1 person I think.
Don’t stress too much about the first venue. You’ll probably grow out of it so you just need a stable base to start from. I’ve run prior meetups out of pub function rooms, renovated Victorian townhouses and co-working spaces. PyDataLondon started at Pivotal (thanks Ian!), then moved to Lyst (thanks Steve!) and then for 3+ years at Man AHL (super thanks Slavi, Gary and colleagues!).
Next – publicise it. Tell all of your friends who’d be even vaguely interested and ask them to tell three friends. Post to Facebook, Twitter, your favourite forums/slack/whatsapp groups. Ask friends in companies or at universities to advertise internally. Go to allied meetups that are already running and ask the organisers if you could have 2 minutes on-stage to announce to their audience (and of course offer to publicise their event to your audience in the future – always reciprocate).
If you’re stuck for speakers – look at the history of speakers at other related meetups and conferences, then reach out to them. Tell your friends that you’d like to reach persons Y and X and maybe they can do you intros.
At each meetup remind everyone that you’re a volunteer groups – so many attendees don’t realise that the organisers & speakers aren’t paid to do this. Remind them that you’re all volunteers giving up your time, ask them to thank the speakers and your colleagues (and maybe to buy them beer or coffee). At the end of the event get your volunteers and speakers to stand and ask everyone to thank them (and maybe buy them a beer in the pub after) – make sure your volunteers are acknowledged. Also remind everyone “we want new speakers – please come and have a chat with the volunteers!” and you’ll develop a feed of people willing to speak for 0 extra effort on your part.
At PyDataLondon we get lots of first-time attendees now (maybe 30% of the room are first-timers now). I’ve taken inspiration from other meetups (e.g. LinuxingInLondon and others) to make the start ‘more friendly’. We have 200 people in the room, many of whom don’t know who they sit next to. We do a 1 minute intro section where “you turn to your neighbour and ask ‘What do you do with Python?’ and then they reciprocate” – so then everyone has someone to talk to in the break. I also get and pass aroud “green newbie badges” – these are stickers that any newbie can stick on themselves, this gives them the super power to go and join any conversation in the breaks. I also get stickers for the speakers & volunteers (robots, unicorns, planets – the London Science Museum is great for these). These techniques work nicely.
Think about your motivations for running a meetup. It takes a lot of sustained effort to make it consistent and then it just takes effort to keep it going. You’ll want to grow an organising group to keep it maintainable. Ask yourself – why do you and your colleagues want to run this group? Make sure you’re all in alignment about your core values, else you may be ignoring issues which might make things weird later. Thankfully the groups I’ve been involved in haven’t “gone weird” but I’ve seen it happen (e.g. founders who won’t let go of the reigns and then burn out), you can sensibly avoid some of these problems by having frank discussions up front.
Later on you may need to scale up your organising group. At PyDataLondon we’ve been blessed with a super feed of lovely volunteers – we run a committee with circa 13 organisers. My earlier meetup “fivepoundapps” was an awful lot of fun but my friend John and I realised after some years that nobody else wanted to run the event – no amount of cake baking (John) and beer carrying (me) would change the feel of the event from “John and Ian’s fivepoundapp” which was a pity. When we burned out it just died. Happy memories, but a pity that it didn’t sustain.
For PyDataLondon I put thought into sustainability and our organisers discussed this as we grew. In the background we have a rotating Release Manager (they check with the venue & speakers, send out a “please unRSVP if you can’t attend” email and do some housekeeping – essential and mostly invisible work), several of us look for new speakers, we used to do a lot of publicity but thankfully that’s mostly automatic now. I write an “update email” most months to our 9k+ members, that takes 1-2 hours to write and includes some links about upcoming relevant events and often requests new speakers. All the volunteers rotate to be on stage, not everyone is comfortable with that (and sadly some of us – myself, Emlyn, Marco – are more comfortable with it than others and we get he limelight) but we try to make sure that all volunteers get some visibility. I don’t know a better way to do this, I’m open to feedback.
You don’t have to start big, you just have to be consistent and it’ll grow sensibly over time. We’re 6 years in now with PyDataLondon and it just seems to keep growing. Build a nice small meetup, let it grow, delegate and find colleagues who want to help it grow and…let it. Beer generally helps (+wine+soft drinks+pizza+suitable alternative food – suit the needs of your audience). A code of conduct is very sensible (NumFOCUS sensibly insist on this for PyData events). Keep telling people. Find high quality speakers. Rinse and repeat. Enjoy the new community. Sometimes I joke that the reason I’ve put in 6 years of effort is, on a personal level, because I couldn’t find 50 interesting folk to come to the pub with me – now I get it for free every month. That’s magic.
Thanks for Radovan of PyDataBratislava, Jan of PyDataPrague, Aidis of PyConLT for direct feedback yesterday, to my colleagues at PyDataLondon and global PyData events and to others who have helped me figure out these approaches over the years.
ps. written at the airport – please excuse any typos!
Ian is a Chief Interim Data Scientist via his Mor Consulting. Sign-up for Data Science tutorials in London and to hear about his data science thoughts and jobs. He lives in London, is walked by his high energy Springer Spaniel and is a consumer of fine coffees.