Running a hackathon is an important part of leading a high performing team in a software company. It has almost become a rite-of-passage in modern day software development leadership, marking the transition from reactive manager into proactive leader.

I remember the first hackathon I ran. It wasn't well organised, I didn't have great buy-in from the executives and had to keep it mostly under the radar. We started without fanfare, compressed it all into a single day, and barely got more than a handful of working demos.

The funny thing is, it was still absolutely loved by the team. The enjoyment and response (not to mention the sheer amount of awesome and creative ideas) that came about was overwhelming. It confirmed for me that running regular hackathons are brilliant opportunities to nurture and support a high performing team.

Since that fateful, and poorly run, hackathon I have organised more than my fair share and I have learned a lot. Here is my take on how to run a hackathon your team will love.

Running a hackathon your team loves

I chose the title of this article very specifically because it focuses on what is the most important aspect hackathons - your team.

Whilst there are many great commercial upsides to hackathons ultimately it is your team that will benefit most. The rest of the benefits, potential or real, will be a natural result from creating a fun experience for your team.

When organising a hackathon the enjoyment of your team is the number one focus.

There are some obvious stages of running a hackathon so I've structured my thinking along these lines - preparation, kick off, hacking, wrap-up, and afterwards.

Preparation

Preparing for a hackathon is a no-brainer. When organising any event the effort you put into preparation is critical. Like hosting a party, you cannot just decide to run a hackathon last minute and hope it all works out. A good hackathon needs good prepration.

Here are the key things you need to get sorted in the preparation phase:

Name (aka 'branding')

All good hackathons have a name, and sometimes even a theme. Despite the overuse of the term I'll call this 'branding'. Pick something that captures the imagination of the entrants but also invokes creativity and a sense of fun.

A favourite of mine was "Hack to the future" hackathon that happened to occur on October 21 2015 (the date Marty McFly travels to in Back to the Future 2)

A sub-part to the brandng of a hackathon is getting good swag. Free shirts or toys always seem to go down well software engineers.

Prizes

A lot of people seem to think the hackathon alone is reward enough and forget about prizes. This reminds me of The Oatmeal's take on artists doing work for 'exposure...

While hackathons are fun and rewarding on their own you will guarantee higher engagement by adding in some prizes. This is basic psychology and economic theory. People work better with tangible incentives.

Last point: make the prizes cool and relevant for your team. Something they would probably like but might not have bought themselves.

Set the rules

Hackathons need some rules or constraints. It might be setting the overarching theme, focusing on a particular business problem, using specific datasets, nominating specific technology choices, or a combination of those.

I also like to add in some minimum requirements for pitching ideas and forming teams (e.g. minimum 3 people) to encourage cross-pollination of people and ideas.

Whatever your rules make sure they are clearly defined beforehand.

Announce it

People need to know about the hackathon and they need to know about it well in advance. Make a formal announcement and make it early enough to get people thinking.

Promote it

Posters, emails, announcements, calendar reminders. Use whatever means you have at your disposal to get your teams interested and thinking ahead to the hackathon. The worst thing for any hackathon is a kickoff where people turn up half-hearted and nobody has bothred to think of any ideas beforehand.

Kick off (Day 0)

Team formation and registration

This is one of those steps that makes it sound a little too official. Why bother having teams formally organised and registered? Because it ensures teams actually form!

The first few hackathons I ran did not have this step and the result was the majority of entries were just individuals hacking on their own. Whilst the ideas created were great, part of a good hackathon is the collaboration and unique ideas that comes from blurring of normal team boundaries.

Secondly, making teams register forces them to plan ahead. Instead of winging it with whatever idea strikes them on the day they will spend more time ahead of the day coming up with ideas and discussing amongst themselves.

Pitches, Posters, and Party

Once teams are formed we want to know what they are working on. This can take any form you like from the obvious (give a 2 minute pitch) to the Amazon-inspired outcome focus (write a press release as if your idea is done) to the X-inspired creative outlets (design a movie poster of your idea).

Kick off sessions should be fun, creative, and social. Once the ideas are shared you want to see the teams talking and interacting. Ideas might overlap, lead into each other, or even generate new ideas. Encourage this collaboration by treating it like a party. Provide food and drink and a fun atmosophere.

