7 lessons learned from organizing a hackathon

We have been running a successful business for several years now. Our company has a wonderful portfolio of successful clients, a growing team of highly talented people and a market position that strengthens every year.

However, from the start we have seen the same problems pop up in our market over and over again. Convinced that a tech company like ours should be able to solve these problems once and for all, we decided to conduct market research to fully grasp the apparent problems. Now we know, that was just the easy part…

The hard part was finding out how to solve the problem by developing new technologies. We created a Web application for PR professionals working at agencies, corporates and NGO’s. The software is designed to help PR people pitch only to the right journalists, thereby minimizing irrelevant emails, or spam.

Still, we know that the amount of irrelevant pitches in inboxes of journalists keeps increasing. This inconsistency annoys us.

To explore the endless opportunities and test the limitations of our team of seven developers, we turned our office into a meth lab for our ‘Breaking Bad Hackathon.’

No distractions, full focus, one clearly defined problem, and two days to crack the nut. We didn’t know what to expect, but here’s what we learned.

1. Create a ‘business as unusual’ setting

We used the popular American series ‘Breaking Bad,’ about a high school chemistry teacher turning into a drug lord, as the theme for our hackathon. We turned one of our offices into a true meth lab, dressed everyone up in yellow safety suits and created a chemistry vibe with dry ice, blow torches and a fog machine (setting of the fire alarm in the building…twice. Oops.)

The setting immediately pulled the team out of their daily routines, forcing them to take a different perspective on the problems at hand. The meth lab inspired the team to come up with original and at times very unusual solutions.

2. Plan long sprints of uninterrupted working

The unusual setting, dress up party and nonsense can distract from the main objective of the hackathon, building and learning. We had a lot of ludicrous ideas for the two days but we decided to eventually cancel most of them to create time for five uninterrupted four hour sprints of programming.

Entering the lab as a non-developer was strictly forbidden during these sprints to safeguard the focus of the dev team.

3. Don’t force people into teams, let teams emerge

One day before the start of the hackathon we discussed how to divide everyone up in subteams, but we couldn’t come up with the optimal division of work. At the kickoff we decided to let it go and just see what would happen. This proved to work magically.

We asked everyone what they see themselves working on. One of our developers said ‘I think we all want to work on the exciting part (in this case: a Web crawler) obviously.’ Three developers in the room agreed with him, but three others strongly opposed and strongly preferred to work on a data model instead.

The other three rather worked on different and also essential aspects of the product. This natural division of the work to be done worked out brilliantly. Everyone could excel in the area they liked the most and in the end we had a complete prototype up and running.

Maybe it was completely coincidental, but we believe this freedom is an essential ingredient for everybody’s drive in a project like this.

4. Define the problem, not the solution

In the two months leading up to the hackathon we conducted in-depth research, exploring the work, challenges and wishes of journalists. We had 25 elaborate interviews with journalists and supplemented the conclusions with desk research.

At the kick-off of the hackathon we, presented the problem we aimed to solve very clearly. We were able to answer all the questions of developers immediately and we could point them to transcripts of the interviews and quote from other relevant articles. Without this research prep, we would’ve never been able to do so – and the hackathon would’ve been an unguided mess.

5. Provide new data sources, APIs and tools

We asked some of our strategic partners whether we could access their APIs for just two days to test potential integrations. We also asked other business relations for data that would be inaccessible on such short notice if we were to build the sets ourselves.

In the process we arranged for access to some new cool tools. This didn’t just benefit the team. By building stuff just for the sake of the experiment we could also show our partners and business relations the great potential of this data and this hackathon. They got very excited about it and we are currently investigating how to work together in these new fields.

6. Healthy food spurs innovation

We never supported the pizza and beer cliché. It makes you feel good for a few hours and then you start feeling like shit.

We decided to choose healthy meals, clear food breaks and some hipster superfoods. Providing professional catering for every part of the day, with a 5-minute explanation by the cook (who also happened to be a nutrition consultant) gave the team set moments to refuel.

The approach paid off. Even after the closing presentations at the end of day 2 we had some fuel left to celebrate!

7. Aim high but manage expectations

To get the most out of this project we set some ambitious targets for ourselves. At the end of the hackathon we wanted to see a working prototype using real data.

We managed expectations by communicating very clearly what a prototype is. It’s not something to ship, but it is something that works, albeit barely. It should prove that you can come up with a solution for every aspect of the definite product, if only you would put more time and effort into it.

So, the key question… Did we crack that nut in the end? In short: no. So what’s all the fuss about then?

Firstly, we developed a working prototype in two days, clearly revealing all the technical challenges we will have to face to get to a minimum viable product. The hackathon gives us the confidence we need to ship an MVP in the next couple of months.

Second, and very important: on top of all the cool stuff we built and the new ideas that originated from the hackathon, the team really enjoyed it. Every employee here now has a part in developing our new product. The team members learned a lot from each other, got to know each other better and together we turned into a highly adequate nut cracking machine.

So hopefully, we’ll soon be able to share some groundbreaking tech in PR and journalism soon. And share with us how you organize your company hackathons.