How to run an internal AI hackathon

01What is the prep timeline?#

Three weeks is the minimum that produces a good day. Week one is friction interviews, week two is converting those into a written problem list and killing infeasible ideas, week three is access, accounts, and confirming the demo audience. Compressing below two weeks reliably degrades the outcome.

1. Week 1

   Eight to twelve friction interviews across the invited functions. Ask what they resented doing last week, not where AI could help.

2. Week 2

   Write the problem list. Each entry gets a one-line description, the data it needs, and a feasibility call. Cut anything blocked on access you can't obtain.

3. Week 3

   Accounts, keys, permissions, room, food, and the sponsor's calendar hold for demos. Send the problem list to participants.

02Which roles do you need to fill?#

Four: a facilitator who teaches and unblocks, an organizer who owns logistics and access, an executive sponsor who attends demos, and a technical helper per two or three teams. The facilitator and organizer must be different people, running the day while chasing a missing API key does neither job well.

03What is the hour-by-hour agenda?#

Teaching 09:00–10:30, team formation and problem selection to 11:00, build until demos, a scope reality check around 14:00, demos at 15:30, and a close at 17:00. Keep the build block unbroken, every interruption costs more than the time it takes.

1. 09:00

   Teaching: the model of how these systems work, the tools on the table, and the specific failure modes people will hit today.

2. 10:30

   Team formation. Mix functions deliberately; do not let people sit with their own department.

3. 11:00

   Build begins. Facilitator rotates on roughly a twenty-minute loop.

4. 12:30

   Working lunch in place. Momentum is worth more than a break at this point in the day.

5. 14:00

   Scope check: every team states what they will demo. This is where over-ambition gets pruned.

6. 15:30

   Demos. Five minutes, working software only.

7. 16:45

   Close: what happens to each build, who owns it, when the debrief lands.

04What are the rules that make it work?#

Three, stated at the start and enforced without exception: demos show running software, no slides; every team is mixed-function; and any build with no named owner by the end of the day is considered retired. Rules stated but not enforced are worse than no rules.

The no-slides rule is not a stylistic preference. It is the mechanism that keeps the afternoon spent building rather than framing.

05What goes in the debrief?#

Within a week: every build with its owner and status, the friction themes that recurred across teams, the access and tooling blockers hit during the day, an honest note on what did not work, and two or three specific recommendations for the next quarter.

The friction themes section is often the most valuable page in the document. When six independent teams all build something to work around the same broken internal process, that is a finding worth more than any individual tool built that day.

Questions people ask#

How many facilitators do you need for forty people?

One lead facilitator plus technical helpers at roughly one per two or three teams. Beyond about forty participants, split into two rooms with separate demo sessions rather than scaling one room.

Should there be prizes?

Small, non-competitive recognition is fine. Ranked prizes tend to push teams toward demoable spectacle over useful plumbing, which is the opposite of what you want surviving the week.

What if teams finish early?

Have them write a one-page handover for whoever will own the tool. That is the step that most reliably decides whether it is still running in a month.