How to run a successful hackathon

How to run a successful hackathon

CYB's head of engineering, Ali Salaman, shares all you need to know to organise a successful hackathon.

As we recently found out at Caution Your Blast Ltd (CYB), a lot of thought and preparation goes into organising a successful hackathon. Before I give my tips below, I will refer you to some additional articles from my esteemed colleagues. The brilliant Richard Bray explains why CYB decided to work on a hackathon with Climate Edge earlier this year, while Paul Williams provides a review of that hackathon.  


So how did we do it?

Clearly there are many ways to go about it, but here’s a roadmap you can take inspiration from as to how you might be able to run your own hackathon.

1. Select a suitable collaborator

If you are going to involve an external company in your hackathon you must start sourcing suitable partners. Think about what you want to get out of the hackathon, and the value you want to give to the other party. Avoid cartels, dictators, sociopaths and bad companies (unless you want a stressful week!) 

As a company looking to use digital as a force for good, we wanted to work with someone also trying to have a beneficial impact on society, hence teaming up with Climate Edge. Your aims may be different, but you can apply this general approach.

2. Format and logistics

Work out an agreeable format and the logistics with your collaborator beforehand - time, date, location and a relevant problem that can be solved (we aimed to help smallholder farmers upscale their business). 

Choosing a location for your hackathon may be straightforward in most cases, but in today’s hybrid working environments, perhaps a little more thought needs to be put into it. Our office was the obvious choice for us - but you may not have an office and may need to book a space in advance.  

3. Prepare affected stakeholders

Consider how the hackathon will affect any projects that participants are already working on. All affected stakeholders - clients, internal departments or project teams - should be contacted to agree on a period of absence for the duration of the hackathon. Try not to do a Houdini disappearing act and respect commitments - give plenty of notice! 

4. Teams

Allocate people into balanced teams of skills and personalities ahead of time. This not only saves time on the day but ensures the teams are best placed to produce the most considered and rounded solutions, and aren’t skewed towards one way of thinking. For example, spending time designing and developing a tech solution could be akin to using a hammer to crack a nut if a non-tech solution is available and not immediately obvious to a team full of software developers. 

5. Feed me till I want no more

Making sure the participants are fed and watered is important. Agree a budget with the powers that hold the purse strings, consider dietary requirements and PLEASE avoid obnoxious food choices such as cooked fish or eggs that some find offensive in an office setting - we’ve all been there! We were mindful that not everyone will want to stay in the office, so let people do their own thing on the second day to break up the event. 

6. Timetable

A three day hackathon felt like the right amount of time to be able to collaborate across professions to design a solution, work on a prototype and then present it back to the group.  I’ve provided an outline of the structure below that you may find useful to use as a baseline to build yours off:

Day 1

9:15 - Intro to the hackathon

  • Describe the formalities as appropriate - fire drills, facilities, refreshments, etc.

  • Format of the hackathon

  • Introduction to the problem statement 

  • Describe recommended working practices - see on the day below

  • Explain teams

9:30 - Intro to the Lean UX canvas

We wanted teams to use the Lean UX canvas approach - this may not be appropriate for you, but you may want to introduce a theme or similar skill you want everyone to focus on during this period instead

10:00 - Break

10:15 - Kick-off 

Climate Edge described the problem in more detail, explaining their business and the stakeholders and parties involved in the various workflows. 

11:00 - Team working starts

This is where the real work begins. Participants separate into their teams and begin discussing the problem area.

12:30 - Working lunch (food delivery)

13:00 - Research opportunity with Climate Edge

Additional team members of Climate Edge contacted via video conference for user research so we could validate ideas and clarify details. You may want to agree to a similar approach with the organisations you decide to work with.

17:00 - Home time

Day 2

9:00 - Teams self-manage working on design/solution for the whole day

Teams effectively continue as they were, completing design work and starting prototyping.

12:30 - Lunch (teams get own lunch)

13:00 - Climate Edge available for research if needed

Another research opportunity, the same as day 1.

17:00 - Home time

Day 3

9:35 - Kick-off

9:40 - Team working

Focus should be on finalising the prototype and the presentations at the end of the hackathon.

12:30 - Working lunch (food delivery)

14:00 - Presentations

  • 10 minutes presenting time - think show-and-tell

  • 5 minutes Q&A from Climate Edge & special guest

Each team can show off their process and solutions. Presentations were given to Climate Edge as well as an independent special guest we invited to critique each design (a representative from another of our clients). This may or may not be possible depending on the nature of the work being undertaken due to data confidentiality, etc, but something to consider.

14:45 - A few words from Climate Edge 

It’s useful to get feedback from the organisation you’re participating with. Climate Edge were able to summarise their thoughts on each solution and their experience in general. 15:00 - Home time

7. On the day

To expand on the Day 1 introduction in the timetable above, it is also important to give the participants some guidelines as to how to work: 

  • Basic ground rules - the boring but important bit covering behaviours and etiquette. Basically be kind, professional and play nicely, kids 

  • Use the existing knowledge of the organisation you’re participating with - they understand their users, their context, and their overall proposition, so get clarification as needed

  • Do just enough to test and learn -quickly identify what you don’t know and test, e.g. user research utilising hackathon partner resources

  • Know which constraints matter - understand financial, legal, technical and user constraints that could affect a solution, e.g. any laws you need to operate within for certain countries

  • Divide and conquer - a handful of people working on a single task will lead to chaos and boredom. Split up tasks to the relevant specialists as appropriate

  • Limit your work in progress - you won’t get brownie points for good intentions, only solutions, so focus on one thing at a time

  • Agree a way forward - confirm a set of circumstances and criteria to allow you to make progress, learning from other people’s ideas and perspective

  • ‘Yes’ isn’t enough.  You must say ‘Yes, and…’ - make sure all participants add to the discussion, sharing thoughts and having their say. Don’t be shy - be confident and say it!

  • There are no mistakes! - what’s the worst that could happen?

  • Have fun - the most important thing. Don’t make it a painful experience for yourself or others. Get involved, work well and enjoy it

I hope the practical points outlined above may help you plan yours, or at least give you some ideas you can use for your own hackathon.

Good luck!