I’ve organized hackathons for two years at Bench. They’re fun, creative, and delicious (food is key). I’d like to share some of the things our team has tried and learned.
We run quarterly 2-day hackathons at Bench to take a break from our day-to-day routines and surface new ideas. They always yield interesting projects, but the past two hackathons have gotten particularly spicy. More good ideas started making their way into follow-up sprints and challenging our product roadmap.
So what changed? I’ll do my best to try to articulate how we as organizers may have contributed to the success of these hackathons. It’s important to focus on what we can control, and although we can’t guarantee the results of the projects, we can control the format and environment.
Hacking the format
A hackathon is a DIY, bottom-up affair where we want to surface the team’s good ideas. We even embed that philosophy in how we organize by having the event owned and run by volunteers on our team. That means we’re doing it like engineers would — iteratively. There are plenty of things we’ve learned along the way.
At first, a 2-day hackathon event would seem fairly straightforward. Set a theme, order pizza, ask some important people in the company to judge on the afternoon of day 2, and then award some gift cards to the team that wins.
Oh, how far we’ve come! From running a few hackathons we’ve learned about our team’s values in each of these areas, and we’ve adjusted almost all of them. I’ll list some of the things we do and the lessons we’ve learned in each area from our experience running quarterly hackathons.
A theme is a guide, not a rule
Themes are helpful. They provide some constraints that can foster creativity, but at Bench we’ve also seen that themes can narrow peoples’ focus too much. Some previous hackathon themes felt like they encouraged speculating on the product roadmap ahead of schedule, and that wasn’t our intention.
One hackathon we ran had a mandatory theme of “Growth”, and the winning team implemented a third party referral system inside our app, with a pull request ready for review on Monday. Inarguably it was high value, but also very safe.
We changed two things for our most recent hackathon to encourage broader thinking: we made the themes optional, and we made the theme more of a prompt than a requirement.
Our most recent hackathon’s theme was “Data Magic”. It was specific enough that it gave people some ideas around our new Financial Data Service, yet it was also sufficiently broad enough that it allowed wide interpretation. The end result was a wider range of ideas, some theme-related and some not, but all exploring valuable concepts for the company.
Winners, not prizes
If it’s an internal hackathon, you don’t need fancy prizes to bring people to it. The poor souls have no choice. Going rogue and working on cool stuff off-ticket is the only option they have.
That said, we tried to buy the winners gift cards during previous hackathons. Unfortunately, we didn’t know how big the winning team would be, which meant we couldn’t buy prizes ahead of time. On one occasion a winner didn’t want to accept a gift card — they were just happy with winning. So why were we worrying about gift cards?
We also have a tradition of immortalizing our winners names on a bench in the office. It doesn’t get any more prestigious than having your name on a bench at Bench. At our most recent hackathon we chose to forget the gift cards and just stick with the bench plaque. Guess what? No complaints. The feeling of being recognized for your achievement is enough. Now, instead of throwing that money at Amazon, we can throw it at caterers.
Delicious, nutritious food (may contain traces of CSS and HTML)
It feels terrible when you go out of your way to order food for your team and then somebody needs to go elsewhere to get their lunch because you didn’t take their needs into account (this has totally happened). People like it when their health and their tastes are considered when food is ordered for them, so we try to be mindful of both.
Our team has an array of dietary preferences, so at our most recent hackathon we found options that would be delicious and healthy for everyone. In Vancouver we’re lucky enough to have some catering providers that do this exceptionally well; our catering for the last hackathon was by Dirty Apron, Heirs Pears, and Nuba.
A note about pizza: it is delicious, popular, and often an easier option (depending on diets), but since we only do this once every 3 months, we choose to prioritize memorable over easy.
Don’t space out when it comes to space
Bench is in an open office and has a shortage of meeting rooms. We’ve known this for as long as we’ve been doing hackathons, so we don’t mess around. Meeting rooms are bookable and we worked with our facilities team to manage moving any existing or recurring bookings.
We’ve been fortunate to never have this come up as an issue — every hackathon has started with groups taking over the area available to them and self organizing into pods. Some rooms end up as war rooms full of whiteboard sketches for the full 2 days. That’s the optimal usage for them in my opinion, so I’m happy to ensure that’s never an obstacle.
Let the audience do the judging
In previous hackathons, we invited judges that each personally cared about the theme as it impacted our company. We felt that this compounded the issues that the theme created and put too much emphasis on delivering predictable business value that the judges would appreciate. That’s something that we already do every day at work, hopefully, so we wanted to encourage a wider range of projects.
We stopped inviting judges to eliminate this bias in project selection and instead ask participants to vote winners for each category: innovation, company value, execution, and presentation. Then we determine the overall winner based on those votes. With this choice we optimized for speculative projects and saw more of them in our most recent hackathon as a result.
Empower the organizers
Our committees tend to be junior and intermediate engineers who are genuinely enthusiastic about having fun and experimenting. We’re fortunate that our leadership understands the value of hackathons and trusts the organizing team to take two days of time and make the most of it. Since the cost of 2 days of engineering time isn’t a primary job concern for us (yet), we can instead focus on collecting ideas and hyping up the rest of the team.
Hype it up around the company
The engineering leaders at Bench have long understood the value of hackathons and defended our time spent on them. They’ve not only endorsed the organizing team to spend time preparing the hackathon each time, but Geordie Henderson, our SVP Engineering, documents the projects in order to share the outcomes with the rest of the company after the event.
We also make the presentation time known across the company so that curious people can come check out what’s going on. The more understood the value is by the rest of the company, the more freedom we get to continue this.
That’s the gist of it
When you walk into the office on a hackathon day it should feel special. It should make you want to try something new and exciting, and then share it with everyone. Hopefully parts of what we’ve learned will help you open that up more for your team if you’re running internal hackathons. The basic idea is always the same: with full, happy bellies, a clear 2 day schedule, and space to work, your team can do some epic stuff that surprises you.
And if you’re not running internal hackathons, you should totally try it.
That’s all. Until next quarter, happy hacking!