IN THIS ARTICLE:
- Enterprises large and small are using hackathons to increase employees’ learning and find new revenue opportunities
- Hackathons can result in unexpected innovations, broken down siloes and new possibilities for technology within an organization
Today, when a company’s ability to pivot and adjust to lightning-fast changes in the marketplace can mean the difference between success and irrelevancy, speed is of the essence. But no enterprise can expect to keep up with the competition if its own employees are saddled with outdated skills. That’s where a new breed of hackathon comes in. At once intensely competitive and highly collaborative, many of today’s hackathons are not only designed to result in new products, apps and code, but to impart new strategies and know-how to the participants.
In this interview, Hewlett Packard Enterprise’s Sean Hughes talks about why hackathons often result in unexpected innovations; how the challenges inherent in these high-pressure, high-spirited get-togethers reflect the hurdles that developers face every day; and how open APIs and hackathons might, in the end, help make the world a better place.
When most people think of hackathons, they picture them taking place in an academic or startup environment. But these days all sorts of companies are using them as a way to reinvigorate their teams. Why?
The trend we’re seeing is that companies are looking to accelerate the pace of their employees’ learning internally through business-focused coding challenges, because they understand that rapid innovation can lead to new business models and revenue streams. These hackathons also give developers real-world experience with the latest tools and technologies. Above and beyond those goals, though, the hackathon format is a lot more fun and a lot less formal than traditional professional training or enrichment efforts. Done right, it’s a very cool way to reignite a culture of innovation. Unlike formal training programs on, for example, a new software package, a hackathon is a really low-cost investment that can lead to incredibly rapid prototyping of new products and proofs of concept.
What’s the usual time frame for these hackathons? How long do they last?
They come in many formats. It can be a hackathon sprint, where in eight hours the participants try and cram something together. But honestly, chances are good that you’re not going to get a working prototype in that amount of time. Traditionally, there are about one or two days’ worth of coding. What’s notable is that in the midst of this experience, developers get to move from pure ideation all the way through to rapid prototyping. They’re testing ideas and trying to implement them to complete a working, usable app within a severe time constraint. Of course, at the end of it, they have to use their expertise and market insights to pitch their app and convince the judges that what they’ve built is genuinely innovative and viable. And remember, in a hackathon for in-house developers, they have access to proprietary knowledge, systems and data, which helps make the outcomes relevant to the enterprise. That’s obviously important because it means the apps are likely to meet the business objectives of the company while the participants benefit from the team-building and rapid-development experience.
Speed is clearly a major component of these events, but the end result has to be relevant to the stated theme or goal of the hackathon. Do you think that sometimes participants err on the side of speed to the detriment of relevance?
With an enterprise hackathon, the teams are acutely aware of the need for relevance, particularly with their organization watching. Keep in mind that speed is also affected by other factors. In fact, quite often at these hackathons, the tools that developers use or the platforms they’re working with can raise barriers to the speed at which they finish their hack. They might start a project with a very strong idea about what they’re going to build, but then they’ll get three or four hours in and realize that the platform they’re using isn’t really up to the job. It’s too complicated or there’s not enough documentation associated with it. So the tools are really important and have a real impact on how fast the developers are working. These speed bumps can certainly impact degrees of relevance for the app, as key features may not be completed before the deadline.
That said, it’s amazing how often these hackathons result in genuine innovations. We see entirely unexpected mash-ups of new and old technologies. And all of this breaks down barriers and highlights the fact that technology today is so open and so accessible. Every solution provider, every platform provider effectively has an open API, especially if they’re going after developers.
Do hackathons reflect, at any level, the day-to-day experiences of developers?
Developers are a tough crowd. They’re the new decision makers in a lot of ways, even though they might not have budget responsibilities. They have to come up with innovative ways to tackle really hard problems on what are often ridiculously aggressive go-to-market schedules. From a platform provider’s perspective, we have to make sure that our capabilities can solve exactly the sort of problems that developers run into at these hackathons. And these capabilities have to be well documented, intuitive and, more important, self-servicing. With hackathons, we get a chance to understand the pains that developers are going through as they try to innovate in the event itself and in their day jobs.
This is probably an unfair question, like asking a parent to choose a favorite child, but what’s the coolest or most surprising application to emerge from the hackathons that you’ve been a part of over the past year or so?
That is tough to answer, but I’ll tell you about one that was definitely impressive. At a university hackathon earlier this year, in which the focus was on international development, a group of students from Harvard ended up winning first prize. The app they built took a bunch of data from the government of Tanzania that was in the form of paper documents that had been scanned and converted to PDFs—“dirty PDFs,” we call them. The students used HPE’s optical character recognition API to extract text from the PDFs, analyze the text and create visual charts of the data. That led to the discovery of some really questionable spending by certain parts of the government with huge expenditures—something like 60 percent of the total—classified as “personal” or “miscellaneous.” This app was all about making it easy for citizen journalists who aren’t necessarily developers themselves to use APIs and tools to help them hold their governments accountable. Yeah, I definitely love that one.