I have run into several urgent situations this year, including major infra instability issues caused by fast product iteration, large cost reduction target with a short time window, and a major product sprint to deliver. Things started getting worse after some major product launches led us to accumulate a lot of technical debt in a very short span of time. As a result, my infra team was stuck putting out fires nearly every weekend just to keep the system up and running during traffic peaks. We were dealing with crisis after crisis and had a bunch of ideas about how to fix some of these issues, but everything was going to take a long time for our team to implement. We needed a solution that would generate fast, unconventional, innovative results. Enter the hackathon.
The idea of a hackathon always sounded like a team-building event to me. I had always wanted to host one, but never imagined my first time would be during a crisis situation. With no better option, I decided to give a hackathon a try, but called it a “stability camp” instead, to avoid any misconceptions around the word “hack.”
Before getting started, I had a lot of unanswered questions. Would feature teams be interested? Would anyone (other than those on the infra team) sign up for this? I had no idea.
I sent out an email to the entire team and stated the simple mission of this hackathon: “to make our system more stable while continuing to add new features.” I also created a virtual idea sheet in which I listed 10+ ideas generated by the infra team. Over the week, I mentioned the crisis and the upcoming hackathon in every conversation I had with other people in the company. A week later when I opened the sheet again, there were more than 100 ideas from various teams, even some from our client engineers with suggestions for rewriting iOS/Android modules to help.
When the hackathon finally happened, it was a huge success. At the end of our 2-day stability camp, we had finished 39 projects, made significant progress on 14 ideas, and converted 71 ideas into 3 long-term initiatives. The results were astonishing. We have even been able to enjoy a few smooth weekends since then :).
We could have just called the event a success and moved on, but there was something magical that happened during the hackathon that I didn’t want to let slip away. On the first morning of stability camp, each person spent 1 minute presenting their ideas. The feeling was beyond impressive, it was creative, inspiring, and astonishing. It gave me a completely new perspective of the system that I had spent so much time building from the ground up. Over a 2-day period, people collaborated in teams to address a wide range of issues. People experimented with new roles in their projects: client engineers worked on the back-end, feature teams improved infra design, infra engineers fixed data pipelines, etc.
The intensity of the collaboration not only generated some impressive results, it also influenced our organizational culture. More teams now think in terms of stability and every team took on new projects, including initiating efforts to improve quality, enhancing monitoring and test coverage, etc.
Three months later, I staged another hackathon — this one focused on product development across several organizations in different cities. The hackathon was also a huge success, and it achieved the goal to align teams across multiple organizations towards a new product vision and inspire new ideas. From the hackathon, a lot of collaboration was instigated. People learned about different teams, collaborated with each other, and, most importantly, started to appreciate the challenges others had been dealing with.
Hackathon Defined
After a few successes, I started to wonder what a hackathon really is. George Krasadakis presents one definition in his article “How to Run a Successful Hackathon”:
“An intensive, software-centric ideation, prototyping and presentation challenge on known or unknown problems or opportunities.”
I’d like to make some modifications to this definition based on my experience and define a hackathon as, “An intensive, software-centric ideation, implementation challenge on known or unknown problems or opportunities.”
How to Plan a Hackathon
When planning a hackathon, the first thing you need to do is to identify the theme. What’s the goal of this hackathon? Your theme can range from broad concepts (future of video, blockchain for non-profits, etc.) to very specific goals (infra stability, etc.). The more focused your theme, the easier it will be to measure your results. The success of a hackathon can be measured by the number of participants, the number of finished projects, or the improvement of core metrics for a specific problem as defined by the theme. But the long-term impact of your event — which may be more important for internal hackathons — is the potential for culture shifts (internal collaborations, etc.) and community growth (retention rate for future events, etc.). Those things can be hard to measure directly, but can be observed through indirect feedback on later collaborations.
As the planner of a hackathon, I found several levers that can be tuned to achieve better results, the same as any other large-scale system:
- Participants: once you know the theme of your event, the second most important decision is who you will invite, which is often dictated by your theme. A hyper-specific theme like optimizing for infra cost may only be appropriate for members of the internal engineering team; however, a broader theme, like distributed fintech, can involve groups beyond the engineering team, such as the product, design, marketing, and sales teams, among others. You can even go outside the organization and host a public hackathon, which has the additional benefit of serving as a potential recruitment event.
- Incentive: the most important factor to success in a hackathon is the participation ratio. You can’t ensure increased participation by just inviting more people. The more diversified a group is, the harder it can be to create a shared incentive. When I brought up the goal of making our system stable, people were instantly incentivized because this is a shared goal across all my teams. For an event with a broader theme, it’s important to identify a common goal, such as a shared company strategy, increased visibility, supporting collaboration, etc. Many people suggested that I offer financial rewards, but I didn’t think that would be an efficient means of motivation. Small swag items for winners can be fun and help everyone focus on the mission instead of cash prizes.
- Timespan: the event can’t be too short or too long. It can’t be so short that nothing serious can be accomplished, but it can’t be so long that everyone gets bored, overwhelmed, or exhausted either. You need the intensity, that drives teams to work around the clock, to spark creativity. I have found two days is normally a good choice, since lots of great things can be done overnight. However, if you are trying to tackle issues that involve production, such as cost reduction, extra deployment delays should be considered.
- Rules: what should everyone build? how they should work with each other? Is there going to be a presentation at the end? Does everything need to be implemented? Does it need to be deployed to production? What is each team members’ role? Will designers work across teams? Who can help if people encounter difficulties? Establishing those rules in advance can help you create and support a lot of small teams in a short amount of time.
- Location: a hackathon is normally more productive if people work together. This means you may need to arrange travel for those who work at other offices. People normally work late into the day during a hackathon. Is the space you plan to host in comfortable enough for a large group of people to work overnight? Do you have food, service, and security available after hours? Those are mostly logistical concerns, but they can be critical to ensuring that things run smoothly.
- Social: for large hackathons, especially cross-organization and public ones, participants may not know each other well (or at all) before participating. They will need to go through the forming, storming, norming and performing group processes in a short period of time. Hence, the more social opportunities you can create before the event, the easier it will be for individuals to perform effectively as teams together later. To facilitate this, I normally share an idea sheet weeks in advance to get ideas circulating, I also organize several brainstorming sessions before the hackathon; and on the day of the event, I invite participants to give short presentations about their work.
As with every other system, a good design can be scaled up. I have been trying to imagine how large a hackathon can be and what kinds of problems such an event might address? How would all of these factors come together? I definitely plan to do more in-depth research on this topic.
Have you attended a hackathon or been involved with planning one? Share your stories (good and bad) with me below. 😊