How to run your first internal hackathon

An internal hackathon is a short event where employees step away from their usual work to build something of their own choosing, then show it to the company. Done once and done well, it can bring people together across teams. Done badly, it leaves people unsure why they bothered.

The accounts below come from software companies, mostly engineering teams. If you are running one for another kind of team, the planning steps still apply, but check the details against your own people. Two of the sources (a hackathon platform and a hiring platform) sell products, and the article says where they are cited.

Decide the goal, then say it out loud

Write down why you are running it before you plan anything else. In a LeadDev account of a first event, the author says his team was unsure of the purpose and assumed a specific project was expected. He now advises stating the goal up front and telling participants what it is.

The Pragmatic Engineer's account of a hackathon at Craft Docs lists its goals: make the event exciting, build new relationships across teams, include non-engineers explicitly, and create learning opportunities. Choose yours and keep it short.

Keep the organising group small, and expect to need help

At Notarize, a two-person committee ran the event, chosen from outside the company's core leadership to keep it grassroots. The LeadDev author organised his own first event and says he would ask for more organising support next time. A small group makes decisions quickly. It also needs time protected for the work.

Tell the rest of the company

A hackathon pulls people off their normal work, so other teams need notice. The LeadDev author emailed other departments about why the event mattered, when it ran and what counted as an urgent request during it (real business emergencies only), and reminded department leaders in one-to-one meetings. At Craft Docs, the idea was raised on a Monday, the executive team committed by Wednesday, and the event was announced four weeks ahead.

Let people choose the ideas, and keep teams small

At Notarize, everyone in the company submitted ideas on a shared spreadsheet, and engineers signed up for a project or proposed their own. Teams were capped at three developers. No rules forced anyone onto a project, and no project had higher status, including the CEO's.

LeadDev's advice is to tell people early and often that they should generate the ideas and that nobody will dictate projects. His team ran a group ideation session a couple of weeks before the event. At Craft Docs, every idea needed a short pitch (the problem, the proposed solution, the resources needed and a prototype vision) and at least two enthusiasts, so nobody worked alone.

Keep it short and protect the time

Notarize considered a full week, cut it to three days, and capped its first event at two days. It wrapped up after a day and a half, with closing presentations on the second day. The company argues that constraints help creativity and that longer events turn into production-style projects. The LeadDev event ran two and a half days and taking part was optional. Craft Docs also ran two and a half days, with two days of building and half a day of demos and evaluation, and it adjusted release schedules, provided meals and kept people in one place.

A longer event can work too: Vercel, a software company, describes an annual week-long hackathon. For a first one, shorter is easier to protect.

Include people who do not write code

At Craft Docs, one of the three prizes was set aside for the best idea, design and presentation, even without a working prototype. The account says this brought in recruiters and customer support colleagues, and every squad still ended up with an engineer and a working prototype. About 80% of the company took part. If your goal includes bringing teams together, say in the invitation that non-technical people are wanted.

Plan the showcase and the judging

The LeadDev author reports that presentations and judging were messy at his first event, with no significant prizes. Plan them as carefully as the building:

Present to the whole company. Notarize invited everyone to its closing presentations and had a judging committee, named in advance, choose the top three.
Keep demos short and share the criteria. At Craft Docs each demo had 12 minutes and nine teams took about two hours. The judges were three company leaders and one external guest, and the criteria were shared up front. Each team got a one-page written evaluation, open to the whole company.

What two platform vendors advise. These are sellers of hackathon and competition products, so read their advice as one view:

Builder Base suggests keeping to four to six criteria, with a sample 20-point rubric of four criteria scored one to five. It advises a short judge briefing that shows what a three and a five look like, a warning about bias toward confident presenters, and a tie-break agreed before judging.
Unstop, writing about hackathons used for hiring, suggests locking the criteria and weights before submissions open, a 15 to 20 minute calibration session for judges, a short written reason for any very high or very low score, and scoring presentation separately from the quality of the solution.

For rules on keeping any team contest fair, including published scoring and tie-breaks, see the guide to fair team scoring.

Prizes

Prizes in the sources are modest. Notarize gave miscellaneous physical prizes at its first event and gift cards at its second, and most teams donated their winnings to a charity. Craft Docs gave three monetary prizes totalling €10,000. The LeadDev author chose stickers over t-shirts. Decide what you can afford, and tell people before the event.

After the event

The sources agree that the work does not end at the closing presentation.

Review against the goal. The LeadDev author judges the event against the goal he set, and gathers feedback with an anonymous survey, or informally a week or two later. Feedback on frequency and length was mixed.
Tell people what happens next. At Notarize, many projects had clear business value, so staff asked when they would ship. The company had to temper expectations because the code needed cleaning and testing, and it gave status updates afterwards.
Some projects do ship. Vercel names several projects that shipped after its hackathons and says it runs weekly demo days to keep the spirit going.

A checklist before you start

A one-sentence goal, shared with participants
A small organising group with protected time
Notice to other teams, and a rule for what counts as urgent
A way to collect ideas, with people free to choose
A team size limit and a time limit
An invitation that includes non-technical colleagues
Judging criteria, judges and a tie-break agreed beforehand
Prizes decided and announced
A plan for what happens to the projects, and for feedback afterwards

Where this fits

A hackathon is one kind of team contest. The workplace wellness challenge guide covers another. If you want a place to run a team competition, see Arena for companies.