Hackathon Does and Dont’s

While wikepedia puts hackathons in the domain of computing only (see here), in my understanding a hackathon must be defined much broader and many examples show evidence of hackathons growing up in non-IT spaces. It is a timeboxed event where any sort of interested people try to build a solution for a given problem or try to create value on top of existing data, interfaces or anything else (e.g. Chemistry Hackathon). There exist plenty of websites like hackathon.io which offer a calendar of upcoming open hackathons. And most important to name is the uncountable number of internal hackathons giving employees the chance to promote and develop their ideas which would never see light otherwise. More and more hackathons are accepted as a useful tool of open internal and external innovation. Hence more and more hackathons come up, willing to embrace the power and genius of each participant.

But what makes a hackathon a successful one? There are some obvious ones like

more than enough drinks and food (and geeks do not eat burgers and pizza only)

a good work- and playground

a clear, demanding but achievable goal, a real world problem

passionate supporters and a not to homogenous group of hackers

the story must go on (the end of the hackathon is not the end of the idea!)

While one may wonder why adequate prices are not in the list because they are not primarily necessary if you really match the 4 rules. As you may notice those 4 are quite similar to what Daniel Pink thinks makes a team successful; purpose (the demanding goal), mastery (matching with others in playground) and freedom (the team is self organized). One should not forget how important an adequate amount of humour might be. Especially as pride and sorrow may change a few times during a hackathon. The longer it takes, the less sleep you have, the more humour (not sarkasm) is sometime needed to keep you going the last mile…

And finally one more word: the result of a hackathon is not a ready-to-rollout product. It is a bunch of ideas with a first prototype or even a little bit more. As mentioned earlier prices are not the goal of taking part. It is relevance and every hackathon organizer should ask him or herself, how each hacker can keep on contributing or how his idea gets acknowledges when it comes to a real product later on. There exist some pretty good internal hackathon stories which result in labs, where the idea can be used in real by end-customers and the inventors are shown on the labs page, official contributor lists and many more. It highly depends on what you want to achieve and within which context.

How does your project plan look like?

This plan should give you a rough idea, it may vary depending on your case. It was used for a roboter hackathon with external teams only (see robothon)

Weeek 1: Workout on the goal, which is achievable in 24h, not too easy, not too strong, take care on your audience. Think about what sort of Tech you will need to help them solving the problem.

Week 2: Check financials, if needed talk to potential sponsors, at robothon we asked for 100 Euro per team only, rest was paid by sponsors (which is quite demanding if you work with roboters). Think about what you may tell sponsors already. (We decided to write about the claim only (10 items, 10 meters, 10 minutes), not about technology and other jobs to be done like we wanted them to think about a business canvas too)

So within 3 months a solid hackathon is organized, take that time, especially consider more time for the first 3 hackathons.

The hackathon day (24h):
14:00 welcome
14:15 Intro, rules, schedule
14:45 Show playground and working area
15:15 Unpacking
16:00 GO
22:30 Part Exchange 1 (allow the teams to change parts if necessary)
24:00 Midnight break
8:00 Part Exchange 2 (allow the teams to change parts if necessary)
14:00 allow public viewing for the last 2 hours if OK for the teams and if a hackathon with externals
16:00 LIVE DEMO
17:00 And the winner is …. and party 🙂

I will continue to organize internal and external hackathons. One thing you have to acknowledge is, you should truly try to understand what makes the teams successful and what motivates them to come back for the next session. We started working with a University team of occupational scientists in order to get those questions answered (Pilot study in German out there, ping me if you are interested). Do not forget, that a hackathon results in a lot of energy and a lot of work to do upfront. You are then paid by energetic teams, an incredible amount of creativity, fun and ideas. You get tons of leadership and group management insights and you get not only prototypes but loyal hackers giving their time and passion (for free) to you!