Update: On November 18th he New York Times published an article on the TelAPI Emergency Response and Preparedness Hackathon that can be found here.
On Saturday, November 10, I was fortunate to have the opportunity to organize a hackathon in New York City. The hackathon’s focus centered upon using telephony to address problems in the context of emergency preparedness and emergency response. It was my nerdy way of doing something to respond to Hurricane Sandy.
We ended up having 25 developers show up and build some really incredible applications. Over the course of 12 hours, five applications were built. The whole event was a great learning experience. Consequently, I wanted to share the most salient lessons I took from organizing the event.
Get momentum early. It’s important for prospective attendees to know that the upcoming hackathon shows promise and is gaining traction early. This helps to legitimize the event.
Within five minutes of solidifying a date and a venue for the hackathon, I reached out to every developer in my network to let them know about it (even if they weren’t located in NYC). I became a salesman of sorts. A message that said, “You definitely don’t want to miss it. We’ll be giving away awesome prizes. Free food and beer! Folks from the media will be here!” did the trick. I even set an arbitrary cap (i.e. 30 people) in hopes that developers would be more inclined to sign up early and avoid the possibility of being left out.
Use Hacker League. If you’re organizing a hackathon, you should definitely consider using Hacker League. I came across HL at a hackathon back in October and was totally blown away. Hacker League is a platform that hackathon organizers can use to create events, and allows prospective participants to sign up for them. It was immensely helpful with sharing logistical information and getting a feel for how the attendance numbers were shaping up.
Use Meetup to recruit participants. I’ve only lived in NYC for two months, so my network of developers in the community is limited. As a result, I turned to Meetup to find developers that might be interested in participating. First, I created my own NYC Telephony API Hacker Meetup group, which quickly amassed 30 developers interested in telephony.
As soon as an individual signed up, I’d email them personally to inform them about the upcoming hackathon. I also reached out to organizers of other related Meetups (e.g. NYC Hacker Hours, Brooklyn Tech/Startups, NYC on Rails, etc.) to see if it was okay for me to email their members about the event. Every single one of them said yes and were more than willing to help me spread the word.
If you’re the event organizer, you’re not a participant. This probably seems obvious to most of you, but it certainly wasn’t to me. I couldn’t help myself. I love hackathons and I really wanted to build something too. I was confident juggling my duties as host/organizer and hacking away on a project wouldn’t be a problem.
I couldn’t have been more wrong. Throughout the entire day, I was getting pulled in all different directions. As soon as I’d sit down to focus on the code I was writing and the tool I was building, I’d have to go take care of something totally unrelated. There was no time to focus, and worst of all, I ended up leaving my teammate high and dry.
It’s OK to say “no.” If you’re the one responsible for organizing a hackathon, a lot of folks are going to make suggestions regarding how the event should run. This is a good thing, however you can’t cater to everyone. Things can quickly spiral out of control and result in a convoluted mess unless you’re willing to say “no” and from time to time. Don’t be afraid to politely decline others’ suggestions and offer to use them for a future event.