Hackathon judging criteria and a scoring rubric that survives scrutiny

What hackathon judges score: nine criteria

The nine criteria cover the problem (how important it is and how well it fits the strategy), the idea (how well it solves the problem, and how new it is), the path to production (feasibility, ease of development and ease of operations) and the value (impact and demand). Each comes with the one question a judge answers, so every judge on the panel scores the same thing.

Demo quality is deliberately not a criterion. A beautiful demo of the wrong problem is the worst possible outcome, and with AI tools any team can produce a convincing prototype in hours, so polish no longer separates strong entries from weak ones. Evidence does: a problem that bites, a mechanism that works and users who want the result.

The criteria work with any of the evaluation models: closed scoring by a panel of experts, live pitching to judges, or the hybrid two-stage model that combines them.

What judges look for in each criterion

A criterion is only as useful as the evidence it asks for. These are the signals judges are briefed to look for.

C1 · Problem importance

A named problem with a visible cost: who has it, when it bites, and what it costs in time, money or risk. The pitch should make the judges feel the problem before they see the product.

C2 · Problem alignment

The theme and the problem statements in the brief are the yardstick. On-theme work that advances a named portfolio bet scores high, however unglamorous; off-theme work, however impressive, goes to the chair rather than being quietly rewarded.

C3 · Idea effectiveness

The mechanism, traced from problem to outcome. “AI will optimise it” is not a mechanism: the demo should show the problem dying, not features existing.

C4 · Idea feasibility

Buildable with means the team can name: technology that exists, data that is accessible, costs that make sense. Honesty about what is mocked counts in favour, not against.

C5 · Ease of development

The distance from demo to production: integration, data plumbing, edge cases and the parts that were mocked. A credible 90-day pilot path is the benchmark.

C6 · Ease of operations

Someone must own this on a Tuesday in February: support load, running cost, data governance and compliance. Teams that thought about the unglamorous parts are rewarded.

C7 · Impact

The value, quantified honestly and bottom-up: users × frequency × value per use. Estimates are marked as estimates, and judges punish confident fictions, not small numbers.

C8 · Novelty

Novelty that was checked: what exists, what was tried internally, and where this genuinely differs. A team that found three competitors and still differs beats a team that found none.

C9 · Demand

Evidence of pull: user quotes gathered at the event, sign-ups, a measurement, a stakeholder asking to pilot it. Push (“everyone will want this”) is not demand.

Weights and written anchors

Set the weights once, in the hackathon brief, and copy them into the scoring workbook and the judge pack: one source of truth, three documents. Publish them in the pre-read that participants receive when registration opens. Teams that build to the rubric produce better entries, and a published rubric is the contract that makes the result defensible.

Change the weights if your event values something else, but change them before the event, and in the brief first. Before you settle them, ask what behaviour each weight will reward, what it will punish, and where a team could still win on polish rather than insight.

Weights decide how much each criterion counts; anchors decide what a score means. Every criterion carries a written description of a low, a middle and a high score, so a senior leader and a builder score the same pitch the same way. Judges score in whole numbers from 0 to 10, and the workbook applies the weights. These are the anchors for demand:

Choosing and calibrating the judges

Choose judges for proof as well as seniority. A senior leader who has not built anything in a decade tends to reward stories; builders reward proof. Mix the two, and let the anchors bring them to the same score. Five judges is plenty: more slows the deliberation without changing the outcome.

Send every judge the judging guidance with the pre-read, a week before calibration. Before scoring, each judge reads the brief (the theme, the problem statements and the published weights), declares any conflict of interest and blocks the time for the pitches, the scoring and the deliberation that follows.

Then calibrate, before Pitch Time. In a session of 60 to 90 minutes, the panel walks the rubric criterion by criterion, every judge scores the same sample pitch, and the panel walks the anchors until it scores alike. Calibration is what makes one judge’s 7 mean the same as another’s.

“You are judging investments, not performances.”The judge pack, Hackathon Masterclass

The guidance sets the judges’ posture. Score alone, before you deliberate: independent scores are what make the aggregate honest. Evidence beats style: a team that shows a user quote, a measurement and an honest list of what is mocked outscores a team with a flawless script and no evidence. Questions probe; they do not rescue: ask the question that tests the weakest claim, and do not coach a team through its answer, because the next team gets no such help.

