AI hackathons for internal teams

01What is an internal AI hackathon?#

An internal AI hackathon is a facilitated one or two day sprint where employees from across functions build working AI tools on their own workflows. Unlike a public hackathon, there is no prize, no external participants, and no novelty brief, teams solve real friction from their own week and demo software that runs.

The distinction matters because most people's mental model of a hackathon comes from the recruiting-event version: pizza, a leaderboard, and a prototype nobody opens again. An internal AI hackathon inverts almost every property of that format.

The single highest-signal number afterwards is not how many things got built. It's how many are still in use thirty days later.

02Why run one instead of training?#

Training transfers information; a hackathon transfers capability. After a course, people know what a tool does. After a build day, they have shipped something a colleague uses, which changes what they believe is possible for them specifically. That belief shift is what actually moves adoption inside an organization.

There is a specific pattern I see in organizations that have done enablement but not building. Completion rates for the training are high. Usage a month later is near zero. Leadership concludes the workforce is resistant. The workforce concludes the tools don't apply to their job. Both are wrong, and both conclusions are downstream of the same thing: nobody in that building has personally shipped anything.

A build day breaks the loop because it produces a specific, local, undeniable proof, Priya in finance made the thing that does the reconciliation summary, and it works, and she is not technical, and she did it before lunch.

03Who should be in the room?#

Mixed function teams of three to five, drawn from anyone whose week contains repetitive work, operations, finance, support, people, marketing, sales ops, plus enough engineers to unblock but not enough to take over. Eight to forty participants total. The wrong room is all engineers; they build impressive things nobody asked for.

• Domain owners: the people who feel the friction daily. They pick the problems.
• Engineers: one per two or three teams, explicitly in a support role, not a driving one.
• One executive sponsor who stays for demos. Their presence is what makes the work count.
• Someone from security or IT, in the room and empowered to say yes to small things.

Make attendance opt-in but make the invitation broad. A room of volunteers from twelve functions beats a room of conscripts from one.

04How do you prepare for an AI hackathon?#

Preparation determines the outcome more than the day itself. Two to three weeks out, interview a slice of participants, convert their real annoyances into buildable prompts, confirm tool access and credentials, and secure the demo slot with a senior sponsor. Teams that arrive with a curated problem list ship; teams that brainstorm on the morning do not.

1. 3 weeks out

   Friction interviews. Twenty to thirty minutes each with eight to twelve people across the invited functions. The question is never 'where could we use AI', it's 'what did you do last week that you resented'.

2. 2 weeks out

   Turn those into a written problem list, each with a rough shape and an estimate of whether it's a one-day build. Kill anything that requires new data access you can't get.

3. 1 week out

   Access and accounts. Every participant logged in, every API key issued, every permission granted. This step, skipped, costs you the first two hours of the day.

4. 2 days out

   Confirm the sponsor for demos and send the problem list to participants so they arrive already attached to something.

05What does the day look like?#

Ninety minutes of teaching, then teams pick from the pre-work problem list, then five to six hours of building with a facilitator rotating between teams, then five-minute demos with a working-software-only rule. Debrief follows in writing within a week, covering what shipped, what is worth keeping, and who owns each thing.

1. 09:00

   Teaching block. The mental model, the tools, the failure modes. Enough to build with, not a survey course.

2. 10:30

   Teams form and pick problems from the pre-work list. Mixed function, three to five people.

3. 11:00

   Build. The facilitator rotates, unblocks, and pairs. Most people get something working before lunch.

4. 14:00

   Reality check pass, every team gets asked what they will actually demo, which quietly kills over-scoping.

5. 15:30

   Demos. Five minutes each, working software only, no slides. That single rule does most of the work.

6. After

   Written debrief: what shipped, what's worth keeping, what needs an owner, what to do next quarter.

The no-slides rule deserves its own paragraph. It is the difference between a day of building and a day of positioning. When people know they cannot present a concept, they stop designing one at 2pm and start making something run.

06What do teams actually build?#

Almost always internal workflow tools rather than customer-facing products: report generators, triage assistants, document summarizers, and answerers built on internal wikis. The common shape is a task that takes a person hours, happens weekly, and has a written source of truth somewhere in the company.

• A weekly operations report that previously consumed two days of a person's time
• An intake triage assistant that routes and pre-summarizes the support queue
• A pricing-question answerer grounded in the actual sales wiki
• A recruiter screen summarizer the people team kept running afterwards
• A contract clause checker that flags deviations from standard terms

None of those were built by people who had used AI seriously before that morning. The ceiling in most organizations is not technical ability. It's permission and a deadline.

07What does an internal AI hackathon cost?#

Facilitated internal AI hackathons typically run as a fixed fee scoped to group size, prep depth, and whether it is one or two days, plus travel for on-site events. The larger cost is usually the one nobody prices: participant time. Forty people for a day is a meaningful investment, which is why prep quality matters.

The variables that move the number are the number of participants, how many friction interviews the prep includes, one day versus two, on-site versus remote, and whether the engagement includes follow-on support to get the surviving builds into production.

The cost comparison worth doing is not against a training budget. It's against the fully-loaded cost of the recurring manual work in the room, if four of the things built survive and each saves a few hours a week, the arithmetic answers itself within a quarter.

08How do you measure whether it worked?#

Measure survival, not output. Thirty days later: how many builds are still in use, how many have a named owner, how many people have built something else unprompted, and whether the internal conversation about AI has moved from hypothetical to specific. Demo count on the day is a vanity metric.

09How do these days fail?#

Four ways, in order of frequency: no prep so the morning is spent brainstorming, tool access unresolved so the first hours go to logins, engineers dominating so non-technical people spectate, and no follow-through so everything built dies quietly the following week.

• Treating it as a morale event. If nothing is expected to survive, nothing will.
• Letting it become a vendor showcase. A day spent inside one product teaches the product, not the capability.
• Choosing problems by political interest rather than by where the documentation is good.
• Skipping the debrief. The written follow-up is what converts a good day into a program.

Questions people ask#

How long should an internal AI hackathon be?

One day works for most organizations and is far easier to get forty people to attend. Two days is better when the group is large, when several teams need to integrate with internal systems, or when you want the second day for hardening what survived the first.

Do participants need technical experience?

No. The most valuable builds usually come from non-technical domain owners, because they know which repetitive task is genuinely worth automating. Engineers help, but a room of only engineers produces impressive things nobody asked for.

Can an AI hackathon be run remotely?

Yes, and it works well with a tighter agenda, smaller teams, and a persistent video room per team. The main loss is the informal cross-team drift where someone overhears a solution to their problem, so the facilitator has to move that signal deliberately.

What tools should teams use?

Whatever is already approved, plus one or two general-purpose build tools. Standardizing on a single vendor's platform teaches the platform rather than the capability, and creates an unhelpful dependency the day after.

What happens to what gets built?

Each surviving build needs a named owner and a decision: keep as is, harden into something supported, or retire deliberately. The written debrief exists to force that decision while attention is still high.

How is this different from an innovation day?

Innovation days optimize for ideas; this optimizes for working software. The no-slides demo rule is the mechanical difference, and it changes what people do with their afternoon.