How to Hackathon: Where Experimentation Mindset Meets Rapid Action

I was pretty nervous. A handful of Eppo teammates—engineers, data scientists, marketers, and our founder and CEO—eagerly huddled around a widescreen monitor in an office in San Francisco. A similar scene was unfolding at a teammate’s house in northern Virginia. Sprinkled across the globe, a dozen other teammates were all virtually tuned into the same meeting: Eppo’s first hackathon presentations. 

People were about to present what they worked on the past two days. Would this remote(ish) hackathon–Eppo’s first–that I advocated for and organized be a success? Or would it be a flop? I’d find out in the next ~90 minutes.

(You’ll have to read on to see how it turned out…)

There’s a wise maxim that gets passed around Eppo: “Everybody in business is always running experiments, it’s only sometimes that we’re randomizing units and measuring outcomes.” In other words, just because you aren’t running an A/B test doesn’t mean you aren’t experimenting to find out what works. Hackathons are the perfect example: putting aside our carefully crafted roadmap to tinker for a few days and see what we learn.

I’ve even been experimenting with the meta-level of how to run hackathons over my last few roles. I’ve tried plenty of tactics and approaches in the past that I didn’t bring to this first swing at Eppo: making the entire duration of the hackathon 24 hours, incorporating some sort of “late-night surprise,” and having judges and voting and awards around the best projects. This was also my first hackathon at a remote-first company, so there were some new hypotheses and approaches I threw into the mix. 

So, what exactly did we do? I’ll break that down below! Every organization, team, and situation is different, so these steps don’t guarantee results. But they will give you some ideas and add tools to your figurative toolbelt, so you, too, can have a great first hackathon or expand on the ones you already have.

1. Define the goals

To get organizational buy-in, the hackathon's goals needed to be clearly stated and understood. While it may be fun, we wouldn’t want everybody working on Tinder for cats. On the other hand, we wouldn’t want people to work on things that were part of our regularly scheduled roadmap either. The sweet spot is in the middle. We identified that sweet spot by defining a mission, describing what we wanted to get out of the hackathon, and outlining what success looks like. We then shared that with the relevant leaders to get the green light.

‎Like most tech organizations, people are our biggest operational expense. Having everybody go off and work on whatever they want is thus very expensive for a company. And that’s before you factor in any travel or food that may be involved. Because of this expense, we needed approval.

Luckily, our mission, motivation, and definition of success helped make it clear to leadership that it was worth the investment, and we got the green light. Promoting building a muscle for innovation from the trenches and adding value to Eppo was hard to argue against! 

2. Align on logistics

After getting buy-in for the general idea, the next step was to decide how we were going to do this hackathon. When should we do it? Should it be an intense 24-hour push or a multi-day event? Should we all get together in one spot or work distributed like we normally do? Is it just for engineers or the whole company? What would the schedule look like? Should we hire clowns to come in at 9:00 pm and cheer everybody up with balloon animals? There are lots of details to iron out!

Working with another seasoned hackathon participant, we had strong opinions about what we thought would work best. However, rather than make decisions from our ivory tower, we solicited input from the team and distributed a short survey.

‎The survey results had some variation–as expected–but clustered around a few key points that, much to our delight, were close to what we thought we be best for our team:

• The responses for the time of the year to do it were fairly diverse, with Q4 being the strongest preference, followed by Q1
• There was a strong preference for a ~3-day-long event
• There was an overall preference for in-person collaboration
• There was a heavy bias towards no formal rules
• About half of the team didn’t have any ideas in mind already, while half did

Using this, we formulated a more concrete plan and got it approved. At the next company all-hands, we prepared a few slides and presented them to the entire company. They included the finalized logistics, the survey data that helped lead to that, and general hackathon tips. While starting with a survey and presenting its results along with what we decided on doing was extra work, it helped solicit input and get buy-in from the team.

‎
3. Hype it up

We could tell that many people were unsure what was coming and what to do. Especially those who were not engineers or had never participated in a hackathon before. To help drive engagement, we did a few things leading up to the hackathon.

First, we made a deck where people could drop ideas. We pre-seeded it with some of our own to help demonstrate what we were looking for and highlighted it in our launch presentation.

