Everything you think you know about hackathons is (probably) wrong

OPINION / 22nd November 2019

Hackathons seem really popular right now, and having been involved I realised that while many people don’t have first-hand experience of these events, there are some common misconceptions about them. Not all hackathons are the same.  The ORM team have years of experience running hackathons, both internally and for a broad range of clients, so we spend a lot of time dispelling myths about this agile approach to problem solving – here are some of the most common misconceptions we’ve encountered.  

1. Hackathons are just fun competitions and have no real-life application

A hackathon is an exercise in creative problem solving. It’s an intense period of work by a team of multi-skilled people that might include a competition element (and sometimes even prizes) but the purpose is to solve real-life problems. 

The hackathon approach to problem-solving is based on agile delivery – a methodology that was developed as an alternative to large waterfall projects that took months, or sometimes years, to deliver working solutions.  Instead, agile projects adopt an iterative approach, where smaller, working components of the bigger solutions are delivered in short work cycles called sprints.  

Hackathons are rapid prototyping sessions that allow teams to quickly produce working solutions that can be tested by users, adapted and updated before they decide if the product is desirable (by users), viable (for the business) and feasible (to build).  The ultimate goal is to deliver a working prototype or solution to a real-life problem, not to win a trophy.     

2. Only software developers and techies take part in hackathons 

While software developers and interface designers can be invaluable participants in certain instances, not every hackathon is designed to create this kind of product. And, even if you do need to develop a piece of software, it takes a team of people with different input to create a successful tool. 

In our experience the ideal hackathon team should include four to six people with a broad range of skills and who represent an understanding of:

  • the problem to be solved; 
  • the users of the final product;
  • how to design and build solutions;
  • the business from an internal viewpoint;
  • other perspectives and external experience to challenge the norm.

 

Without input from the users, people who understand the business and those at the coalface, the “techies” alone wouldn’t be able to create a product that is fit for purpose.  

3. Hackathons = sleep deprivation  

Participating in a hackathon does not necessarily mean packing a sleeping bag and working through the night.  Typically, an event can last anything from a few hours to a week, and it’s possible to develop ideas into a working product in a single day. And we’re talking about standard business days – we believe you’re more productive after a good night’s sleep!  

We all recognise that our work days are generally full of meetings or short bursts of work, meaning we have less opportunity to focus on specific activities for long periods of time. One of the reasons why it’s possible to achieve so much at a hackathon without working through the night is because these events allow people to work together, without the distraction of meetings, phone calls, emails, etc.

Preparation is also key to a hackathon’s productivity. In the leadup to the event it’s important for all of the stakeholders to meet and define the business problems that the group aims to address.  If the problem is clearly defined, it’s easier to understand and the team will be able to spend more time working on a solution. 

Basically, a hackathon boosts productivity by providing the right environment to creatively solve problems, while at the same time taking away all the normal day to day distractions.

4. The only purpose of a hackathon is to develop new tech products

It’s true, hackathons are extremely effective ways to kickstart tech projects because they deliver a working prototype much faster than a typical operational cycle would allow.  This makes it much easier to present proposed solutions to senior stakeholders and to get buy-in and approval for building a full working solution. But there are many other applications for hackathons and broader benefits to this way of working. 

Hackathons can be used to improve existing products by quickly producing new features and tools for market testing.  They are also ideally suited to developing business propositions – if you’ve got a business idea that you want to develop, the right hackathon teams can help you understand what customers are looking for, what’s possible from a technology perspective and what the business case is so that you can develop your business plan.  Similarly, hackathons can also be used to define new ways of working and solve operational problems in existing businesses. 

Whatever the purpose of your hackathon, putting people from different disciplines together provides the added benefit of promoting better working relationships and gives people an opportunity to participate in projects that they may otherwise not have been able to.    


ORM’s view

The word “hackathon” is an amalgamation of “hack” and “marathon” but it would actually be more accurate to compare these events to HIIT training sessions where participants give maximum effort in short bursts.  That kind of intense activity requires a lot of accessible energy – which brings us to what is probably the only commonly held belief about hackathons which is actually true – that they’re fuelled almost entirely on junk food.  Hackathons are probably the last place on earth where you can chase a handful of Haribos with a can of Coke without anyone around you either noticing or caring. With this combination of incredible productivity and unlimited sugar, other business events simply can’t compete.  That’s probably why they’ve been spreading those rumours!    

To get the full rundown on how an ORM hackathon works, check out our recent webinar. Click here to listen now.

Peter Patersen Peter Patersen Director, Client Engagement Peter Patersen