Hackathons have been a part of Flatiron Health since the company was founded in 2012. Our Chief Technology Officer (back then, Flatiron’s second engineer) Gil Shklarski brought the concept with him from his previous stint at Facebook. For Flatiron, our quarterly hackathons are meant to be two days free of meetings or sprint commitments for the whole company, where employees form teams to work or “hack” on something that they are passionate about, but just haven’t had the opportunity to work on. This could be exciting new product features, radical code cleanup (“dev happz” or, as Gil refers to it, “fixing s**t liberally”), cutting-edge data analyses or the occasional “gotcha” experiment from our security team. Each hackathon culminates in a live-demo session where participants have three minutes to present their projects in varying states ranging from “duct-taped together” to polished and ready to go into production, and then everyone at the company has the opportunity to vote on their favorite hacks in different categories.
Over the past few years, as Flatiron has grown, our hackathons have grown with it — from a handful of small hacks to a large, company-wide event spanning almost three days with over 40+ hacks presented at each final demo event. We have found these hackathons to be an important part of our company culture that have significantly shaped how we innovate and collaborate.
As we host our 16th hackathon this week, we wanted to share our top five reasons why we love running hackathons:
Hackathons encourage cross-functional collaboration
One of our favorite aspects of running and participating in hackathons is the ability to collaborate with people you usually don’t get the chance to work with. Flatiron’s hackathons may be different from those run by traditional tech companies, as we very much encourage non-engineers to participate — we firmly believe that bringing in different areas of expertise can be hugely beneficial. While teams at Flatiron already make up a number of different functions, including engineers, designers, quantitative scientists, and often oncologists and clinical staff, joining a hackathon team with an entirely different focus than your day-to-day is often eye opening, allowing you to see the work you do in a broader context. For example, we brought our informatics, clinical, data engineering, front-end development and marketing teams together to build a new trial finder for Fight CRC (read about it here). We love cross-functional collaboration so much that we introduced the “Best non-coding hack” as well as the “Best collaboration” award categories.
Hackathons allow anyone to innovate in anything
As customer commitments increase and the breadth of the company has grown to many different business lines, it’s only natural to become focused solely on one’s own responsibilities and near-term customer commitments. We encourage our employees to use the hackathon as way to step outside of their day-to-day role and use their creative juices to work on whatever problem they believe is worth solving. Most importantly, a hackathon provides an outlet for people to quickly spin up a minimum viable product or a demo to spur conversation without needing to talk in the abstract or request resources. We’ve seen amazing new products ship from our hackathon, and time and time again it is stimulated from a diverse group of functions and initiatives.
Hackathons help develop those “soft” skills
As has been written about by many successful engineers (most recently, here), we know that being a good software engineer doesn’t just require good technical skills, but also what many usually call “soft skills” — the ability to collaborate, empathize, present and even sell an idea. Within a hackathon team, engineers often take on the role of product manager as well as project manager, where they have the chance to learn to radically prioritize different parts of the project (two days go by pretty quickly!), navigate disagreements on the team and give a compelling three-minute pitch. Especially for engineers who might often be heads down in code, hackathons are an amazing opportunity to step up and get themselves out there in a low-risk environment where everyone is in the same position of learning and possibly failing — see the next point!
Hackathons celebrate failures that can lead to even bigger successes
Some projects fail hard by the end of the hackathon, but these failures should be celebrated just as much as successes. Since our first hackathon, Gil has encouraged teams to keep Facebook’s motto in mind: “What would you work on if you weren’t afraid?” Celebrating failures also creates a culture in which teams are encouraged to stretch boundaries of what was thought possible, and in turn, successful projects often then yield larger rewards. However, creating this culture of intense innovation and experimentation requires an acceptance that some projects will fizzle out after two days for many different reasons. While these projects may not make it out to our customers, they still provide learnings. Spending two days learning that a product idea is not feasible, a new technology doesn’t meet its promise, or that current infrastructure won’t support a new use case, are all highly valuable and important learnings that will ultimately drive your engineering organization forward. At Flatiron, we encourage teams who have worked on failed projects to still present their demo at the end of a hackathon.
Hackathons improve upon the “20% time” concept
We love the concept of dedicating 20% of each person’s time to working on side projects that spawn exciting new product lines — but let’s be honest, especially in a growing company like ours, it’s usually all hands on deck to push a new feature, fix a bug or carefully orchestrate changes that affect several teams. Dropping all these responsibilities one day a week to work on a passion project is simply not always possible. Hackathons give us two or three days of undisturbed time where we de-prioritize sprint work and staff engineers to keep the lights on, but otherwise really try to give everyone the opportunity to experiment, explore and collaborate. This focused burst of activity once per quarter is easier to schedule for the entire company; and since everyone participates, it’s also easier to find people to collaborate with. There is also the added benefit of getting your idea immediately in front of the entire company and leadership team during the demo sessions. And just as with 20% time (which famously gave us Gmail), we have had several amazing hacks developed. One of our most successful product features — Document Search — was actually conceptualized and prototyped during a hackathon. Read more about it in this Fast Company article.
While hackathons may not be the answer for every company, Flatiron has found them to be incredibly valuable both to our culture and to our business. They have helped encourage cross-functional collaboration, allowed people to stretch themselves professionally, helped with soft skills development and much more.
In our next blog post, which will be published in the next few weeks, we will lay out a few best practices for running a successful hackathon.