‎Then, I and the other seasoned hackathon participant scheduled quick (30-minute) small group meetings with everybody in the company. It helped that, at the time, we only had a bit under 30 people at Eppo. During these meetings, our goal was to have each participant generate at least one idea to put into our deck. We’d quickly re-iterate the key points of the hackathon, list off a few example ideas, and then ask probing questions like:

• “What is the worst part of your job right now?”
• “If you could wave a magic wand and make a change at Eppo, what would it be?”
• “What did you have at a previous organization that we don’t have here that you miss?”

We’d then help them transform their answers into an idea and work with them to make a slide. The meetings were very successful, and after a half hour, each participant would usually have multiple idea slides generated.

In subsequent all-hands, we’d re-plug the hackathon and ask folks to peruse and comment on the deck. Some ideas got more attention than others, and people started coalescing around some of the ideas. This asynchronous ideas chatter was a lightweight way to help teams form in advance of the event so that they could hit the ground running when the time came.

4. Low-touch execution

The leadership mantra of “hire great people, then get out of their way” applies to hackathons as well. Our hackathon had a loose agenda: A kick-off meeting, team dinners, and final presentations.

‎Per our logistical decision of Eppo-supported in-person pods and dinners, many people organically organized into coworking groups. All our DC-area engineers got together to work in person during the day and eat dinner together. A few others and I, closer to California, flew out to our office in San Francisco and worked from there. Others worked from home as usual.

We only had one rule: “Every team must present at the end.” We started things off with an all-hands hackathon kickoff meeting, reiterating the key points and what success looks like (you can never go over that too many times). We wouldn’t get together again as a full group until the end. However, we did have asynchronous announcements in Slack. The usual requests for help, pairing sessions, etc., took place as well.

The projects themselves were worked on by small teams or solo, and generally fell into three categories:

• Tactical Strikes: small, practical, and ready to ship
• Exploratory: proof of concepts, prototypes, exploration of new tools and technologies whose learnings will be inputs into future decisions
• Culture-building: zany and fun, enriching our culture 

A good hackathon produces projects across all three categories. The distribution of projects between these categories ended up being what I (and many others) thought was a great balance, with about 50% in the first category, 40% in the second, and 10% in the last. 

5. Presentations

Leading up to the hackathon, we pre-scheduled a 90-minute demo meeting, so it had been on everybody’s calendars for weeks. We told each team they should aim for five minutes, but in reality, they had closer to ten–which is good as people historically underestimate how long it will take to present, especially including fielding questions.

We shared the blank presentation deck the day before, and teams soon started adding and crafting their slides. The general vibe of the deck indicated we cared more about content than presentation polish, removing pressure. Humor, memes, gifs, etc., were abundant. Several teams opted for live demos as well.

Here’s the play-by-play of how our presentation actually went: 

The first demo was of new useful filters for our list of experiments. This simple change is immediately ready to be deployed to add value to our customers. The next demo was a tool that automatically segmented metric changes by the properties of an entity and surfaced cases where one segment reacted differently than the test in general. For example, it would point out where a test variation performed better than the control overall, but not for a certain subset of users. It worked well, and it was immediately obvious how this could be useful. With a little design polish, it was ready to be deployed in the near future. The third demo leveraged AI to automatically map columns of a table to their usage in the Eppo platform. This was exciting as we’re on the lookout to explore ways to leverage AI, and this was a great one!

‎Ten more demos ranged from things ready to deploy at that moment to proof of concepts and prototypes to guide our future decision-making. Non-engineers participated as well, demoing ideas for a redesigned blog, potential integration of a new onboarding tool, and even custom Slack emojis of our pets.

After the demos, everybody was already asking when we could do the next hackathon. 

‎6. Follow Up

After the demos, our Head of Product worked to ensure things that needed a bit of polish to be deployed got the space needed in the upcoming weeks to make that happen. He also created tickets in Linear and pages on Notion–our issue tracking and collaboration tools of choice–for the proof of concepts and prototypes. These included what he imagined were the appropriate next steps, and were linked with any relevant already-planned initiatives.

‎Already, the whole company is on board for another hackathon. We’ll likely reuse many of the tactics discussed above and probably try some new things. Hopefully, these tactics will be useful to you, too. I’m looking forward to future hackathons!

‎