Editor's note: Erin Tao is a business development associate at Aviary — and, yes, its hackathon organizer. Follow her on Twitter @etaooo.
It's been about a month since Photo Hack Day 2, and I've recovered sufficiently from my hackathon hangover – a very legitimate ailment, though less literal than a SXSW one – to put some coherent thoughts together. A number of people have reached out, asking for tips, thoughts, and advice on throwing hackathons; only now that the second one is under my proverbial belt do I feel slightly more qualified to speak on the subject.
There's so much involved in terms of planning that I can't adequately address the important points in a single post. The emphasis of this article is the requisite planning, whereas the follow-up will focus on best practices for actual execution of demos, which are the most challenging and stressful element of hackathons.
Why organize hackathons?
You want a strong showing of local technical talent, who will presumably use the next twenty-four hours to create awesome things. You also want to establish your company or organization as a thought leader and community mobilizer in a particular space. In lieu of cash, the currency of hackathons is the collective goodwill that builds relationships and carries on long after the event; though possible, it's not the ideal shindig for turning a profit.
Why attend hackathons?
If you're a company: Nothing gives your API the same degree of exposure as providing a room full of developers with the opportunity to do some tinkering firsthand. Better yet, you have the ability to be present for the duration of the hacking process. There are very few chances to get such immediate, fresh feedback on what's confusing, what's awesome, and what you can be doing better.
If you're a participant: You need an arena to demonstrate your coding prowess. You don't mind missing out on sleep. You also don't mind subsisting on pizza, beer, and flat soda for 24 hours. Most importantly, you want an opportunity to participate in an event that really brings your local developer community together: you'll meet fellow hackers, see what they're up to, and show what you can do.
Why would companies want to get involved in the first place?
I've gotten this question (which I consider absolutely fair) a number of times. Nowadays, hackathons possess a much broader appeal; in fact, they provide one of the most direct forms of exposure to the startup scene and the technical talent in it. No longer are they niche events that are only relevant for a university computer science department: a perfect example is how the original Photo Hack Day was the first of NASDAQ's many event sponsorships, such as Shelby.tv's hackday.tv, the foursquare hackathon, and the hackNY benefit / fashion show, Raise Cache. Nokia's headline support of Photo Hack Day 2 enabled them to reach mobile developers and showcase the platform to the Windows Phone community – in addition to New York City startups – as a whole.
Big companies are beginning to understand that hackathons offer the brand visibility they desire as well as the audience they're trying to target – and that audience is quite receptive. Yes, developers aren't exactly fond of being pitched to, but they're undeniably curious: what new APIs are out there? How they can build on them, and what can be made? Each Demo Day I've had the pleasure of attending has proven that these answers are limited solely by the imagination and technical expertise of the hacker. This begs the question "Where else does – or can – this sort of thing happen?", which encapsulates everything that is awesome and slightly magical (yes, seriously) about hackathons.
Interested in throwing a hackathon of your own?
Organization and the pre-event legwork are everything. Here are the major points you must cover:
1. Pick a theme. A good approach is to explore existing verticals: at Aviary, we picked photos because of their relevance to our API / SDK in addition to the abundance of companies building awesome products in the space. If community is your primary concern (and it should, at a minimum, be a key motivation for throwing one in the first place), keep your role explicitly neutral. Don't name the hackathon after your company (this is why we opted for "Photo Hack Day" rather than "Aviary Hack Day"). Most importantly, don't privilege your own product.
2. Leave ample time to plan. Depending upon the scale of the event, you need anywhere from three to six weeks to properly prepare for the event. The first Photo Hack Day was organized in three incredibly frantic weeks, and Photo Hack Day 2 – a much more extensive endeavor, in terms of attendees, offerings, and general scale – took over two months.
3. Lock down a venue. For obvious reasons, nothing substantive can happen until this is taken care of. General Assembly is the go-to hackathon destination in New York City, but other alternatives exist: the Spotify hackathon was held at SPiN, hackNY continues to be held at NYU, and plenty more take place in a range of corporate venues such as Microsoft, Google, or Aol ventures.
4. Secure sponsorships. To be sure that the broadest range of potential sponsors can participate, use tiered sponsorships and keep price points relevant to what you can provide in exchange for support. This consists of varying degrees of product / API exposure, as well as branding opportunities. Generally speaking, the most expensive elements of a hackathon are venues, food, and prize money – contributions from a headline sponsor should cover the cost of at least one of these.
That being said, as an organizer, it's crucial to strike a balance between making an event worth a sponsor's time and preventing the weekend from degenerating into a pitch-fest. Your priority is to throw the best event possible for hackers and the tech community. After all, when builders and innovators are exposed to sponsors in ways that don't feel forced, everyone wins.
5. Rally the interested parties. Tap into existing developer networks – Meetup is perfect for this – and make the appropriate reach-outs to sponsors and companies with cool, useful APIs. If a company with an irrelevant API contacts you, it's perfectly okay to tell them that the event may not be the best use of their time. You save them the time, effort, and the risk of being disappointed, while sparing developers from demos of technology they won't use.
Figure out who can help you on the day of the event: coworkers, volunteers, or friends alike. If the venue offers on-site help, be sure you establish, in writing, who is taking care of what, and what time you can rely on them to be where. When you don't know how the hell the A/V system works or where extra power cables are stored, these people will help fend off the waves of potential panic attacks.
6. Market like heck to potential attendees – and don't forget students! In addition to the obvious press reach outs, look for influencers who can spread the word via social media and word of mouth. Attend events, happy hours, and contact listservs: a few great places to start include StartupDigest, Gary's Guide, or incubator mailing lists. Ask sponsors for help with cross-promotion and leverage their networks; after all, it's in their best interest to have the widest audience.
We've had great success with student-hackers, so reach out to the computer science departments at local universities. At Photo Hack Day 2, Columbia senior Yufei Liu created Synviary and walked away with the Aviary company prize, People's Choice, and First Place, winning a grand total of $7,500. Abe Stanway and Misha Ponizil, students at Rutgers and NYU, respectively, won People's Choice and Second Place at Photo Hack Day for Honey Badger. Their bounty? $4,000.
If, according to one redditor, neon wayfarers, American Spirits, and PBR are ingredients for the hipster beartrap, then free pizza, free beer, and the potential to win hundreds (if not thousands) of dollars over the course of a weekend is the student developer equivalent. Their attendance is absolutely worth the time it takes to reach them. For those of us a few years removed from college, we can't allow ourselves to forget that the next wave of members in the New York tech community will be new graduates.
7. (Slightly) over-order on food. I can speak on this matter as someone who has epically over and under-ordered. If you over-order, it sucks to see food wasted (especially if you're footing the presumably expensive bill), but it's nothing compared to facing a maelstrom of empty, angry developer bellies. There should be two golden rules concerning hackathons and food: (1) don't f*ck up the coffee, because nothing is more endearing than dragging developers out of bed on a Saturday morning and depriving them of caffeine, and (2) don't f*ck up the meals. (In the interest of full disclosure: I have done both.) If you think it is remotely feasible for a room of over 200 young men and women to finish the spread, trust me – they will. Also, it helps tremendously to ask attendees to note any special dietary needs when they sign up for the event.
To give you an idea of why you should oh-so-slightly over-order on food, here's what hackers at Photo Hack Day 2 consumed in a span of thirty-two hours: 250 bagels, 300+ tacos, 300+ burritos, 12 buckets of BBQ chicken, 20 quarts of pulled pork, 12 pans of cornbread, 20 quarts of mashed potatoes, 150 cookies, 80 boxes of pizza (640 slices total), 27 cases of water (432 bottles total), 384 beers, and 28 cases of soda (448 cans total). Hackathon organizers, do yourself and your hackers a favor by including an extra pizza (or ten) in your catering order.
8. Make sure there's (a wide range of) cool stuff to give away. There's a strong correlation between the quality of prizes and the quality of hacks. For the first Photo Hack Day, Twilio gave away an 11? MacBook Air, while Shutterstock gave away a Nikon dSLR. I'm sure you can guess whose APIs were well represented on Sunday.
Push participating companies to sponsor a prize and give them the freedom to choose the winner. It's a win-win situation for everyone: companies want developers to hack on their APIs, developers (like the rest of us) don't mind material motivation, and attendees want to see cool hacks.
9. Remember that, regardless of how much you prepare, sh*t may – and probably will – go wrong. It's just a matter of figuring out what constitutes an acceptable mishap and what is debilitating, and building safeguards to ensure that the latter doesn't happen. Mishap: an order of twenty Hawaiian pizzas, when you meant to order pepperoni. Percolators end up brewing what looks like dirty water, rather than coffee. Not enough small or medium tees to go around. Compare this to the disastrous counterpart: the wifi cuts out. Projector breaks during demos. Not enough power outlets. See what I mean?
Once all of these moving pieces are in place, the foundation is set for a solid hackathon. Solid does not mean smoothly run, by any means – execution of the actual event is an entirely new beast.
(Credit must be given where it is due. Everything I learned about building some semblance of order and structure came from John Britton, whose knowledge once existed as a seven-page Word doc that he kindly shared with me. John's thoughts have since turned into a more cohesive article by Ben Doernberg, which I would absolutely recommend as a starting point.)
[image from Hackers]
No hay comentarios:
Publicar un comentario