Running your first internal hackathon

A company hackathon is a great way to boost the spirit of your team, especially in Covid times. But how should you go about organizing one?

In case you’re not familiar, a hackathon is an event with the goal of building cool projects as quickly as possible, often with an overall theme. The participants are usually software engineers but product managers, designers, and non-technical folks can get involved too.

What gets built can also vary broadly: software, hardware, a combination, a demo video, or something else entirely. The goals can also vary pretty broadly and will be very different if it’s an internal hackathon compared to a public one. Companies will often use them internally to develop innovative new features (one famous example is Facebook’s Like button).

I’ve taken part in many internal hackathons at my previous companies, but I recently organized one myself for the first time. Now I’m sharing what I learned, and my advice for running your first internal hackathon:

1. Be clear about your motivation

Hackathons can serve different purposes and that’s totally okay. What’s important is making sure you have a clear goal for yours. Whether you’re trying to get ideas going for a big new company initiative, looking for an opportunity for your team to bond, trying to give people a chance to work on pet projects, or something else entirely, you should know why you’re doing the hackathon – and make it clear to participants.

For me, it was clear from the beginning that I wanted to bring the team together for the first time since the pandemic started and give everyone a creative outlet to work on projects they wouldn’t normally.

To my surprise, these goals weren’t obvious to my team. Some of them had absolutely no idea what the goal was (besides the very ambiguous ‘hacking’) and many assumed we’d be working on specific projects that we simply wanted to tackle quickly, since that’s what they’d seen hackathons used for before.

Luckily, my team spoke up about their uncertainty. To avoid the problem in the first place, you should let folks know what the goals are right away when you announce the hackathon. Not only will this avoid confusion and set a clear shared goal, but it will also give people an opportunity to start thinking about the kinds of projects they might want to work on.

2. Manage the expectations of other departments and company leadership

‘What do you mean all development is going to stop for three days? We have important projects?!’ Be prepared to hear this when you first start planning a hackathon.

There are always going to be deadlines, important projects you don’t have capacity for, bugs in production, and numbers not being hit. The important thing is to communicate why your hackathon is important to get buy-in from other departments and senior leaders.

When planning our hackathon, I’d originally only told a couple of relevant people but word got out quickly and I received many, many questions from various people and teams with different degrees of nervousness and frustration. The event would require time from folks that they needed for their own projects and they were understandably anxious.

To tackle this, communication was key. I sent an email to the company leaders (many of whom had never even heard of a hackathon) explaining what the event was, why we were doing it, why it was important, how we landed on the timing, and what kinds of requests would be looked at during the hackathon (real business emergencies only) and what wouldn’t (everything else). To avoid further confusion, I also let everybody know about the hackathon in our company Slack channel (but this was more for general awareness).

In my 1:1s with department leaders before the hackathon, I reminded them it was coming and invited them to ask any questions. By the time the event rolled around, everybody was on board, incredibly supportive, and genuinely excited to see the projects that would come out. Most importantly, they respected that teams would be taking time out to work on it.

3. Figure out the details

At this stage, everybody should be clear on why the hackathon is happening and feeling excited. Now it’s time to start figuring out the details. There’s no standard template as every hackathon is different, but you might find it helpful to run through these specifics:

• What are your exact timings?
• Who will be invited? Do they have to participate or is it optional?
• Who will be arranging travel for any remote team members?
• Are you going to provide food and if so how often?
• Are there going to be any special extras (I’ll never forget the reptiles that were brought in during one hackathon…)?
• Are you providing any swag (t-shirts, stickers, etc.)?
• Will anything be judged and if so who will be the judges?
• Will there be prizes?
• How is everybody going to present what they work on?
• Do you need any prep sessions?

If you haven’t participated in a hackathon yourself, I recommend chatting with a few people who have and asking them what they liked, what didn’t work, and what could be skipped. Remember to keep your own goals top of mind and don’t take on anything that you’re unable to do well.

In my case, I went with stickers instead of t-shirts since swag wasn’t a focus. The event ran for two and a half days, and participation was optional for all engineering, product, and data teams. We had presentations and judging, but the organization was a bit messy and there weren’t any significant prizes. This wasn’t ideal but it didn’t detract from the overall experience, and they’re just things we can improve on for next time. The first time around, my VP of Product and I split the organization, but next time I’m definitely getting more support to handle things!

4. Manage the expectations of the team

Once the plan is all set, you need to tell the team early and often what’s going to happen. Remind them that they’re the ones who should be coming up with ideas. Don’t dictate their projects; you want them to be as creative as possible.

In my case, we had decided that there would be winners in two categories: the project that could benefit our customers the most and the project that could benefit employees the most. We made this clear to everyone on the team, also clarifying that they wouldn’t be limited to these categories if they wanted to work on something else.

We also scheduled a session a couple of weeks before the hackathon to generate ideas as a group. This was a great way to get people in the right mindset and go over the plan again. It’s important to have meetings like this on the calendar early so folks can block their time and prepare their thoughts.;

Remember there’s a lot of repetition involved in getting information across effectively (to communicate a message, you need to say it seven times).

5. Reflect on your success, ask for feedback, and repeat!

Congratulations, your hackathon is done! Now what? To assess whether it was successful, you keep in mind why you did it and ask yourself whether you achieved your goal.

It’s also important to gather feedback from the team. I sent out an anonymous survey, but even informally asking people a week or two after the event will do. As well as assessing the technical or formal achievements, reflect on how happy you were with it. Did it bring you joy? Did it boost team morale? Did people seem to enjoy it? The most important thing to me was bringing everybody together and seeing all the cool ideas people had worked on.

Our hackathon was a great success and the feedback from the team was overall very positive. Some folks said they’d want a hackathon every month (probably a bit too regular) while others said once a year. Some wanted it to be longer and others would have liked it shorter. This just goes to show there’s no perfect format but the more feedback you have, the easier it is to learn from the experience and make improvements for future hackathons. I’m already looking forward to the next one!