September 30, 2013

Lessons Learned On Running A Hackathon

Events
Traceability
Version Control

We just threw our first public hackathon, and as you can imagine, we learned a lot in the process. I'd like to share a few of things we learned, so that you can hopefully use some of our experiences in planning your own event.

1) Have A Hook

A question I ask myself anytime I do something is "who cares?" and setting up a hackathon is no different. If you are building something around a widely known brand then you have a draw right there, but otherwise think about what is going to make your event standout. In our case we were inviting people to come hack on a product that was very new and they would likely not be familiar with, so we held it on the USS Hornet aircraft carrier as a draw. It worked; many of the participants were unfamiliar with the technology but came because of the venue.

2) Tell All The People

It goes without saying that you need to publicize your event, but take advantage of every avenue you can. We were able to get a lot of exposure by working with organizations such as Girl Geeks and Hackbright. We saw that a full half of our attendees found us on EventBrite, so I would highly recommend posting your event there as well.

3) Registered Devs >> Attending Devs

When we announced our hackathon we were blown away by the number of registered developers. We were honestly a little concerned; we had three times as many registrants as we had planned for. On the flip side we knew that pressing a button on a website to say you are attending a free event is way easier than actually showing up.

In the end we hit our original goal, but it was certainly an emotional roller coaster as we saw what our actual attendance was. To deal with this variability you need to get a better idea about the yield of attendees vs no-shows for this demographic.

4) Be flexible

Figure out ways to stay flexible. For example our dinner on the opening night came from a local food truck that delivered pizzas as we needed them every half hour. We also made sure we had drivers on hand if we had to get more drinks or snacks. There's no way to know exactly how many people will show up, so find ways to be able to shift depending on what happens on the day of the event.

5) Bigger isn't always better

When we started getting all the registrants and began to expand our plans to support them, we were extremely excited. "Yes! We're going to reach all the people!" When the world didn't show up we were a bit crestfallen, but honestly our hackathon was better for it. We were able to spend a lot of time engaging with the attendees and helping them learn the technology involved. I think it made for a better experience for us and them. Plus, more beer for the rest of us.

6) Have helpers on hand

If you are going to introduce people to a new technology at your hackathon, even if it isn't the main purpose of the hackathon, make sure you have people on hand to assist. In our case we were using Vagrant with Puppet to setup a development environment. It worked really well but there were a couple steps involved in getting it setup and I was the only real expert on the system. In retrospect I should have realized it wouldn't be entirely turnkey and trained up a couple helpers.

There's also a good chance a lot of your attendees will be college students; they have free time after all. Having people on hand to help them get past some technical hurdles will help them have a better experience. We taught a number of the students how to code in PHP, javascript, and CSS for their first time, and they turned around and used those skills to make cool software.

7) Fun Is Always An Option

One piece of feedback that was consistent in the retrospective was that having a number of short breaks built into the schedule really helped the attendees bond and forced them away from their computers to get some fresh air. We had a coffee truck deliver fresh java at 10pm, root beer and stout floats at midnight, and a MakerBot running from 11 o'clock on to give people ways to take a break from their code while still staying engaged with the event. We also provided wireless headsets with three channels of music. I saw a lot of the attendees bonding over the music and it provided a low energy way for people to engage with the event.

8) Know What The Goal Of Your Event Is and Stay Focused

If you're organizing a hackathon you probably have something you're trying to achieve, whether that be promoting a technology, generating interesting ideas in a particular field, or just giving people a chance to get more coding experience. Whatever your goal is, make sure everything you do is in support of that goal.

For me the success criteria for our hackathon was that every person should walk off the ship feeling that they had learned something and that it had been time well spent. Every decision we made revolved around that criteria. Many hackathons have a few prizes for the top hacks; at ours anyone who put themselves out there and demo'd got a prize. For us minimizing competition and giving people a feeling of success was more important than awarding outstanding work. Even without the carrot of major prizes for the winner, people still did outstanding work.

Organizing a hackathon is no small feat, but I definitely think it is worth the effort. Have you run your own hackathon? What did you learn in the process? I've started a conversation about his on branch. I'd love to hear about your experiences!