Mentors at a hackathon: what good looks like

A good hackathon mentor helps a team think more clearly about its own idea, through questions, honest feedback and the occasional unblocking, without taking the idea over. Good mentoring is designed: a small group with clear roles, a schedule of check-ins tied to the moments teams get stuck, and a short briefing on what to do and what not to. Here is how to set it up.

What mentors are for

Mentors exist to shorten the time teams spend stuck. In a 36- or 48-hour event, a team can lose six hours on a wrong assumption, a broken data connection or a problem framed too broadly. A good mentor spots that early and asks the question that gets them moving again.

What mentors are not for: judging, designing the solution or bringing a pet idea. The best mentors leave the team feeling the idea is more theirs, not less. That matters for the event and beyond it: if a pilot follows, the team must believe in what they built, and they will not defend an idea a senior visitor handed them.

There are four useful mentor roles. Most events need at least the first two:

• Domain mentors know the problem from inside: the service, the regulation, the history of what has been tried.
• User mentors are, or speak for, the people affected. In many events they are the most valuable people in the room.
• Technical mentors help with data, tools, integration and what can realistically be built.
• Method and pitch mentors help teams test assumptions, structure the story and get to the point.

Seven steps to a mentoring programme that works

1. Decide what teams will need, and when. Walk through your agenda and mark where teams typically struggle: framing the problem in the first hours, choosing one idea, the first test, the late-night technical wall, the final story. Each of those is a mentoring moment. Choose mentor roles to match. If the challenge is about a public service, a domain mentor who knows the rules is worth more than two extra developers. The challenge statement (see how to write a challenge statement people want to solve) tells you which knowledge is scarce.

2. Recruit fewer, better mentors. A ratio of roughly one mentor per two or three teams, per session, is usually enough if their time is scheduled. Recruit for listening and patience, not seniority. A senior executive can be a good mentor, but only if they can sit with a team for twenty minutes and ask more than they tell. Ask each candidate for a specific time commitment, at least two blocks, before you accept them. A name on the website who appears for ten minutes is one of the 9 hackathon mistakes organisers keep repeating.

3. Brief mentors before the event. Thirty to sixty minutes, ideally the day before. Cover the challenge and its constraints, the judging criteria (so mentors steer toward what matters, see judging criteria that pick the right winner), the schedule and the house rules. The most important rule is simple: ask, don't tell. Give them a short set of questions to use, such as:

• Who exactly is this for, and what moment in their day are you improving?
• What is the riskiest thing you are assuming? How could you check it today?
• What would you cut if you had half the time?
• What did you learn in the last three hours that changed your mind?

These questions point straight to assumption mapping and a quick hypothesis test; mentors should know both well enough to suggest them.

4. Schedule the time; don't leave it to chance. Unstructured "mentors are around, just ask" fails in two ways: confident teams monopolise mentors and quiet teams never ask. Run fixed rounds instead: for example, a 15-minute check-in with every team after the problem-framing block, a second after the first test, and a third before the pitch. Between rounds, mentors can be called by request through a simple queue. Rotate mentors so each team hears more than one view, but keep one named mentor as the team's main contact so advice doesn't pull in five directions.

5. Give mentors a way to share what they see. After each round, gather mentors for ten minutes. Which teams are stuck? Which are about to build something that breaks a constraint? Which have not spoken to a single user? This lets the organisers act early, by sending a user mentor to the team that needs one, for instance. It also stops mentors repeating each other's advice. Mentors' notes should never be passed to judges as scores; mentoring and judging must stay separate, or teams will stop being honest with mentors.

6. Protect the team's ownership. Watch for the common failures: the mentor who redesigns the idea, the mentor who insists on their own technology, the mentor whose seniority makes the team abandon a good direction to please them. Tell mentors in the briefing that the team decides. Tell teams, too: "Mentors give advice. You decide what to take." If a mentor keeps overriding, move them to a different role quietly.

7. Close the loop after the event. Ask teams which mentoring helped and which didn't, using a feedback capture grid. Thank mentors with something specific: the team they helped, what changed because of it. If a winning idea goes into a pilot, the mentor who knows the domain is often the best person to stay involved for the first weeks. That continuity is part of what happens after the hackathon.

Do's and don'ts for mentors

Do

• Start every conversation by asking what the team is trying to do and where they are stuck.
• Push for contact with real users and data early, on day one if possible.
• Suggest a quick test (a paper prototype, a five-minute conversation) instead of a long debate.
• Say honestly when something breaks a constraint, and explain why.
• Leave each team with one clear next step.

Don't

• Don't take the pen. If you are drawing the solution, you are designing it.
• Don't bring your own idea and look for a team to build it.
• Don't give advice on everything; pick the one thing that matters most right now.
• Don't contradict another mentor in front of the team; raise it at the mentor huddle.
• Don't mentor a team you will also judge.

Illustrative example

Illustrative. A national health service trust in the United Kingdom ran a two-day hackathon on reducing missed outpatient appointments. At its first event, twelve senior clinicians and managers were listed as mentors. Most visited once, briefly. Three teams changed direction after a consultant suggested a reminder app; by the pitch, four teams had built near-identical reminder apps.

The next event was redesigned around the moments teams struggle. Organisers recruited seven mentors: two outpatient clerks who handled rescheduling every day, two patients from the trust's patient panel, one data analyst, one clinician and one facilitator for testing and pitching. All seven were briefed the evening before with a page of questions and one rule: ask, don't tell. Every team had three scheduled check-ins and one main mentor. At the first huddle, mentors flagged that five teams had assumed patients forgot their appointments; the clerks knew that many patients could not get time off work at the times offered. The patient mentors confirmed it. Teams that tested this with the patient mentors moved toward flexible slot-swapping instead of reminders. The winning idea went into a small pilot with the outpatient manager as owner, and one of the clerks stayed on as an adviser.

Questions people ask

What does a hackathon mentor do? A mentor helps teams make progress by asking questions, giving honest feedback, sharing domain or technical knowledge and unblocking problems. They do not judge, and they do not design the solution for the team.

How many mentors does a hackathon need? It depends on the number of teams and the length of the event, but roughly one mentor for every two or three teams in each session works when their time is scheduled. A mix of roles matters more than the total.

Can a mentor also be a judge? Better not. Teams need to be able to admit doubts to mentors without worrying that it will cost them points. If you have to overlap, make sure no one judges a team they mentored.

Where to go next

For the full event design, see how to run a hackathon that produces something real and the map of formats in hackathons, jams and challenges: every type explained. The assumption mapping, hypothesis test and paper prototype guides are the three every mentor should know.