An ​internal hackathon​ can be a great way to increase developer engagement, explore new product ideas, build relationships, and find new leaders. Here are a few things we’ve discovered that help to make ours a success.

Tip 1: Excite your leadership!

It’s hard to get team engagement without meaningful involvement from leadership. One way we’ve done this is to start at the top: our CEO, CTO, Chief Medical Officer and Senior VP of Product are all judges for our hackathons. ​This shows the team that our leaders take the hackathon projects seriously and it gives team members direct interactions with execs that they might not otherwise have on a regular basis.

As part of planning, we ask ourselves which other executive judges will provide new perspectives we want to incorporate. For example, after our Fall 2019 Hackathon, some of the planning team felt that the projects had gotten “too inside the box”: projects were too close to the product roadmap, and weren’t exploring more strategic opportunities. So I asked our VP of Corporate Development and Strategy to join the panel, explaining that we wanted him to encourage more “out of the box” thinking and contribute feedback reflecting his unique market perspective. He jumped at the chance — every executive who has participated has talked about how much fun it is to judge — and is now one of our most enthusiastic panelists.

Tip 2: Empower your Hackathon Planners

When Wade Chambers took over as CTO in early 2018, one of the earliest conversations he and I had at his staff meetings was about planning for an upcoming hackathon. While GR had held them previously, Wade helped to formalize the process and goals and then delegate the rest of the decision-making to the planning committee. With Wade’s direction, we agreed upon a few guidelines:

• We established a fixed budget for hackathon direct expenses (awards, meals, etc).
• We kept the hackathon planning team that had already existed, but formalized it a bit; in particular, we decided that I should guide it and provide updates in Wade’s staff meetings.
• We added the hackathon into our quarterly planning framework (​OKRs​).

With that done, the hackathon team was able to run with the rest of the planning. One further thing happened: Wade’s executive assistant became a key participant, helping to manage the budget, directly handling catering, and bringing important perspectives of her own.

Also, Wade, like many of our colleagues, brought some hackathon approaches with him. An important technique we got from Tellapart / Twitter was to split the “hacking days” from the “judgement day” by a weekend. If teams want to go “above and beyond” by hacking or working on their presentation over the weekend, well, there’s nothing stopping them. For all of our recent Hackathons, we hack on Thursday and Friday, then judge on Monday afternoon.

Tip 3: Go wide

We’ve run hackathons internally for almost as long as we’ve had engineers. Our earliest one was very focused: in early 2015, with an engineering team of only about 20 folks, we ran a one-day hackathon of six teams in conjunction with our (then-separate) data science team to determine the best storage options for large-scale data ingestion (and query).

While that was OK (and at least got us to do something outside our “all AWS all the time” thinking), it was too directed and not nearly enough fun. Only a few folks thought way outside the box, and their projects, though ambitious, didn’t get any real evaluation. It was more of a quick bake-off than a hackathon.

In more recent hackathons, we’ve deliberately made the range as wide as we can. We do this in three ways:

1. We have a lot of award categories​, with awards aligned with our business values (“Put Patients First”, “The Sarah Josephine Baker award for Patient Health Outcomes”…) and others for technical qualities (“The Nikola Tesla Award for Cool Tech”). The most important one for getting people to go big is the “Wile E Coyote” award for most audacious — and usually “failing” — project.
2. We encourage every technical organization inside Grand Rounds to participate​: not just our “Engineering, Product, and Design” (EPD) group (which now includes Data Science), but data professionals from our various analytics groups, IT, infosec, customer solutions engineers, and product support engineers. While EPD provides the budget and the structure, many award-winning teams are either formed from, or include, people from outside EPD.
3. Our CTO and I spend significant time encouraging managers both inside EPD and in the other organizations to participate in our hackathons​. Sometimes scheduling pressures will convince a manager to not push their team into hackathons — but the normal competitiveness of managers usually brings them back. (“My team had 3 hackathon projects go to production last time; did any of your folks even show up?”)

Tip 4: Structure the presentations

Some of the most heartbreaking problems that have happened in our hackathons have been caused by great projects having terrible presentations. In the worst case, a team didn’t acknowledge the team member that had easily put in the most effort on the project, including a massive over-the-weekend sprint. We eventually lost that employee. From that lesson, we’ve made it clear that presentations ​must:

• Thank every team member
• Identify the impact of the work: who benefits and why
• Only then, demonstrate the work
• Fit into a time limit (in our most recent, 5 minutes of presentation)

We also set up sample Google slide presentation templates with outlines like the above. However we found that while the templates helped focus peoples’ minds, they constrained their creativity. For our latest event, we’d lost our template, so we simply put the bullets above into my kickoff talk and presentation. Since this was our first virtual hackathon, we encouraged teams to meet the 5 minute limit by preparing videos for their presentation, rather than doing live presentations. We did ​not​ give any guidance about how to prepare the video.

