Hackathons or Hackdays or “Innovation Days” or whatever you want to call them have been a mainstay in tech for a while now. Sometimes, they’re seen as a simple “fix” for an organisation that’s lacking innovation (spoiler: that’s not how they work). But, just so we’re all on the same page:

A Hackathon is a time limited sprint where (primarily) software is created

I’ve been purposely vauge here - but I think this definition encompasses most things that someone would call a “Hackathon”.

These events can produce some amazing ideas and cool demos. But they can also be stressful and (if you don’t manage to make anything functional) embaressing. Here are some thoughts from someone who’s organised a couple and attended a heaping handful.

āŒ What a Hackathon ISN’T

Now we are clear on what a Hackathon is, lets talk about what it isn’t.

1. A hackathon isn’t time to build something on your backlog

This is a trap I’ve seen many internal style “hackathons” fall into. This also tends to happen with 10% time - if engineers are so motivated to fix something that’s been languishing on the backlog, then there’s something seriously wrong with your team management.

Sure, sometimes people will have a pet peeve that others don’t want to prioritise - but as a product owner, you sometimes you just have let engineers do things that don’t seem to be a priority. If your priorities are so tight that you can barely get what’s nessecary done, then it’s not just these “pet peeve"s that are suffering deprioritisation - it’s also general quality of life and reliability improvements to your product. There’s a fear that engineers will go the other way, if let off the leash, and try to gild the lilly with incremental improvements that absorb all of their time - but really, if you communicate the priorities well enough to your team, they’ll know that that isn’t appropriate. They should be on your side, after all.

Also, demoing “I moved the header 5 pixels further down the page” is a really boring hackathon demo …

2. A hackathon isn’t a way to prototype genuine product ideas

This is a trap I’ve fallen into myself. If you have a product idea that’s a pretty sure bet - just put some time into your day to day to create a prototype. Don’t hijack a hackday to get it done.

If it’s a risky, random idea that could be great or could be terrible - that’s a good candiate for a hackday project. You’ll learn a lot either way, and if it turns out to be worth developing, you can keep developing it further.

But - for something that you’re fairly sure will work and doesn’t have a huge amount of technical risk - will building it in a short period really help? You already know it’s technically feasible, but crunching to build it in a day may not do the idea justice.

3. A hackathon isn’t a way to promote your product

Now, this is a bit contravesial as there so many events that precisely meet this criteria. But - in my opinion - a hackathon should have a theme, and some resources. For an internal hackathon, those resources might be “all the stuff we currently have”. But externally, the host may bring something to the party. For example, APIs or SDKs - being a common one. But you can’t make the theme “use our APIs to do - uh - something”. That’s an instruction not a theme, and it’s hardly inspirational.

Isn’t a Hackathon just a fancy crunch?

It’s tempting to view a hackathon as a way of getting people go into crunch mode but dressing it up as “innovation”. And, often, it is - setting up your event for developers to work from beanbags, sleep on sofas or pull all nighters with copious amounts of caffiene sources on hand - added to an extreme unrealistic timeline (e.g. 24 hours) - and you have a perfect storm for crunching.

These kinds of events are fine for a certain group of people - but exclude many more. For a start, it requires being able to commit your personal time to work (almost impossible if you have a family), as well as possessing health sufficient to cope with the exertion (physical and mental).

It doesn’t have to be like that though. It can be a lot more civilised, and just as productive (if not more). Here are some thoughts on how to do that as an organiser.

šŸŒ… Pick a theme EARLY

Give you attendees plenty of time in advance to know the theme and develop ideas around it - and perhaps even form teams and project ideas.

Forcing people to come up with ideas quickly in a group setting tends to draw out the most gregarious and extraverted people - who might have good ideas, but perhaps not always. Giving people time and space to think about their ideas makes it easier for the best ones to be presented - especially if the method of presenting them isn’t in a social context (perhaps a wiki page).

Don’t agressively filter ideas for “relevance”. Some of the most awesome things I’ve seen built at hackathons were only tangentially connected to the theme - or indeed technology - at hand.

And as for themes themselves - keep them loose, vague, and open to interpretation. Give you attendees all the space for creativity and you’ll be surprised with the result.

šŸ“š Prep your resources

There’s nothing worse than getting started on your hackathon and finiding out that you need someone to manually issue an API key, or go through an approval process. Prepping for this ahead of time is a great way to spend more time coding and less time faffing with admin.

This is also a great reason to come up with ideas early: if you need special access to something, or a niche tool or dataset - you can get it ahead of time.

If you’re offering a resource as an organiser, like an API, to your attendees - then make it super easy to get access to it. Bench test it, if it takes longer than 3 minutes from asking for, to being granted access - you’re doing your attendees a disservice.

šŸ¦‰ Don’t pull all nighters

In your code of conduct, set boundaries on how long people can work on their project. Have an end stop to the day - and make sure everyone stops work at the same time. A great way to do this is a post-event social event, which gives attendees an incentive to stop on time. And, make it clear that attendees should not be working on their projects overnight!

If you’re in a physical location that you can restrict access to - lock it overnight - and don’t open until a reasonable time the following morning - perhaps with a round of coffee to greet your attendees back.

Making these efforts helps keep everyone on the same level playing field, improves inclusivity - and reduces fatigue.

šŸ“ Have built in write-up time

One of the worst things to happen is being unprepared for a presentation. I know, this happened to me once - at a Hackathon with thousands of attendees - I had to demo something that I didn’t understand, or know how it worked - and, as it turns out, was broken. Worst experience of my professional life. Don’t put your attendees in that position.

Make it clear in the schedule that there is a protected amount of time where they are expected to create their presentations, rather than continue development until the last second.

šŸ”„ Non-completion is an option

Sometimes, things don’t get finished and actually that’s completely fine. The main thing is that you’ve learnt something by trying - and your attendees should feel safe to share that experience.

A presentation of a broken thing is boring, but a presentation of why you couldn’t get something to work could be a lot more interesting. Why didn’t you finish? Was it because that library you chose was more complicated to use than you expected? Or were you too ambitious? Was the problem you were solving larger than you expected? Or did you not define it well enough? If you had to do it again, what would you change to improve your chances?

Hackathons can be great, when done well

I’ve attended some pretty great Hackathons - and some pretty terrible ones. They’re not the panacea to stagnated innovation that some might hope, but they can be an energising and interesting way to break out of your norm and do something really out there for a bit and give you inspiration. And, it’s possible for them to be inclusive, too