How to Run an AI Hackathon That Actually Pays Off
Six months after the workshop, the team still uses AI every day, and something has gone flat.
Nobody is resisting. The tools are in the workflow, the prompt library exists, people are faster than they were. What has stopped is the building. The question “what else could this do?” does not come up any more, because the obvious answers all got built in the first two months and nobody has had a spare Tuesday since.
The usual prescription is an internal A fixed block of time, usually a day, in which people drop their normal work and build something. The name comes from software and carries some baggage worth discarding: it does not require staying up all night, it does not require anyone to write code, and the competitive framing with judges and prizes is optional and often counterproductive. What is load-bearing is only the protected time and the permission to attempt something that would not survive a normal week. . It is a reasonable idea and most of them waste a day.
Start with the number that should worry you
Research on hackathon project continuation found that around 65% of projects receive no further work after the event ends, measured by commits to the repositories the projects were built in. Other work in the same area puts the share still being worked on a week later at under a fifth.
That is the honest baseline for the format you are about to run. Not a reason to skip it, but the thing the day has to be designed against, because a hackathon that produces nothing durable is an expensive morale event.
Almost every piece of advice on running one focuses on the day. The day is the easy part. What decides whether it mattered is Monday.
Why the enthusiasm went flat in the first place
Worth understanding before you try to fix it, because the fix can be another instance of the problem.
What you are looking at is probably the The tendency for performance and engagement to jump when something new arrives, partly because it is new rather than because it is better. People concentrate harder, tolerate more friction and rate the experience more generously in the first weeks. As the thing becomes ordinary, that premium disappears, and what is left is whatever genuine value the tool actually has. Measuring in the first month and projecting forwards is how organizations talk themselves into believing a temporary surge was a permanent gain. ending. The early weeks after a workshop are inflated. What remains afterwards is the real level, and the real level is usually “people use it competently for the things they already know it does.”
This matters for what you do next. If a hackathon is just another novelty, you get another spike and another decay, and you are on a treadmill. The version that works is not an injection of excitement. It is a periodic, scheduled removal of the thing that actually stopped the building, which is that nobody has a spare Tuesday.
That is the same permission problem as work happening after hours, just at a later stage. A hackathon is the crudest and clearest possible way to say that building is the job today.
This is not the workshop again
If you have run a workshop, whether the full day and a half or the compressed three-hour version, this is the opposite exercise. It is worth being explicit about the difference, because running the workshop twice is the most common mistake here.
The workshop exists to build confidence. Projects should be small enough that everybody finishes. Somebody walking out with a working thing they made in an afternoon is the entire point, and an unfinished project is a failure of scoping. You are teaching people that this is possible.
The hackathon exists to find the ceiling. Projects should be stretch goals, deliberately too big, chosen so that the team finds out where the tool actually stops. An unfinished project here is not a failure, provided it left something behind. The people in the room already know AI works. What they do not know is how far it goes.
Run the confidence exercise on a team that is already confident and you will bore them. That feels like a waste of a day, and it is usually why the second one does not get scheduled.
What the research says actually predicts survival
The continuation work identifies factors that separate projects that lived from projects that died. Three are worth designing around.
Team composition was the strongest predictor. Projects built by teams with diverse, well-matched skills survived at much higher rates than projects built by teams without that fit. Not the idea, not the technology, not enthusiasm. Who was in the room together. If you let teams self-select purely by interest, you will get clusters of similar people building things nobody else can maintain.
Fit to existing work mattered. Projects that connected to something the organization already did got continued. Projects that were interesting on their own terms, but did not relate to the business, did not.
Organizational commitment of resources afterwards mattered. Someone has to be given time, and the research is blunt that prior commitments and prioritization are the barriers that kill otherwise viable projects.
And one counterintuitive finding worth holding onto: intensive short-term activity right after the event was associated with a lower likelihood of long-term continuation. A frantic week of follow-up looks like momentum and predicts the opposite. The projects that lasted were worked on steadily, not rescued in a burst.
The format, designed against all that
One day. Four blocks. Everything here exists to move one of the factors above.
Before the day: pair people deliberately. This is the highest-value thing you will do and it happens a week early. Since team composition is the strongest survival predictor, do not let teams form purely by enthusiasm. Mix skill sets on purpose, and make sure every team has at least one person who will still be near the problem in three months.
0:00 to 0:45, pitch and pick. Anyone can pitch. The only filter is a question: what does this connect to that we already do? A project with no answer is a hobby project and it will die, which the research is clear about. Pick fewer projects than you have appetite for.
0:45 to 4:30, build. No check-ins, no standups, no progress theatre. You are removing interruptions, which is the actual scarce resource.
4:30 to 5:30, demo and hand over. Demos are five minutes each, and every one ends with three sentences rather than applause: what exists now, what would make it real, and who owns it until the next session. A demo that ends without a named owner is where most of the 65% begins.
If you ran the full workshop, this is its showcase with one deliberate change. The workshop’s demos end on what did not work, because that event exists to make the attempt visible and to show the struggle was normal. These end on who owns it, because this event exists to make the work last.
The Monday after: one commitment, not a campaign. Give each surviving project a small, regular slot rather than a heroic week. That is the counterintuitive finding turned into practice.
Two worked examples, one technical and one not
The research base here is almost entirely software hackathons, so the technical version transfers directly and the non-technical version is my extension rather than a finding.
A technical team. Stretch project: an agent that takes a support ticket, reproduces the issue in a test environment, and opens a draft pull request with a failing test. Almost certainly not finished in a day. What survives is the reproduction harness, which is useful on its own and connects to work the team already does.
A finance, operations or marketing team. Stretch project: take the monthly report end to end, from raw exports to a drafted commentary with the numbers checked against source. Almost certainly not finished in a day. What survives is the checking step and the prompt set for the commentary, both of which outlive the ambition.
Notice the shape in both. The stretch goal is the target, and the thing you expect to keep is a component of it, named in advance. That is different from hoping a foundation emerges.
Yes, this contradicts my own advice
The three-hour workshop post says to follow up without booking another session, using a question in a meeting you already have. This post says book a day. Both are right at different points.
In the first weeks, process is the enemy. The habit is fragile, and adding ceremony to a team that has just started is how you make AI feel like an initiative. A question in an existing meeting is exactly enough.
By month six the problem has inverted. The habit is no longer fragile, it is settled, and settled is the problem. What is missing is not lightness, it is a deliberate, scheduled reason to attempt something that will not fit into a normal week.
Light touch for a new habit. Protected time for a stuck one.
The takeaway
An AI hackathon is a good idea and the default version of it wastes a day, because the format optimizes for the twelve hours that are easy rather than the three months that are hard.
Design the day backwards from Monday. Pair teams on purpose rather than by enthusiasm, refuse projects that do not connect to work you already do, end every demo with a named owner and a next step, and then protect a small recurring slot instead of a heroic week. Around two-thirds of what gets built at these events never gets touched again, and almost everything that changes that number happens before and after the day itself.
*Sources: the continuation figures are from Alexander Nolte, Irene-Angelica Chounta and James D. Herbsleb, “What Happens to All These Hackathon Projects? Identifying Factors to Promote Hackathon Project Continuation” (opens in a new tab) (Proceedings of the ACM on Human-Computer Interaction, Vol 4, CSCW2, 2020).
Related: Hosting an AI Workshop is the full day-and-a-half version, the confidence-building session this one is deliberately not, and where the showcase format above comes from. AI Workshop in Three Hours: You Won’t Get a Day and a Half is the compressed version, and the post whose advice this one argues with. Your Team Is Building AI Tools After Hours. That’s a Management Failure. is why protected time is the thing actually being purchased here.