How to run an internal AI hackathon that ships something

Why a hackathon beats training

Most organisations try to drive AI adoption with enablement sessions. Someone demonstrates a tool for an hour, everyone nods, and usage moves for about a week. The reason is not that the training was bad. It is that watching someone else solve their problem teaches you almost nothing about solving yours.

The pattern we see repeatedly, and it is a strange one: teams have real appetite and no path in. People have heard what these tools can do, they believe it, and they still have not applied it to their own work, because there was never a protected block of time in which trying was the actual assignment.

A hackathon is that block of time. Its real output is not a tool. It is a group of people who now know what is possible with their own data, which is the thing that keeps producing value in the months afterwards.

The failure mode to design against

Hackathon theatre is easy to produce and hard to spot from the inside. Everyone enjoys it, the demos get applause, leadership posts about innovation culture, and eight weeks later nothing exists.

It fails for a predictable reason. Nobody decided beforehand what would happen to the winner. The event was framed as an exploration, so exploring is what it produced.

Build the run sheet

Pick a format and a team count. The demo block scales with the number of teams, which is the thing most schedules get wrong and then discover at four in the afternoon.

Who is in the room

Aim for teams of three or four, with at least two people who actually do the work on every team. If a team is all engineers, it will build something technically interesting that nobody asked for. If a team is all operators, it will get stuck on a data question at eleven o'clock and never recover.

The fix is to keep your engineers out of the teams entirely and run them as a clinic. One or two people who float, unblock, and answer questions, and who are explicitly forbidden from taking the keyboard. This is counterintuitive and it is the single biggest determinant of whether operators leave feeling capable or feeling like spectators.

That last row matters more than it looks. If the person who can say yes watches the demos over a recording next week, you have converted a decision into a follow-up, and the energy is gone by then.

Collect the problems in advance

Do not open with a blank page. A week before, ask every participant one question: what is the most annoying recurring task in your week? You will get thirty answers in two days, and they are the real backlog of the business.

Then filter them. A good hackathon problem is:

• Recurring. It happens weekly or monthly, so a fix compounds.
• Owned by someone in the room. No proxies, no "the finance team would love this".
• Small enough to be wrong about. One screen, one workflow, one team.
• Not blocked on changing a system of record. Reading from the CRM is fine. Writing back to it is a different project.

Reject customer-facing product ideas outright, however good they are. They belong in a product process, and they will swallow the day.

What "shipped" means at 4pm

Set the bar explicitly, because otherwise every team spends the last hour polishing. A demo qualifies if someone who was not on the team can do the task with it, using real or realistic data, without a narrator explaining what would happen if it worked.

Three minutes each, hard stop, no slides. A team that needs slides did not build anything.

Then pick, in the room, out loud. One build gets the two week finish window. Say why. The teams that were not picked should leave knowing exactly what would have made theirs the one, because that shapes what they attempt next time and there should be a next time.

The week after is the whole thing

A hackathon converts into value in the fortnight afterwards or not at all. Three things to have in the calendar before the event:

1. A finish window. Two weeks, named owner, explicitly protected time. Not "as a stretch goal alongside their day job."
2. A hardening pass. Whatever was built in a day has no permissions model and probably no error handling. Decide who takes it from working to trustworthy, which is where the handoff from prompt to engineering usually happens.
3. A number attached. Take the winning build and run its workflow through the cost of the manual version. That figure is what funds the second hackathon, and it is far more persuasive than a demo video.

Run the second one three months later. The compounding effect is real: the second event starts from a room that already knows what is possible, and the problems people bring get noticeably better.