Innovation is a critical part of any business, particularly a software business. However, as we know from Clayton M. Christensen’s book The Innovator’s Dilemma, it is hard to innovate in a large company. The challenge is that many innovations will disrupt the existing revenue stream. But without innovation, the revenue stream will inevitably end. To remain a viable business, innovation needs to be fostered and adopted, even at the risk of short-term self-disruption. One way a growing company can remain innovative is by encouraging engineering teams to innovate through hackathons. A hackathon is a short period, usually twenty-four hours, during which a group of developers collaborates to write some software very fast. The aim is a high-energy drive to proof out ideas or build a rapid prototype. The events usually run on a diet of caffeine and pizza. The hackathon participants each bring their own ideas, and the group together decides which ideas to pursue. The developers form their own small, temporary teams to work on their chosen ideas. At the end of the hackathon, each team reports to the whole group on its idea and the progress it was able to make. This type of brief but intense activity is invigorating for the creative side of software development. Participants typically work all night with few breaks in order to build as much of the idea as possible. This rapid development of a new idea is usually a welcome break from the normal software development processes of bug fixing and QA testing.
A hackathon is also a low-risk way to get the skeleton of a new feature or product. Far less total effort is required than for a more slow-moving product development methodology. The requirements and success criteria are quickly agreed upon, and focus shifts to building the software. Generally, the ideas are drawn from the team members’ own experience rather than from a structured product management approach. At the end of the hackathon, the basis of the idea will be proven or disproven. A lot of work usually will still be required to make the idea into a real product or feature. In some organizations, hackathons are used to prove that the company supports modern program methodologies. They have no intention of actually using the ideas generated by a hackathon. Other organizations use hackathons to return to their startup origins.
I spoke with Rob Strechay, who is vice president of product at Zerto, about the hackathons that Zerto runs. The conversation was triggered by Zerto’s new mobile reporting interface. In an earlier briefing, I was told that the mobile interface came from last year’s hackathon. It turns out that Zerto’s management team members are believers in hackathons as part of the innovation process and the company culture. Both the founders, now the CEO and CTO, are involved in the hackathons, although not necessarily by writing software themselves. The hackathons have a festive atmosphere. Support staff work shifts to make sure the developers have everything they need to focus on proofing out their ideas. I was impressed that three of the five ideas from last year’s hackathon are making their way into the product. The most visible is the mobile reporting app, a whole new way of interacting with Zerto’s products; many other ideas are less visible, yet no less important. The new release of Zerto’s product has some significant performance improvements for replication. It sounds like some of that came from a hackathon idea. Another interesting aspect of hackathons is staff whose career development is aided by it. A support engineer who took part in a hackathon, for instance, has since transitioned into a quality assurance role.
It is the use of hackathons to elicit innovation that I like the most. As companies grow, it gets harder to innovate. Yet without internal innovation, external disruption is inevitable. The very processes and ways of thinking that produce software with enterprise reliability are at odds with the rapid change and trial that are part of innovation. Innovation requires an empowerment of technical staff to create something new and different. It is very different from the usual product development approach, in which the writing of software plays a small part. Requirements gathering and business case planning dominate product development.