Hackathons are one of the most popular company-wide events at AddThis. From our start, these 24-hour events have been valued as a source of creativity, innovation, and collaboration.
The core concept of a hackathon resides in the root word “hack,” which implies a quick-and-dirty patchwork and a clever solution to a tricky problem. At AddThis, the projects we tackle during hackathons can be an engineering challenge like processing data at scale, an innovative product idea, or redesigning a common office area.
But no matter what the project, the spirit of hackathons remains the same – try something new and walk away having learned a valuable lesson, even if you didn’t accomplish your goal.
With that in mind, here are a few guiding principles we follow when organizing our hackathons:
During a normal day, people work on the specific products or functions for which they were hired. For hackathons, however, we eliminate such roles in order to maximize creativity and innovation. For example, there’s no reason why a system administrator can’t team up with a designer to try and create a new product feature, or why a few engineers and marketing team members can’t team up to repaint an old storage room and turn it into a quiet room for work.
Ideas have a much better shot of being realized if more than one person is involved. This is especially true in the software world where projects require multiple disciplines (e.g. back-end, UI/UX, database) to get off the ground.
One method we’ve developed over the years to encourage this kind of teamwork is a pre-hackathon event called the “pitch session”. We organize it a week before the actual hackathon and ask everyone with an existing idea to pitch to the rest of the company as a way to recruit team members who can bring missing expertise to a project. The session doesn’t take more than an hour, and it gets the collaborative and creative juices flowing amongst peers.
While it’s certainly nice to accomplish what you set out to do with a hackathon project, finishing is by no means a requirement. In fact, failure is a fairly incontrovertible part of hackathons, and learning overall. When participants present their projects at the end of a hackathon, we encourage the teams that didn’t reach their goals to talk about what didn’t work and why. Embracing failure as an opportunity to learn is part of what strengthens our work culture.
In addition to telling hackathon teams not to be afraid of failure, we do add an element of competition by rewarding the teams that stand out. We’ve come up with a few awards so that different projects can be recognized for their engineering prowess (CTO award), beautiful design (UX award), or product innovation and company impact (CEO award).
There’s also a company-wide popular vote, which builds a ton of excitement and anticipation at a time when everyone is tired from working on their projects for the last 24-hours. But the real win for these teams is to see their projects end up in a product roadmap. In fact, many of our available products started out as hackathon ideas, one of which is a data-science project that powers our audience modeling capabilities.
Hackathons are becoming more and more popular, especially in the software industry, and companies each run them their own way. These are four of our most valued hackathon guidelines, but we’d love to know how you run yours. Let us know in the comments below!