Hacking the Hackathon

As a 250-person (and growing) organization with a large engineering presence, there’s long been a strong internal appetite to organize a Latch Hackathon, where technical contributors get together for a short period of time to collaborate on a project. Like any agile and scrappy team, we faced some trepidation of how we could effectively pull off an event with limited resources and disruption.

But earlier this year, we hosted our first successful hackathon event. We saw nearly 100 percent participation from every software engineer, alongside other employees from various departments across the company — including firmware and mechanical engineers, product designers, program managers, and more. In two days, these teams produced 11 different projects exploring new ideas that covered every aspect of our product experience. These projects were no minor tasks — one hardware demo had the same effect as a Vegas magic act, eliciting audible gasps from the audience.

During this process, we learned some valuable lessons for “hacking the hackathon.” In short, hosting an effective event that’s not only fun but also provides amazing value for the organization doesn’t actually require the resources of a larger, more established organization. Here, we’ll share our tips and tools of the trade.

Schedule with roadmaps in mind

With roughly 30 software engineers at Latch, we believed it was imperative to gather as many minds as possible to create a worthwhile event. However, we were also sensitive that asking the entire software team to set aside their projects for two days could also cause major disruption. With this in mind, we scheduled our hackathon at the beginning of the quarter. For most teams, this is usually a time where most projects have wrapped up and leaders are focused on planning. Engineers and their managers have more flexibility to spend time on projects outside their roadmap — making a hackathon more available to people and eliminating the need to drop out due to “crunch time.”

Don’t overcomplicate logistics

When a group of us got together to start planning the hackathon, it was important for us to make this event feel special and not just another day at work. We initially discussed taking people out of the office to an entirely different environment that was more conducive to dividing groups into teams. However, we quickly realized this would present logistical challenges. While renting a workspace was an option, they were costly and we also needed specific equipment like extra monitors, power, and whiteboards. We’d also need an area for snacks and a location that was near our office to make sure commutes weren’t significantly impacted.

With these requirements in mind, we decided to scale back and use our normal office space. Instead, we set aside certain spaces as designated hackathon areas and arranged desks that could be easily moved throughout the office based on team needs. For meals, we arranged breakfast, lunch, and dinner for all our hackathon participants that still made the day feel special. These minor changes kept our budget needs to a minimum and led to simpler logistical planning, while also giving people an environment that felt different from their day-to-day workspace.

Success is its own reward

We initially considered offering prizes for the best projects. However, we ultimately decided against this. We found that participants were incredibly motivated by their excitement for their project, by their own teammates, and by other hackathon participants. Eliminating prizes didn’t just eliminate another budget item — it also allowed us to remove the logistical overhead of choosing a panel of judges, formalizing judgement criteria, and eliminating our anxiety as organizers about the potential perception of “unfair” judgement.

Make participation easy

We encouraged participation from people across the company and extended our invitation to include those outside of engineering. This proved to be a winning strategy as different perspectives and user knowledge from product, design, sales, and other departments resulted in powerful projects and new cross-company bonds.

With this in mind, we found value in explaining in all our announcements what hackathons were and how cross-functional participation could add incremental value. While most engineering organizations are usually familiar with the concept of hackathon events, non-technical teams may be less familiar.

To further encourage participation, we made sure participants knew that although they were welcome to work longer hours on their project, it wasn’t the expectation. We also made it clear that the hackathon project was NOT expected to be completed on top of their normal workload. For those two days, the hackathon should replace their work and not add to it. We found most teams ended up wrapping up each day around 8:00PM.

From interest to participation

When we announced the hackathon, we heard overwhelming support and excitement. However, we were a little surprised to realize that turning excitement into participation required some coaxing.

We found it effective to give people a nearly-free way to express interest like adding their name to a list. Then we provided a more formal sign-up document where people could form teams, record what they were interested in working on, and more. While few people took the leap from “expressing interest” to “signing up” of their own accord, we found that using an “interest” list had a better success rate at getting individuals to to sign up.

Second, we were surprised by how many people wanted to participate with very little information around teams or projects. We organized an optional “team formation” meeting the day before the hackathon where we put several ideas on the board, invited anyone with an idea to present it, and then informally started forming groups around ideas that had critical mass. We were pleasantly surprised to find it wasn’t too difficult to get everyone who was interested paired with a project and team.

When a small group at Latch got together and decided to organize an official Latch hackathon, we had grand ambitions which made the task seem even more daunting. But we realized that we should apply the same ethos we asked our participants to apply — to focus on proof of concept rather than polish — and to launch the first Latch hackathon without letting perfection get in the way of execution. Once we adopted that mindset, everything fell into place. We scaled back on our wish list when it seemed logistically or financially difficult and still managed to create an event that felt different and exciting. We emphasized making it easy to participate and encouraged people from across the company to take part. Ultimately the success of the event came down to the skill and dedication of the participants themselves — and with Latch employee talent, this delivered phenomenal results.