What makes hackathons work
Steve Kelman share recent research on how successful hackathon teams turn out functioning products.
If you work on IT in the private sector, especially if you are at a small firm or actively involved in open source projects, you may have had experience working on hackathons — a word whose semi-outlaw connotations give a feel for how these are nothing like business as usual.
Hackathons are sort of like agile software development sprints on steroids. They are time-limited events — often but not always three days — where a small team stops everything else they are doing and works fulltime (sometimes around the clock) to develop some new product on deadline. While hackathons are associated with the private sector, there have been occasional hackathons in government, at NASA, the General Services Administration, Department of Veterans Affairs and elsewhere.
Think of hackathons as the polar opposite of the sadly typical pace of software development in government.
Three business-school based management scholars — Hila Lifshitz-Assaf of New York University, Sarah Lebowitz of UVA,, and Lior Zalmanson of Tel Aviv University — have written an article on hackathons in the Academy of Management Journal, the premier management journal publishing empirical work. Titled Minimal and adaptive coordination: How hackathon projects accelerate innovation without killing it, the article explores how to increase the chances that a hackathon will actually produce a working product.
The authors looked at 13 design challenges, all involving technology, that had to be completed within 72 hours. Members of the teams had never met before. Each team was provided with the same tools (such as 3D printers, laser cutters, and electrical equipment). The teams were all left to their own devices in how to organize the task.
At the end of the hackathon, 3 teams had created fully functioning products, another 3 produced products that were functioning at a basic level, while 7 were unable to come up with a functioning product at all.
What were the differences between the successful and unsuccessful teams?
The seven unsuccessful projects tried to develop a full-blown plan for organizing and coordinating their efforts before starting to work, with the idea of recalibrating the plan when problems arose. They used past experience on organizing projects without compressed timelines as a basis for developing their plan for a hackathon, basically doing what they had always done but faster. These groups also planned in advance some specific measurements and features for the product being developed.
The other six projects did not try to establish coordination processes or temporal sequencing in advance. They assumed that a hackathon should not be organized like other projects.
Three of these projects (which the authors call “adaptive coordination”) started with few developed approaches but gradually developed them over time based on experience. Three kept efforts to coordinate minimal throughout the process, and the teams mostly worked in parallel in groups of two.
These different approaches had very different hackathon results. The seven fully pre-coordinated projects all backfired when unexpected difficulties arose. These teams sometimes continued with their pre-developed approach nonetheless. By contrast, the three adaptive coordination projects all produced working products. The minimal coordination projects were in between, producing partial products that had some features but not others and were not integrated into a whole.
The lessons here, I think, don’t apply just to hackathons but to project management in government in general. Trying to plan everything in advance — an approach often favored in government because of its seeming orderliness — does not work well. An evolutionary approach, where the aim is not to start with a well-developed plan but to encourage one to emerge over time based on experience, works much better.
Project managers, listen! This is practical advice.
NEXT STORY: Quick Hits