How to organize an internal Hackathon

Here in PPC Bee, we’ve already done seven internal hackathons. In order to organize them well, we looked for inspiration in many different sources. Unfortunately, most of them dealt with the issue of organizing external hackathons—i.e. 

Your company invites people into your firm that you’d like to possibly hire, you let them come up with great ideas, test the people if they are good at what they say they are good in in their CV, and in the end you can even kinda “steal” the ideas they come up with. Although we don’t hold external hackathons, it doesn’t mean we’re against them, quite the contrary—our internal hackathons are partially based on its principles, along with agile, Design Sprint, waterfall, and who knows what else … :) 

Those seven hackathons have taught us quite a lot. And because we’re huge fans of education, regardless of whether it’s we or others who receive it (e.g. in PPC Bee Academy), we refused to just sit on what we’ve learned about it and we decided to share it with you instead. So here’s a manual on organizing an internal hackathon.

The most basic and essential part of the entire hackathon is coming up with what’s going to be created at it. In PPC Bee, we hold three types of hackathons:

Regardless of which hackathon you’d like to organize, all participants must always have something to do at it. This means that there are tasks both for junior, and senior employees. The topic of the hackathon also cannot be too easy, neither too challenging.

In case of a bugkathon or client hackathon, prepare a list of about twenty tasks beforehand, in varying degrees of difficulty. No task should take longer than two hours to fulfill. We’ve discovered that if these hackathons try to solve a problem that’s too big, the results aren’t particularly good. Another important part of the preparation stage is to describe each task clearly and well in writing, and define acceptance criteria.

If you want to hold a feature hackathon, it’s good to first think about whether it’s even a good idea to try developing the feature in question at a hackathon, and whether it’s possible to create a functional MVP in a day or two. Possible solutions aren’t analyzed and drafted until the morning of the hackathon, but doing a small analysis and formulating a preliminary draft a few days in advance may come in handy.

Once you know what you’d like the hackathon’s topic to be, it’s time to think about who will need to take part in it. The entire development team? What about someone from the industry? Field experts? Better write down a list of people, including yourself as the organizer (in PPC Bee, anywhere from 6 to 12 people participate). Another step, which is vital (and rarely easy) is to decide on the date when everyone’s free, and your conference room, including a projector and whiteboard, is available. In PPC Bee, we’ve learned not to hold our hackathons on Friday when the team is dead tired. :) In our experience, hackathons are ideally held in the middle of the week from 9 a.m. to 5 p.m.

That would be it for the topic, participants, and date. Now all that needs addressing is the final edge of the magical money-time-scope triangle—the budget. In this regard, internal hackathons have one advantage, namely low cost. In our company, a single day of refreshments for 7 people costs about 2000 CZK. The team members are paid like on any other workday. Meaning that unlike typical monthly costs of development, a one-day hackathon comes to 2000 CZK, tops. Pretty worthwhile, don’t you think? :) 

And what will the day look like? Write down an agenda. And definitely arrange for drinks, lunch, and other refreshments to be available so that the team doesn’t die of hunger. Also make sure the food isn’t too heavy, otherwise your employees might fall asleep. :) 

In the evening before the hackathon, crank up the air conditioning in the conference room to purify the air. When your 7 people swarm to the room, it will take them longer to breathe all the air up. Push the tables together and set up a place for each participant, including a chair, external monitor, and cables. And don’t forget about wall plugs, too—one for each laptop charger and one for each monitor.

Make sure that no marker has dried out and prepare a cloth for wiping the whiteboard. Among other things, have papers, working pens, and sticky notes at hand and put a waste basket into the room. Check that the projector is working. And if you’re holding a hackathon in the summer, it doesn’t go amiss to set up fans since sitting an entire day in an overly conditioned conference room, when it’s 35 degrees Celsius outside, is no fun.

The main goal is to prevent team members from needing to leave the room for any reason and helping them work the entire time. Meaning, move a part of the kitchenette to the conference room—water, glasses, napkins, etc. A cooling box should include cool beer, energy drinks, etc.

Last but definitely not least, set up an integrated development environment. Honestly, we haven’t always managed it ourselves and can vouch that a failure to do so can really mess things up. Naturally, a working internet connection will come handy.

PRO Tip: Clear your test environment of any pull-requests and temporarily increase the number of containers on your testing server so that you don’t have to wait an eternity “before the tests are completed.”

Holding a successful hackathon is 80 % about preparation. Now, let’s talk about the hackathon itself. 

In the morning, we always start with an analytical part of the hackathon, which is attended by the entire team. In case of a bugkathon and client hackathon, we collectively go through all tasks to make sure everyone understands everything, and think about the implementation, regardless of whether it concerns programming, front-end, testing.... It’s just a typical design and analysis.

When you hold a feature hackathon, the analytical part looks a bit different (though it’s still attended by the whole team). The problem that needs to be solved at the hackathon is presented, with the following hour or four devoted to coming up with a specific solution—the members use the whiteboard, find solutions, make arguments, and formulate drafts. Recently, we tried the Design Studio methodology. This part of the hackathon sort of resembles team-building. You must keep in mind the rules of creating an MVP though. Remember to not go overboard on the daydreaming during design and analysis.

As soon as your goal is set, the implementation part starts. Write your sub-goals down, visualize them on the whiteboard, and do your standard kanban. During the course of the day, do about two status updates when you present whatever you’ve managed to create and remove any problems/blockers (similarly to the Scrum daily stand-up). Otherwise program, code, test, or even prepare content. Simply put, the entire team is fully focused on working towards the desired result.

Thirty minutes before the hackathon ends, hold a final demo—present whatever you’ve achieved, and note on the whiteboard everything that still needs to be done before any unfinished tasks can go into production.

Not going to lie—we rarely finish everything that was agreed upon during the morning analysis. When we were starting with hackathons, this made us pretty upset. Ultimately, though, we realized that hackathons presented an ideal opportunity for us to join forces and work collectively on complex, consecutive, or interdependent tasks. The most difficult tasks tend to be fulfilled, though. Any leftover assignments are usually finished by individual members themselves in the following days, without the team present. And that is okay, no need to bite each other’s heads off because of it.

We’ve realized this essential truth during the retrospective that follows after each hackathon. What went well? What worked, and what didn’t? Do we still love pizza? Is there something that could be prepared better next time? There’s always room for improvement. Write all observations down to make your future hackathons even better.

So—are you going to hold an event like this at your place? Or are you worried this might be too much for you to handle? Whatever your answer, here’s a few encouraging stats to close things off, summarizing what we’ve managed to achieve at our hackathons: 

No doubt, there are many other things hackathons brought us, making us realize that they are truly worth the time and effort. Will they be worth something to you? We believe they will. But you first need to give them a try in order to find out. Let’s do it! :-)