This thought was originally written for the Pastry Box Project and has been reposted here.
When I first came across hackathons several years ago, the idea sounded awesome to me. A bunch of people get together, brainstorm ideas, and build wacky or useful stuff over a weekend. I never really accepted the fact that they were in large part geared solely towards developers. I had weird ideas. I had things I could contribute to a team. I was up for navigating the murky waters of prototyping a concept in any way I could, be it code or cardboard. I just… wasn’t a developer at all. I didn’t understand why hackathons didn’t bother trying to get all types of people together. Sure, they’d maybe say they were open to anyone and there’d be the occasional code-literate designer or two in the audience, but that was about it. I remember sneaking in to a Yahoo! Hack Day to work with Leah Culver and Cal Henderson on a hack. All I remember doing is looking for images and resizing them. Not a monumental task, but I got a thrill out of being part of making something. In fact, that’s why I moved to San Francisco from Kansas City in the first place. I wanted to be surrounded by people obsessed with making things rather than just talking about what other people make.
It is those early experiences that motivated me to take great care when I decided to organize my first hack day in 2010: Science Hack Day. Yes, Science Hack Day’s mission is about getting excited and making things with science. But there has always been a semi-secret secondary mission just for me: hacking hackathons. There are a lot of things I don’t like about what I’ll refer to as “generic” hackathons. Honestly, I can rant for hours. The summary of those rants is essentially: Design your event with the shyest person in mind. Always be looking for ways to lower the intimidation factor. It’s about the people, not the prototype. A great event is a diverse event. It’s a Hack Day, not a Mechanical Turk Day. Do not offload your fears, uncertainties and doubts into a bucket of rules and restrictions for attendees.
It’s that last one that I find event organizers have the most trouble with and it is why I wrote this post. When I was organizing my first Science Hack Day, I remember losing a significant amount of sleep as the event date neared. I had organized everything to a T. The event format was set, my co-organizers were in line, we had all the supplies. And yet, as I lay in bed each night, the fear crept in. I realized that while I had perfectly organized everything, I couldn’t control whether anyone would actually want to work with each other. What if they didn’t like each other? What if there were people no one wanted to work with? What if they didn’t know what to do with themselves? I lost a serious amount of sleep over this. It’s at this point that I think organizers pick one of two paths. They either a) drown their freak-out in inventing rules and structures for attendees or b) continue to lose sleep but ultimately take a leap of faith that humans are smart and it’ll all work out just fine. I chose “B”. The event kicked off and later that night as I fell asleep on a hard office floor above the main space, I thought through all the smiles, joy and unbridled creativity taking place underneath me. Like the grinch, my heart grew three sizes that day. I smiled and said to myself: “this is the best thing I’ve ever done”.
I’ve now organized five Science Hack Days in San Francisco and helped instigate people to organize the event in cities around the world. The 45th Science Hack Day just took place last month, and just this year I was in China, Colombia, Madagascar and Mexico to help with the Science Hack Days there. If you’re interested in organizing a Science Hack Day, I’ve created a how-to guide. And if you’re a commercial organization looking to put together a hackathon, do get in touch with me.
Being an event organizer is always a bit terrifying, but it’s how you cope with those fears, uncertainties and doubts that is key to the success of any event. While I’ve written this from the context of organizing a hackathon, I suspect much of this is applicable to a wide range of organizers. Here’s my list of the fears to overcome as an organizer (and the overreactions I frequently see).
The fear of no collaboration
• The ifs: What if no one works with each other? What if they’re too shy to talk to one another? What if everyone just defaults to working on their own?
• The overreactions: Specifying exactly how many people need to be on a team, what types of people need to be on each team, that attendees can only be on one team, and/or how quickly people need to find a team.
• The advice: This was the number one fear that kept me up at night when I organized my first hackathon. Put simply: you need to have faith that humans are smart, awesome and are capable of navigating how to collaborate with one another on their own. That said, there are a number of things you can do as an organizer to make it easier for people to find teams: 1) Have an optional pre-event meetup for attendees to meet each other and the organizers 1-day-to-2-weeks before the event kicks off. This allows people to ask questions, know who the organizers are and meet other attendees ahead of time. 2) Have a shared online space for attendees to toss out ideas and offer to help one another in the weeks leading up to the event. 3) Explicitly tell attendees that it’s okay if they don’t find a team for a while. Encourage them to eavesdrop on conversations. 4) As an organizer: don’t freak out if you don’t see anyone building anything for the first several hours. The stress of “nothing is happening yet” is always visible on your face and in turn it can make those around you stressed. I often have to tell organizers that the second day is like Christmas morning: somehow suddenly there’s a ton of stuff where there was none before! Of course, if you notice a few people aimlessly drifting or on their own, go talk to them about what they’re thinking of doing or who they’d like to work with and then connect them with people you think might be interesting to them.
The fear of no ideas
• The ifs: What if no one knows what to do? What if they don’t know what to make unless I give them a problem to solve? What if they come up with off-topic ideas?
• The overreactions: Creating a list of specific “challenges” that attendees’ hacks need to address. Making the event about a narrow discipline. Only allowing people from a specific industry to attend.
• The advice: Know that everyone has ideas and everyone is creative whether they admit it or not. There are two things I recommend for all events: 1) make it diverse, and 2) make any structures optional. I often see hackathons that are about a very narrow subject and I personally find them to be lacking in the serendipity that makes these events worthwhile in the first place. For instance, people often ask me to do a “space hack day”, which would no doubt be super awesome to geek out with all my fellow space nerds at, but it’d be a monoculture of only people who already identify as space nerds. What I love about Science Hack Day and hackathons in general is getting people to play with things they have no experience with and getting these super unusual collaborations of astrophysicists, fashion designers, web developers, lawyers, writers, Navy officers, etc. Of course, it’s possible to make a specific-topic hackathon a success, but go into it knowing that you’ll need to do significant outreach to make sure you have diverse attendees (e.g. “I know you’re a neuroscientist, but I’d love to have you come work on space stuff for a weekend!”). Also, I’m not opposed to offering challenges altogether – I just think they should be optional suggestions. It breaks my heart to see attendees get super excited about a hackathon and then realize they have to choose from a list of pre-determined challenges to participate. Let your attendees surprise you. Off-topic ideas can and have gone on to make meaningful impacts.
The fear of no incentives
• The ifs: What if no one is motivated to build things for free? What if they don’t take our event seriously?
• The overreactions: Using money, flat screen TVs and other wildly expensive material goods as prizes.
• The advice: While some will say big prizes helps legitimize their event, I would argue that it’s not worth how it changes the feel of the event. Big prizes can change an event that would otherwise be about collaboration and sharing of ideas to an unwelcoming competition where teams shut themselves away from everyone and are more focused on the prize than the journey. In a way, expensive prizes cheapen the work people do. It turns what should otherwise be an intrinsic drive to build things to an extrinsic drive to build what is going to win over everyone else, regardless of personal interest in it.
The fear of no outcomes
• The ifs: What if there aren’t any brag-worthy outputs from this event? What if they’re all one-off projects? What if they don’t solve any real problems?
• The overreactions: Helicopter-parenting the attendees with mentors. Creating specific “challenges” that attendees’ hacks need to address.
• The advice: This is probably the most common fear I encounter in other organizers. It’s often external – feeling the pressure from bosses or other organizations to demonstrate how the event made an impact. People mistakenly believe that what makes an impactful hackathon is the hacks instead of the people. It’s easy to see why this mistake is made: hackathons regularly brag about what products or start-ups got their start at their event, completely overlooking that what really came out of the event was the people, not the product. You’re not going to solve giant issues in a weekend. You’re not. What you will be doing is bringing people together to create sparks for future collaborations and ideas that they wouldn’t have had or acted on otherwise. You’re empowering people to play with things they have zero experience in. You’re giving rise to people who are otherwise overlooked for solving problems. You are showing people that they belong. For some people, a hackathon can be a life-changing event. For others, it’ll just be a fun thing they did one time. But either way, you are changing the relationship people have with a topic area, and in itself, that is changing peoples’ lives for the better.
The fear of no-shows
• The ifs: What if no one shows up because it’s free? What if everyone shows up because it’s free? What if I can’t estimate how many people will show up?
• The overreactions: Charge everyone a small amount of money to attend so that there won’t be many drop-outs and/or don’t overbook the venue in case everyone shows up.
• The advice: I am a die-hard about organizing free events whenever possible. I am always annoyed when events charge an entrance fee and it’s clear that they don’t need the money to run the event – they just are using money to manage attendance. Free events are not easy. It does mean that you can’t precisely estimate the number of people who will show up (though, the same can be said for many paid events). Every event is different, but if you’re organizing an event where anyone can register for free, my best advice is to always double-book. No matter how awesome the venue, how free the food, how convenient the location – always double book. I think why it annoys me so much to see events charge that don’t need to is because the organizer is essentially offloading their problems onto the attendees instead of dealing with the issue themselves. I know it’s harder to estimate attendees if it’s a free event, but that’s your job. Don’t charge people money unless it is 100% necessary for the operation of the event. While $2 or $5 might not seem like much to you, to others it’s a barrier to entry that’s entirely unnecessary.
The fear of no skills
• The ifs: What if non-tech-savvy people show up? What if people feel like they don’t have any skills? What if they don’t have any experience in the subject matter?
• The overreactions: Requiring a specific set of skills or experience to attend.
• The advice: This is where I find organizers showing a lack of creativity. Again, allow attendees to surprise you. It should be your job to think through creative ways almost anyone could contribute. Over the summer, I spoke with an attendee who saw everyone building hardware or coding apps and felt like she had no skills to contribute. I talked with her about how hacks can be anything – they could be a video, or a comic book, or a cardboard prototype, or a WordPress site that manually aggregates things into a useful resource. She ended up creating a video. As an organizer, spend some time to think about how people from all walks of life can create things that might be outside of your focus. Instead of asking the “what if?”, brainstorm on the “what could?”. What could a community manager do to help build a scientific app? What could a neuroscientist and an astrophysicist build together? What could someone without a laptop create? What could a team consisting of no developers use to prototype ideas? My hope is that as an organizer, you’ll be able to dream up many ideas. Prototyping isn’t about specific skills, it’s really just about having the drive to realize a concept in whatever way you can – be it drawing, video, cardboard, websites, apps, hardware, software, wetware or performance art.