Hackathons: Don't try them if you don't like risks
Rules and tools to get the most out of your pizza-replete staff
When organisations grind to a halt, weighed down by their own bureaucracy, inertia and politics, they flail about for something to give a short, sharp shock to their vitals. Something to get them moving again.
The techniques used to get things humming along again have varied over the years – a rogue’s gallery of specious business trends and fads. Twenty years ago, it might have been role playing. Ten years ago, an offsite with those cringeworthy trust-building games.
Today, we turn to hackathons.
Until quite recently, hackathons were the exclusive preserve of the tech startup community, thriving on the 48-hours-locked-in-a-room-together intensity followed by the near-orgasmic release of a great pitch. Suddenly, both big business and big government, in a collective penny-drop moment, have adopted the hackathon methodology to inspire employees and capture innovative ideas.
That should be making us suspicious. The purpose of a hackathon is to create a space so unconstrained by conventional wisdom as to be truly disruptive. Owing nothing to anyone, participants can be free to ‘think different’.
That’s the theory, anyway – but I doubt anything would be more terrifying to a big organisation. As much as we might hate bureaucracy, it’s a great way to herd cats, and bureaucracies rein in the natural tendency of any group of humans to go feral. Throw that away, and the organisation risks disintegration.
Big bureaucracies – whether corporate or government – are at odds with hackathons, so they try to have it both ways: they stack the deck of the hackathon, then complain if they don't get the promised results.
It might be helpful to highlight some of things that should be kept in mind to make a hackathon successful.
One: You can establish the questions – but not the answers
The most common defensive strategy in any hackathon is an attempt to control outcomes. That’s often done by framing the questions so narrowly only one answer is possible, or by limiting the terms of discussion, or limiting the range of proposed solutions.
These constraints may be real, and may be presented in good conscience – to ‘help’ hackathoners to a solution – but they hamstring participants’ capacities to develop unexpected solutions to the usual problems.
Two: Conflict resolution skills are key
One recent hackathon saw one team split by an irreconcilable impasse. Half the group wanted to go in one direction, half in another – but they were only given one pitch. Their solution? Clumsily glue the two pitches together, doing a disservice to both.
While conflict is an important part of creativity – and hackathons – participants have to understand that the ability to resolve those conflicts is at the heart of the hackathon. When squaring the circle, out-of-the-box insights are most likely to happen.
Taking your toys and going home just won’t cut it.
Every hackathon needs a meta-moderator whose sole purpose is to keep each team of hackathoners moving smoothly toward their goal. Meta-moderators check in regularly with each team, observing group dynamics, and stepping in with tweaks as needed, using their own conflict resolution skills to keep the teams coherent, focused, and productive – while passing those skills along to the team.
If needed, meta-moderators identify intransigent team members – who won’t play fair or won’t play at all – and blast them out of the way. They’re the ultimate arbiters, and use their powers to help each team achieve the best possible outcome.
Four: Expect mixed results
Hackathons will never produce uniformly excellent results. The mixture of personalities and ideas and organisation is too variable to provide any guarantee of success. Instead, every hackathon will likely produce a few standouts, a few good efforts, and a few disappointments. That’s as it should be: even the most disappointing pitches will teach you something you didn’t know before.
Five: Don’t expect anything to stick
Throwing a group of individuals into a crucible may produce an excellent pitch, but everything after that is left to the organisation supporting those individuals.
The team may be energised and ready to implement their pitch, but if the organisation isn’t ready – because the pitch is too weird, dangerous, or disruptive – it will be ignored and eventually forgotten. And if the winning pitch doesn’t see the light of day, why even bother with a hackathon?
Finally, if you find yourself at a hackathon – and you probably will, before long – remember that it’s not a contest, even though they may crown a ‘winner’. A hackathon is about finding the right mix of creativity and teamwork. Neither is easy. Together, they can generate a spark that will wake the dead. ®
Sponsored: Beyond the Data Frontier