Start the clock!

The kick off session officially ends when the hackathon clock begins. Make an announcement and send the teams off into the wild.

Bonus points for actually having a hackathon countdown clock.

Hacking (Day 1)

All that and we've only just started hacking? Crazy huh? But that's the point. A great hackathon is a well organised one. Most of the effort is up front, setting the team up for success, and then you just stand back let it run.

Well, kind of. There are couple of little things a hackathon organiser needs to consider at this stage.

Get out of their way

The hacking is about the hackers. Don't make it about you, don't bother them too much, and do whatever you can to enable good fast hacking. Remove impediments, block work requests, and just support them where possible.

Food and drink

Supplying these goes a long way during a hackathon. Coffees, snacks, and drinks are always welcome.

Photos and notes

Taking photos and writing notes is they key task for an organiser at this stage. You want to have these captured during the day so you can use them later. Like when writing a blog post or posting to social media. ;)

If you're lucky you can try to rope in a marketing/social media person to help you here.

Wrap-up (Day 2)

After a full day of hacking the teams have (hopefully) made great progress but not normally quite enough to have something useful and demonstrable. This second day gives them the opportunity to find that zen-like middle ground of this Venn diagram I just made up:

All good hacks find their own happy place

After that last rush in the morning to hack in that one last little feature, the teams should wrapping up ready for the afternoon presentations.

Presentations

Each team MUST present. Even if their hackathon is considered a burning failure they still must present. Why? Because we want to learn why it didn't work and maybe trigger ideas for how we could try that idea again in the future. Plus, presenting is always a great skill for people to have so it's also good for their personal development.

The trick here is ensuring all teams have enough time to present but not let it drag on. Set a time limit before and stick to it. People will want to talk more but do not let them.

To combat this problem, or if you are a large company with many teams hacking then you can always go for a careers-fair display booth setup where people can roam around and talk to each team at their leisure.

Here's what I like to see in any hackathon presentation

Quick recap of the idea
Decisions, technologies, solutions
Live demonstration
What next (or what's left to make it get to production)?

Voting panel

A formal voting panel should decide on the best idea.

This is the idea that is deemed to be the best combination of an interesting problem + cool technology + commercial/product potential

Crowd favourite

Give each person a vote toward the crowd favourite idea. No rules for this. People just get to pick what they liked the most. This encourages those people who come up with extremely outrageous ideas that probably wont ever the best idea award. These crazy ideas are worth as much as a good commercial product simply due to the creativity they trigger within the team.

Prizes!

Prizes must be awarded for the winners of both the best idea and crowd favourite categories. Have some fun here.

Announce that the winning idea will get time/budget to be released into a production environment. This is another fantastic reward that motivates software engineers to come to a hackathon with enthusiasm and delight. They love seeing their ideas make it to production.

Afterwards

This is the bit most people forget. After the hacking is complete and the prizes are handed out most people pat themselves on the back for a job well done and think the only thing left to do is clean up.

But if you really want to take your hackathon to the next level then there are some key things to do now.

Timeline for winning idea

Actually follow up and announce a timeline for getting the winning idea into production. This is not just one of my core values in life of doing what you say you will but it also sets a clear precedent that the hackathon is important to the business.

Ideally don't let this be planned any later than a month away. Even if it's just running an A/B test of the new idea within an existing product. Get it out there ASAP!

This includes ensuring the idea gets the right support by being allocated people to work on it. Don't let it get treated like a side-hack. It must be put into the plan and given dedicated resources.

Next hackathon

Now is also the time to announce the next hackathon!

Use the momentum from the success of this one to announce when the next one is. If you don't yet have a specific date then at least announce the month. This will help keep everyone accountable and also get people thinking ahead on how they can do something even crazier next time!

Retrospective

Apply the agile mindset here to learn what could be better. There will always be something that you could improve. Maybe the presentations went too long, or there wasn't enough food, or some people felt excluded. Whatever it is, take this as useful information you can funnel into the preparation for the next one. Remember the goal is to create a hackathon that your team loves.

That's it. That's how I like to create a hackathon that people love.

I'm sure there are plenty of other methods out there for running a good hackathon so if you have any comments or ideas for me then I would love to hear them. Please leave a comment below or find me on twitter.