That worked out ​fabulously​. Our teams were much more creative about their presentations and got their points across in entirely new ways. We even lucked out: the first presentation (by luck of the draw) turned out to have an absolutely delightful “hand-writing on whiteboard” animation style and quirky background music. It immediately engaged the audience, and all of the following presentations benefited from that engagement.

Tip 5: Establish a pipeline to production

We’ve always had an emphasis (sometimes too much of one) on projects that were easy to see as priorities for the company to follow up on. For example, one of the award categories is “Ship it!” for a project that is obviously something we should have put on the product roadmap anyway and appears to be ready to go. Over the years, many features big and small have started as hackathon projects.

But for our most recent hackathon, we also created some space in our quarterly roadmapping process for taking ideas directly from hackathon and into the backlog. We did this in our EPD staff meeting: our CTO put an item on the agenda (without my prompting!) to ask managers which projects they expected to take to product. Note the wording. We now have 10 of our 20 projects either in active planning or being considered for the first calendar quarter of next year. (And, formally, getting this onto the agenda after the hackathon is my job; I just lucked out this time that Wade had put it out there before I got to it.)

That brings up timing: when should hackathons be held? Ours have settled into a good place. First: we hold two a year. Having them more often would make them less special, and also turn them into a normal part of project planning. Doing only one a year, though, risks people not getting to participate because of vacation schedules or sick time.

We want to hold them at about week 8 of our quarter, so we can take at least one ambitious project into the next quarter’s backlog. Here in the US, we have a couple of handy 3-day holiday weekends that work well: Presidents’ Day and Labor Day. We schedule our hacks for the Thursday & Friday of those weeks. Since it’s a short week anyway, managers don’t expect as much normal team productivity, and this makes for a nice, regular cycle everybody can get used to.

Conclusion

Our hackathons have been hugely successful and continue to get better every time. Our CEO has exclaimed “this hackathon was our best ever!” after each one. Our operational groups are clamoring to get their own people involved. And many of the projects go on to be successful product features — or even whole product lines. There’s even a case to be made that our whole “navigation” suite (now the main direction of our company) was first detailed as a hackathon project.

I don’t know that the 5 tips above are the most important parts of doing that. I’ve left out other important actions that also have great impact, like the following:

• Bring in a designer early so you’ve got great graphics all the way through.
• Theme your hackathon. For the Fall 2020 Hackathon, we used “Everything is Awesome!” as an ironic comment on 2020, and it was immediately resonant.
• Don’t feel compelled to require “working code.” Sometimes a great mockup, or even a bit of theater (that navigation prototype) can be hugely influential.
• Feed the teams! If you’re holding your hackathon on site and you don’t already cater meals, it can be a great treat for your team to cater breakfast, lunch, and maybe Thursday night dinner for teams working on-site.
• Give away good swag! We’ve always done T-shirts, but with everybody working remotely, we pivoted to custom Lego kits for the latest one, and that went over very well.
• Bragging rights are their own reward. We tried using a cash (well, Amazon gift card) award for “Best in Show” once; it encouraged teams to be too big, and discouraged small teams and off-the-wall ideas.
• Stay adaptable! Every hackathon will have its own challenges. Ours are now so successful that having a single panel sit through and judge all the presentations is taking more time than we can afford on a Monday afternoon, so our next hackathon will have to change. I’m looking forward to what our planners come up with to respond to that scaling challenge.
• Stay true to your company values and culture. That’s a big part of my job as a staff software engineer, and it’s a huge part of how hackathons stay relevant at Grand Rounds.

Happy hacking!

PS: Thanks!

Taking my own advice, I’d better acknowledge the Hackathon Planners that have improved our hackathons over the years. Working from memory and barely-maintained archives, I’m sure I’ve missed some. For that I apologize, but thanks to all of my colleagues, past and current, who have made a huge difference in our events:

• Alain Bloch
• Andrew Sandler
• Ben Liyanage
• Beverly Thornton
• Brian Chamberlain
• Casey Patterson
• Charles Guo
• Etienne Tripier
• Jake Burton Denmark
• Japheth Gonzales
• Jayodita Sanghvi
• John Schrom
• Kat Henning
• Ken Berland
• Krystal Barclay
• Madeleine Cule
• Mary Reynolds
• Matt Frey
• Maureen Sellers
• Meg Marvin
• Morgan Meinert
• Richard Stanley
• Shuvayu Kanjilal
• Stacey Anker
• Stephen Hitchner
• Steve Martin
• Will Roller