Hackathon brief template: one document, from the theme to the outcomes

What a hackathon brief is for

Most hackathons fall short long before demo day, undone by a vague brief, unclear rules and judging nobody trusts. The brief prevents that by putting every decision in writing, with the executive sponsor, before anything is announced. A hackathon redesigned mid-flight loses the room.

Once written, the brief is the single source of truth: every stakeholder reads the same document, from the sponsor and the problem owners to the communications owner, the mentors and the judges. Keep it current, and keep its section numbers, because the pre-read deck, the pitch deck, the scoring workbook and the judge pack refer to them.

Write it during Design Time, the first of the five phases of a hackathon, and work through Part one with the sponsor in one sitting: its six decisions are the event.

The cover: the event in one paragraph

The cover names the hackathon and its edition, states the theme in one line and carries a control line: a reference code, the version and date, the director and the executive sponsor. Below it sits the standfirst, three to five sentences on the strategic bet behind the event, the challenge participants take on, the format and dates, the prize, and what happens to the winning work afterwards. A sponsor who reads only this paragraph should be able to approve the event.

Part one: Design, the six decisions

Part one is the event, decided: six decisions that everything else executes. Make them with the sponsor before anything is announced.

1.1 Theme and sponsorship

The theme in one sentence a participant could repeat, anchored to a named strategic bet, with what is in scope and what is out. “Innovation” as a theme attracts generic ideas and makes judging arbitrary; a theme tied to a portfolio bet gives every team a reason and every judge a yardstick. Then the sponsorship: the executive sponsor and what they commit (opening the event, judging, funding the pathway), and the owner behind each problem statement.

1.2 Goals and KPIs

Success in one sentence, then the measures, with targets set before the event and actuals filled in after. Count consequence, not attendance: ideas entering the innovation pipeline, pilots funded within 30 days of demo day and concepts with patentable potential, alongside registrations, complete entries and whether participants would join again.

1.3 Format and duration

Internal, open to partners, start-ups, customers and universities, or mixed; physical, virtual or hybrid, with time-zone rules for distributed teams; the dates, the venue or platform, the capacity, and every technology need (sandboxes, datasets, devices, licences) with an owner. The structure does not change with the format: only the durations and the communications cadence do.

1.4 Eligibility and team rules

Who may enter, written to invite domain experts, not only developers: “developers and designers” produces an engineering contest, while “anyone who has seen the problem up close” produces insight. Then the rules of play: team size, a mix of builder, domain expert and storyteller, one person to one team, the pre-work line (thinking ahead is allowed, building ahead is not) and the use of AI that is allowed and must be disclosed. Legal reviews intellectual property, confidentiality and the code of conduct before the event is announced, not after the first dispute.

1.5 Prizes and incentives

Lead with the consequence, not the gift. The strongest prize is what happens to the idea: budget, an owner, a deadline, a slot on the roadmap. Cash and devices motivate; a funded pilot changes careers. A sum big enough to attract mercenaries changes who enters and why, while a presentation to the executive team costs nothing and attracts exactly the right people.

1.6 Judging rubric

The nine criteria and their weights, summing to 100 and published in the pre-read: teams that build to the rubric produce better entries, and a published rubric is the contract that makes the result defensible. For the criteria, the suggested weights and how judges apply them, see the hackathon judging criteria.

Part two: Promote, filling the room

A hackathon is a recruitment campaign before it is an event. Part two decides whether the right mix of builders, domain experts and storytellers is registered, teamed and briefed by kick-off.

2.1 Communication plan

The cadence from the first announcement to the outcomes recap 30 days after demo day, with milestones, channels and dates, and one named owner for the whole calendar. Messages that “the team” owns drift, and a registration nudge sent late is a smaller room.

2.2 Pre-read briefing

What participants receive before the event: the theme, the problem statements, the rules, the agenda, the rubric and the prizes, sent when registration opens and again a week before kick-off. A participant who has read it arrives ready to build at hour one.

2.3 Registration and teams

The registration channel and its owner, the dates and the waitlist rule, how solo registrants find a team (a team-formation session, a matching channel or both), the date teams must be final, and what managers are told.

2.4 Mentor and judge recruitment

Mentors for the build phase, briefed to kill weak directions early, kindly; judges for calibration and demo day, chosen for proof as well as seniority, with a calibration session booked.

Part three: Run, to a published clock

Part three is the event itself, with owners and timings decided before the doors open.

3.1 Run-of-show

The schedule hour by hour, with one named owner per row (a name, not a team), published in advance. When nobody owns “doors open”, doors open late and the whole clock slides.

3.2 Kick-off rituals

The sponsor opens in person with the bet and the commitment to what wins; the rubric is walked through criterion by criterion; the rules take five minutes; teams and problem choices are confirmed; and the first working session starts before the room empties.

3.3 Mentor checkpoints

Two or three published checkpoints that can still change a team’s direction: early (is the problem real, and has it been tried?), half-way (show it working, not described) and final (sharpen the pitch). A checkpoint that cannot change a team’s direction is a photo opportunity.

3.4 Pitch coaching

A protected slot before the dry runs: one line the judges will remember, a demo that shows the journey, and an ask with numbers and names. Teams that rehearse twice, timed, beat teams that build to the last minute.

3.5 Final demos and live judging

A running order drawn in advance and published, timings enforced kindly and absolutely, questions that probe and never rescue, the deliberation straight after, and winners announced with the why, read from the rubric.

Part four: Reflect, Measure, Act

Part four makes Monday matter: it is why the event was worth running.

4.1 Scoring and decisions

Independent scores, declared conflicts that void the right scores, a weighted ranking normalised across judges and written tie-breaks, with the archived scoring workbook as the audit trail.

4.2 Winner announcement

The winner with the why, every strong entry named for something true, and the funding pathway announced in the same breath as the prize. Teams that did not win hear what happens to their ideas: silence here is how pipelines die.

4.3 Funding pathway

Agreed with the sponsor before the event and announced with the winner: a budget, a named owner, access and a first gate with a date. Strong entries that did not win get a pathway too: the pipeline, a sponsor or the next event.

4.4 Outcome tracking and ROI

Owned tracking at 30, 90 and 180 days, with the actuals filled into the goals of section 1.2. The person who owns the actuals should not be the person who needs the event to look good. Measuring Hackathon Success sets out what to measure, and when.

4.5 Next iteration

Within two weeks of demo day, with the organising team and the sponsor: what to keep deliberately rather than by habit, the two or three things that cost the most friction, what exists only because it always has, and the next event’s date, theme candidates and owner.

The brief and the five phases of a hackathon

The five phases of a hackathon are Design Time, Lead Time, Runtime, Pitch Time and Post-Hackathon. The brief follows the same arc in four parts: Part one is written in Design Time, Part two runs through Lead Time, Part three covers Runtime and the final pitches, and Part four takes the scoring and the decisions into the Post-Hackathon phase.

The full template, in the Hackathon Masterclass

The editable brief is a Word document with guidance in every section and advice in the margin. It is part of the Hackathon Masterclass, coming soon, with the pre-read and pitch decks, the scoring workbook, the judge pack and the communications library. The rubric weights are set once, in the brief, and quoted by the pre-read deck, the workbook and the judge pack. Join the launch list to hear first.

If you would rather design the event with us, Corporate Hackathon Programmes take one hackathon from discovery to debrief on the same method, or build a programme across many.