At their best, internal hackathons provide a necessary patch to systemic problems. But their usual structure limits their potential.
What hackathons do best and why
The most valuable output of a hackathon is often a self-contained tool, the solution to a long-lived bug, the testing of a new system, etc. What they have in common is that they are
useful things...
that developers knew are useful...
but couldn't be fit in "non-hackathon time..."
because they weren't deemed urgent or valuable enough by managers.
"Hackathon regret" is a very rare phenomenon: a good hackathon generates good outcomes. But it generates good outcomes that should have already been generated as part of day-to-day operations. They are best seen — at their best — as a temporary flicker of authority that allows developers to minimally compensate for management blind spots.
What hackathons don't do and why
Hackathons rarely lead to useful innovation. This is, as they say, an unpopular opinion. Let me justify it along two dimensions: direction and reach.
Direction: Left to their own devices developers will create tools or fix problems relevant to developer productivity and well-being. Which is good! As I wrote above, those are issues that are often deprioritized due to lack of visibility, not importance. But these tools and fixes are almost never competitive innovations. Very few development teams have such a good environment that, given time to work on what they choose, can afford to aim for the sky. And even if they did, developer productivity is not the competitive bottleneck for most companies.
Reach: A team can develop quite an impressive MVP during the span of a hackathon but — and this is key — you cannot develop a minimally viable version of every innovative idea. There are novel ideas that simply require a lot of work even to get to the barest demo because they depend on concepts and techniques that don't yet have the sort of tools and libraries that make familiar MVPs so easy to build.
In short: the outcome of a hackathon will rarely be very original (the very original always has at least some strange component that has to be built the slow way) and it's far more likely to solve a developer problem that should have been already solved rather than offer a fresh idea for a competitive constraint.
Putting the 'hack' back in 'hackathon'
For a hackathon to generate the sort of innovative idea organizations want requires a different mix of people, with specific attitudes and goals, acting in concert:
Begin with a Business Red Team tasked with identifying core problem(s) to work on ("unexploited opportunity open to competitors" being a type of problem as well). There are two roles for this team. By beginning the analysis from scratch it might identify issues not currently on the company's radar, and even if the issues are known this team can ensure that the hackathon is focused towards high-value problems. For this to work the Red team has to adopt the adversarial attitude of a short-seller making a case, something that isn't always psychologically easy and can often be politically risky for their careers. Setting up a Red Team able to do the job, with political cover reliable enough for them to be willing to do it is the hardest part of any hackathon. It's also the most valuable, and would justify the time spent even if there were no other output.
That takes care of direction. To give the hackathon reach, the problems identified by the Red Team have to be first tackled not by developers writing an MVP but by a Sci-Fi Team coming up with potential solutions. Sci-Fi isn't Fantasy: the team has to have the right background to balance deep knowledge of the problem and an active imagination to give them a chance to come up with novel ideas that might work out. But they shouldn't be limited by the expectation of building something they can demo or even fully describe before the hackathon ends. Their job is creative ambition.
Of course, solutions that can't be built are of limited immediate value (but not zero — the idea that can't be built might inspire the thing that can). The final element of the hackathon is an Engineering Team. Their role isn't to build anything, though. Rather, their goal is to study the idea from the Sci-Fi Team to figure out whether can be built and what it would take to do it.
These three teams do not need to be entirely different sets of people: in a pinch, or as an experiment, you can even try doing all three things yourself. What matters is the need for different attitudes and skillsets at different points of the process. A cold eye for vulnerabilities to identify the problems that matter. A combination of imagination and knowledge to come up with original solutions. Expert pragmatism to judge their feasibility. It's almost impossible to do all of this at once - doubly so to do it well. Under time and resource constraints people will focus on the problems they already know and come up with relatively conservative solutions because they are also thinking, consciously or unconsciously, about how they'd implement them.
Coming up with innovative solutions to important problems is far from easy and never certain. By structuring a hackathon in a way that reflects this complexity and putting in play the very different skillsets and approaches necessary along the way, organizations can improve the odds of the kinds of outcome that hackathons are meant for.
(Originally posted on my blog.)