Making Hackathons Work

A Few years ago, Hackathons were all the rage - and then they kinda died out; or morphed into events that were serving other purposes but still called by the same name and everything became a bit blurry. I organized In50hrs - a little over 75 of them in 8 cities across India.

To get things out of the way, Hackathons are organized (primarily) for three main tasks:

1. By Companies to attract talent and for hiring. (Eg. Hackerrank, Save the Hacker)
2. By Platform Developers to get more developers to start using their platform. (Eg. Facebook)
3. By Incubators and Accelerators and whatnot to identify teams that are solving real problems. (Eg. In50hrs, Angelhack)

I haven't organized much of (1) or (2). But if you are an Incubator or Accelerator - or an entity that is pushing the Startup Ecosystem like the Government, Hackathons still work, but they have to be finetuned a bit differently. Here are some insights, that you might find useful.

• A One Week Long Hackathon Brings out more Serious Participants than a weekend Hackathon
• Pick Top 3 Candidates, than One Winner.
• Winning Teams get their emotional satisfaction and seldom go beyond that stage
• Instead of Prize money, have a Seed Fund (say 20-25L - Approx 50K USD) and a follow on incubation Program that they have to join to claim it. They only get an Admission to Incubation Program at the end of Hackathon.
• Do registrations as Teams rather than Individuals. Preformed teams are much stronger - even better if they have worked together before.
• Have Problem Statements very well defined (Gates Grand Challenge, X Prize or the Innocentive Platform are good examples) 
• If Possible allow for participants to spend the first day or two (of the week) in the Problem Environment where they see how things work, to validate whether their assumptions are right.
• Operators tend to give Problem Statements that are PAIN Points, but not business opportunities. Startups are built around Business Opportunities, so have a system to grade these problem statements before giving it to the participants. Else you dont get "Startups", you get a service provider.
• Pain points have to be abstracted one level up.
• Food doesn't have to be elaborate - infact big meals are bad. People tend to feel sleepy. Break it down into smaller, healthier meals. Even Sandwiches etc would do, with one good dinner at the end of the day.
• We don't see teams working overnight as being productive - in fact we start seeing people becoming sloppy on the next day, missing meals, getting cranky and the whole setup starts looking like a Frat house. Working overnight can be an option - and the venue can be open for the teams who want to (as long as the space has a place to shower), but we have seen better results from teams that work on a set time, call it a night by 10 or 11pm, and then go get some sleep and come back and take a crack at things again. The best breakthroughs have happened after a good night sleep for most teams.
• Pivots are very very expensive later on. You ideally want to see teams evolve their thinking and mature during the hackathon itself. That is value add.

I still believe that it is possible to build something worthwhile in a weekend, if you spend a couple of months preparing for it. But in the scenario - where most participants come to a hackathon because they lack that discipline - it makes sense to have a week long structured hackathon where you also get a day or two in the beginning to set that framework and then drive folks towards it.

Let me know if you think this is helpful.