Conflicts of interest

A declared conflict is routine; an undeclared one discovered later is the only scandal a hackathon can have. Four relationships count as a conflict:

• Line or team: the judge manages, is managed by, or works in the same immediate team as a participant.
• The work itself: the judge owns, sponsors or contributed to the project or the system it builds on.
• Personal: a close personal or family relationship with a team member.
• A stake in the outcome: the judge’s unit wins or loses budget, headcount or standing depending on which team wins.

Having mentored a team during the event is not by itself a conflict, since mentors see many teams, but it belongs in the declaration. Judges declare in writing to the chair, at the briefing or the moment a conflict appears. The chair rules (no conflict, or scores voided for that project) and records the ruling. A voided score leaves every aggregate while the judge still scores every other project, and the register is kept with the scores as part of the audit trail.

Scoring, normalising and breaking ties

Each judge enters a score and a short justification for every criterion, alone, before hearing any other view. The scoring workbook applies the published weights, drops voided scores and normalises across judges, so a hard marker and a generous marker count the same. Then it ranks the field.

Justifications are written so the chair could read them aloud: specific, evidenced, kind. Scores and justifications stay with the panel and the organising committee. Teams receive structured feedback instead, on the concept, the presentation and the implementation, with advice for what to do next. For many participants this feedback is the most valuable thing the event produces.

Ties happen more often than panels expect, because nine criteria and five judges quantise. The hour after a tied finale is the worst possible moment to invent policy, so the tie-break is written down and published in the pre-read:

1. Impact first: the project with the higher panel score on impact (C7), averaged across judges with conflicts excluded, wins the tie.
2. Novelty next: if still tied, the higher panel score on novelty (C8) wins.
3. The chair decides: if still tied, the chair decides in the room and records the reasons with the scores.

Change the order if your event values something else, but change it before the event, publish it, and never improvise a fourth step at the table.

Chairing the deliberation

The chair runs the hour after the pitches in a fixed order, designed so that the loudest voice in the room is the evidence:

1. Confirm that every scorecard is in and complete, and chase the gaps before any discussion.
2. Review the conflict register and confirm that every voided score has been dropped.
3. Read the ranking, weighted and normalised, without comment.
4. Discuss the top five in rank order, with judges arguing from their written justifications, not from memory of the applause.
5. Apply the written tie-breaks where they are needed.
6. Confirm the winner and the placings with the sponsor, against the funding pathway in the brief.
7. Write the why for the announcement: three sentences per winner, drawn from the justifications.
8. Archive the workbook, with the scores, the justifications, the register and the decisions.

The archived workbook is the audit trail. It lets the organisation defend any winning decision against a challenge from a team that did not win, a question every internal hackathon eventually has to answer. It also records the chair’s call on every project: fund, park or no.

From winners to funding

Judging closes Pitch Time; the Post-Hackathon phase decides whether the event was worth running. Announce the winners with the why, read from the rubric, and name something true and specific about every strong entry. Teams forgive losing; they do not forgive silence.

Announce the funding pathway in the same breath as the prize: a budget, a named owner, access and a first gate with a date, agreed with the sponsor before the event. A winner announced without a budget and an owner is a certificate, and the organisation learns that hackathons are theatre. Strong entries that did not win get a pathway too: the innovation pipeline, a sponsor or the next event.

Then track what happens at 30, 90 and 180 days. Measuring Hackathon Success sets out the measures, from the opportunities flagged in the first week to the products that reach the market.

The scoring workbook and the judge pack

The judging system on this page comes from the Hackathon Masterclass, coming soon, as two editable templates:

The scoring workbook

An Excel workbook for nine weighted criteria, up to five judges and twenty projects: conflict-of-interest handling, a judge-normalised ranking, the tie-breaks and the decisions, with no macros.

The judge pack

A Word document for every judge: the judge’s standards, the nine criteria with their scoring anchors, the conflict-of-interest protocol, the tie-breaks, the assessment form and the chair’s deliberation script.

Both take their weights from the hackathon brief, which the Masterclass includes with the pre-read and pitch decks and the communications library. Join the launch list to hear first.

If you would rather run the judging with us, Corporate Hackathon Programmes include a calibration session with your panel and, as an option, an independent chair of judges: your leaders decide, and we guarantee the process.