Lessons from five years of hackathons at Slack

Hackathons, hack days or all-day code jams: Whatever you call them, giving your employees the space and resources to pitch ideas and build out their concepts in a short time frame is a great idea for many reasons. They’re a creative outlet for software developers, a chance for anyone to fix their biggest pet peeves in your software and, in our experience, a consistent source of new product ideas.

Slack has thrown a hackathon every year since 2016, and we’ve kept track of every single project, team and idea generated along the way. That includes our most recent, and first entirely remote, hackathon, held in December 2020. To help you host your own, we’ve compiled the most important lessons we’ve learned in the process.

Why we do hackathons

Put simply, our hackathons directly improve the Slack user experience. Throughout our history of running them, we’ve seen various small teams pitch and build 287 projects. A third of those projects have been publicly launched as a product feature, been internally launched to employees as a new tool, or influenced a feature that eventually made it to production. Another third have landed on our product roadmap, are in development, or are in review.

Participation in December’s event grew 55% compared with our most recent in-person hackathon (though it’s worth noting that our overall number of employees in software engineering increased by a similar amount in that time). Project presentations consisted of three-minute recorded video demos, with 73 total projects produced by teams of one to nine people. Being our first remote-friendly hacking event, we also saw much more participation from our farthest locations, like our office in Pune, India.

One-third of our hackathon projects have launched as product features, helped develop others, or were released as new internal tools.

9 tips for throwing your own hackathon

We’ve learned more each year as our hackathons have grown. Whether your next hacking event is in-person, fully remote or somewhere in between, keep the following ideas in mind.

1. 48 hours, not 24

In the past, we’ve held our in-person hackathons over two eight-hour workdays. For our first remote hackathon we picked 24 hours, but a 48-hour period gives participants more flexibility.

“All-nighter” hackathons tend to skew submissions toward younger folks who can set aside the time for it. A two-day window lets more people work on teams and schedule their time over two full working days, giving them appropriate space for other commitments. Remember, it’s OK to let teams plan ahead of time, but save the coding until the big event.

2. Be open about your entries

We’ve found that the less technical the nature of your hackathon, the more people who can participate. And that doesn’t just mean coding, but opening the hackathon to anyone in your organization. To further support this, we allow people to submit mockups in their final presentations in cases where coding simply isn’t possible.

3. Beware the danger zone

Some hackathon entries can, very unintentionally, be potential HR violations. For example, an idea might require too much personal data or do something that brings attention to (or completely excludes) some employees. Filter out such projects before judging begins.

4. Communication, communication, communication

The biggest challenge for any hackathon will be communication, both internal and external. First, you need to get every stakeholder to approve the hackathon well in advance. You want to make sure managers know it’s coming so no one is surprised if a project’s production timeline is extended by a couple of days.

5. The more people participate, the better your outcomes

Communicate the hackathon companywide to make sure everyone knows it’s coming and participants have enough time to brainstorm, organize and plan for the event.

In the old days, we would print elaborate posters that adorned the office hallways. For remote events, we post messages at the launch into our global announcements channel, where everyone can see them.

6. Streamline your judgment process

Split the work of judging so it’s not all on one person’s shoulders. We separate entries into groups of about 10, with one judge per group. We’ve also found that when non-technical people—like from sales or accounting—judge an event, you might catch apps and utilities the engineering judges would have missed, and you’ll get better, more varied results.

Be sure you give your judges a framework to follow. Below is the guidance we give each of our judges.

All judging is recorded in a spreadsheet (here is our generic scoring spreadsheet). Set aside a few hours for the first round of judging and then a few more hours for the second round. That’s when your judging panel looks at the top scorers from the first round and makes final decisions on the best of the best, well before any awards presentation at the end.

7. Add categories as your contest grows

It helps to let more than one team win an award for your hackathon. You can start with a Best of Show and a People’s Choice (giving all employees an opportunity to vote). If you have many entries, you may need to split the judging along several categories (for example, Best Internal Tool, Best Small Feature, and so on).

8. At the end of your hackathon

Give out awards, give people recognition, and encourage them to note any wins on their future performance reviews. In our experience, people don’t typically care about getting expensive prizes (like a new laptop or iPad)—the prestige of winning is usually enough—but we do award small trophies that people can display on their desk.

9. Create an action plan for post-hackathon

Put all your entries in a spreadsheet anyone in the company can view, and use it to keep track of what happens over time. You may need to periodically reach out to participants months, or even years, later to have them update their project status. Make sure at least one product manager looks at every entry, so no great ideas fall through the cracks. Participants should feel like they’ve contributed to something that was reviewed and that it didn’t get ignored.

One last thing before you start hacking

Before you schedule your first event, have some product managers explore your company’s process of taking an idea all the way to the final product. Doing it a month ahead of your hackathon should help you figure out internal pain points along the way. And to ensure success, make plans for how you’ll spotlight the best ideas through awards and recognition.

For CTOs all the way down to engineering managers, setting time aside for a hackathon is no trivial request. Given that the average software developer has only about 200 working days a year, taking several days off to participate in a hackathon means taking time away from existing projects and being OK with a little chunk of your developers’ annual time going to it.

But as we’ve found, hackathons have a lot of upside. Employees influence the roadmap in a very direct way (maybe for the first time in their role), while addressing their own pet peeves with your product. At Slack, dozens of small additions to the product came directly from our previous hackathons. The events are also good for camaraderie and, ultimately, company culture too.