I recently wrote here about the 2014 SoHacks hackathon, and doing so inspired me to do a general write-up on hackathon best practices based on my experience. I hear comments now and then from those involved with developer evangelism that hackathons are a waste of time and money, and I believe this article can help put that broad claim to rest.
For those unfamiliar, hackathons are brief, highly-energized events where makers of various backgrounds are invited to, well, make things. Typically technical things. They're usually two-day events sponsored by tech industry giants and supported by volunteer mentors. Those in which I've participated have seen a rich variety of ages and skills, but I've noticed a trending tendency toward middle and high school participants. The SoHacks event, for example, was comprised entirely of this demographic.
With the background stuff out of the way, we're left with the question looking for an answer: what good are hackathons? How do sponsors and developer evangelists benefit from these occasional one-off experiences? Here are my thoughts:
Go in with appropriate expectations
If you expect every hackathon to launch The Next Big Thing, you may very well be consistently disappointed. Even though I've witnessed some amazing accomplishments during these high-voltage, compressed time frames, typically you'll see a great many more unfinished ideas. There's also a lot of duplicated effort, as teams intentionally or unwittingly select projects that have been tried (and often failed) at other hackathons. Many of the projects can't possibly be completed in the time given, and sometimes not even in more conventional work scenarios. So don't disappoint yourself by looking for industry-changing start-ups to burst forth from any event. Odds are against it.
Does that make hackathons a waste? By no means! Read on.
Design your approach
Work with your outreach teams and local community leaders to develop a strategic "plan of attack". Benchmark against other, similar events. Brainstorm on what you intend to achieve. Don't just plunge in unprepared! Speaking of which...
Prepare your communities
Want the hackathon teams implementing your products and technologies to shine? Then simply do your jobs as leaders: get them ready. For your known developers especially, arrange to meet with them at their own community events beforehand and make sure they know what you can provide. Offer free training, loan them equipment, do whatever you deem necessary to support a team that will make your tech rock. That said, never work against the rules of the hackathon.
In general, reach out to all potential attendees and make sure they're likewise informed. If you're offering a prize with conditions attached, make it very clear what they are and how those requirements may be fulfilled. I've seen teams with otherwise outstanding projects lose simply because they did not know or understand such requirements. If you're a sponsor, consider advertising prizes and expectations for upcoming hackathons, especially on your own website.
Become an active part of the event
Don't just mail in your support. Handouts (also known as landfill food), swag and even prizes only go so far. Show up at hackathons and pitch your product. Have expert staff on hand with the necessary skills to support your offerings. If participants need tools, bring them and provide them freely (sponsors commonly "loan" these out with no return date).
And don't just take my advice on what to do-- here are some useful tips from ProgrammableWeb on what to avoid: Top Ten Mistakes of Running Hackathons
Understand and work with typical outcomes
- Goodwill. Never underestimate it. When I was a Nokia Developer Ambassador, I consistently received compliments from attendees who expressed appreciation that Nokia was the only sponsor physically represented. Over time, this won developers over to our platform. Is your director looking for bottom-line results? Converted developers is a measurable one.
- Free press. People will write about your support and involvement. Make sure you're an active contributor to those messages. Do it right and they're blogging for you, not about you. Just don't be manipulative in the process.
- Feedback/Experience. At a hackathon you'll watch how your stuff is used, especially under pressure. You'll see first-hand how and where it breaks, and identify opportunities for improvement. You'll also gain keen insight into your competition.
Keep things going
Think of hackathons as punctuated equilibrium, infrequent opportunities to fire up your communities. In between, get busy with sustaining activities. Establish a "hacking continuum".
Follow up each event with a postmortem. Ask your community attendees what they liked, disliked, etc. And don't just settle for an email survey-- do this in person. Surveys are great and necessary for usable metrics, but physical presence is key.
As noted earlier, another critical part of the sustaining activity is pre-hackathon preparatory work. Do it, and you'll generate valuable community goodwill and ensure that your technologies and products are presented in the best possible light.
It's easy to dismiss hackathon outcomes if you look at the events through strictly conventional corporate lenses. Strip away the context of what I've presented here, and just about every one of them could be labeled a failure. Don't make that mistake, sponsors and evangelists. As with most things, "you get out what you put in" with hackathons. So put in some good, productive effort!