It's biweekly 1:1 time with my CTO. He once asked me why my team was credited as one of the strongest engineering groups in the company. I smiled, appreciative, and warned him he might be disappointed by the answer: I normalised failure, encouraged risk‑taking and ambitious solutions, and empowered the team with absolute freedom and trust.
Times without numbers, that absolute freedom and trust did not "work" immediately. Deadlines slipped. Expectations were missed. Yet that is where the real philosophy begins: I normalise trying and failing, because it is part and parcel of building a great product, and when something doesn't work, I explain the reasoning, the lesson, and the next decision we will make differently.
Hackathons are one of the most underrated mechanisms for making that philosophy real—especially in AI. Not as a party. Not as a gimmick. But as a disciplined, time‑bounded laboratory for organisational learning.
A hackathon is not an event. It is a temporary suspension of perfectionism.
For 48 hours, the organisation stops pretending it already knows and starts behaving like a scientist again.
1. Why AI Experimentation Needs a Different Ritual Than "Business as Usual"
AI engineering is not ordinary engineering. It is engineering under uncertainty—where outputs are probabilistic, data shifts under your feet, and evaluation is often more complicated than building the model itself.
In that environment, the default corporate rhythm (status meetings, quarterly roadmaps, Jira tickets) produces a particular kind of failure: teams become very good at discussing AI and very poor at learning AI.
What slows AI learning down
- Fragmented attention: experiments are squeezed between "urgent" production work.
- Low psychological safety: people avoid bold ideas because failure feels like incompetence.
- Diffused context: the same question gets answered in five Slack threads and disappears.
- Coordination taxes: cross‑functional collaboration becomes a calendar negotiation.
What a hackathon changes
- Protected time: exploration is not a side quest; it is the main mission.
- Shared context: everyone sees the same data, the same problem, the same constraints.
- Social proof: adoption spreads because people watch peers build with AI in real time.
- Compressed feedback loops: hypothesis → test → learn happens in hours, not weeks.
2. The Evidence: Hackathons Create More Than "Demos"
A skeptic will say: "Hackathons create half‑finished prototypes that die on Monday." And the honest answer is: many do. This is not an insult to hackathons; it is a description of reality—and it tells us how to design them better.
2.1 The Monday Graveyard Is Real
A large empirical analysis of hackathon projects found that 60% of projects were inactive from the very first day after the event, and by day five, 77% were inactive.
Yet that same study also shows the hackathon is not "nothing": the first day after the event contained a burst of activity—tens of thousands of commits and thousands of contributors—often reflecting clean‑up, packaging, and the last push to make something coherent.
2.2 Hackathons Generate Reusable Artefacts, Not Just Feel‑Good Energy
Another large‑scale study examined 22,183 hackathon projects and found that around 9.14% of code blobs in hackathon repositories were created during the event (about 8% by lines of code). That might look small until you remember the constraint: short duration, small teams, high time pressure.
More importantly, the same research found that approximately a third of code blobs created during hackathons get reused in other projects. The hackathon, therefore, is not merely a prototype generator; it is a knowledge‑spillover machine.
2.3 The World Keeps Running Them for a Reason
If hackathons were merely corporate theatre, they would not scale globally. Yet one of the world's largest annual hackathons, NASA's Space Apps Challenge, reported 114,094 registered participants, 18,860 teams, and 11,511 projects submitted across 167 countries/territories in 2025.
The point is not that your company should copy NASA's format. The point is that time‑bounded collaboration is a proven social technology for turning curiosity into output at scale.
3. The Hackathon Paradox: Most Projects Die, But Learning Can Live
The highest‑quality critique of hackathons is not "they don't work," but "they don't persist." And that critique is fair. The default hackathon produces a prototype; it does not automatically produce adoption.
The hackathon is the ignition. Adoption is the engine.
If you light a match and walk away, you do not blame the match for the cold.
This brings me to the most important part: the purpose of an AI hackathon is not to "win." It is to manufacture three things that ordinary work rarely produces at the same time:
AI adoption becomes inevitable when these three exist. Without them, adoption becomes an argument.
4. Why Hackathons Are Particularly Powerful for AI Adoption
Engineers do not adopt AI because leadership "announced" it. They adopt AI when it makes them feel one of two things: competent or curious. The hackathon is one of the few rituals that creates both.
4.1 AI is tacit knowledge
Many AI workflows—prompting, evaluation design, tool‑use, model‑assisted debugging—are not easily learned from documentation alone. They are learned socially, by watching someone else do it, then trying and failing yourself.
4.2 AI is emotionally risky
For experienced engineers, failing publicly can feel like losing status. A hackathon, properly led, reframes failure as learning. That psychological safety is the foundation of experimentation, and I have always believed in normalising trying and failing.
I grew up in Maiduguri, where learning itself can come at a fatal cost, and I did not touch a computer until I was 14. When I finally did, a lifetime of curiosity and exploration was born. Later, as an 18‑year‑old moving abroad alone, I survived by becoming an explorer—taking risks, learning the language, engaging the locals, failing repeatedly, then trying again.
That is what a good AI hackathon recreates inside an organisation: a safe, time‑bounded permission to explore.
5. The Anatomy of a World‑Class AI Hackathon
Most hackathons fail for one simple reason: they optimise for spectacle (demos) instead of for adoption (repeatable workflows). A world‑class AI hackathon is designed like a research programme with a product runway.
| Phase | Goal | What "good" looks like | Common failure |
|---|---|---|---|
| Before (1–2 weeks) | Prepare the learning environment | Problem statements, data access, guardrails, evaluation criteria, tool setup | Teams spend half the hackathon fighting permissions and setup |
| During (24–48 hrs) | Compress experimentation | Fast hypothesis→test loops, tight experiment logging, live support from mentors | Long meetings, shallow demos, no measurement |
| After (2–6 weeks) | Convert outputs to adoption | Selected projects get time, owners, and a production path | "Monday graveyard" (most projects go inactive quickly) |
5.1 Design principles
- Outcome‑focused constraints: pick problems with measurable outcomes (time saved, accuracy improved, incidents reduced).
- Guardrails that liberate: clear rules on privacy, security, and safety so teams can move fast inside boundaries.
- Experiment tracking as a first‑class citizen: no experiment "counts" unless it's logged (inputs, metric, conclusion).
- Cross‑functional by default: AI adoption is not just code; it is data, product, risk, and people.
5.2 A simple 2‑day format that actually works
6. The Post‑Hackathon Runway: How You Prevent "Monday Death"
We have already seen empirical evidence that many hackathon projects go inactive quickly. The remedy is not to shame teams. The remedy is leadership support and ownership.
Here is a lightweight but powerful approach I recommend:
- Pick 3 winners, not 30. Winners should be selected by evidence: measurable outcomes, reproducibility, and clarity of risk.
- Assign an owner and a sponsor. Owner drives execution. Sponsor removes organisational obstacles.
- Give a real time allocation. Not "keep working on it if you can." Give an explicit 10–20% capacity for 4–6 weeks.
- Ship a small slice. One workflow, one service, one internal tool. Then expand.
- Publish the learnings. Even the failed projects must produce reusable artefacts: prompts, evaluations, checklists, code snippets.
The best hackathon output is not the demo—it is the documentation that makes the next demo inevitable.
7. What You Should Measure (If You Want Professors to Respect It)
If an Oxford professor asks, "How do you know the hackathon mattered?" you should not answer with vibes. You should answer with measurement.
| Metric category | What to measure | Why it matters |
|---|---|---|
| Adoption | % of participants who use the tool/workflow again within 30 days | Hackathons should create repeat behaviour, not one‑off excitement |
| Learning | # of experiment logs written; # of reusable prompt/eval patterns created | AI capability scales through shared artefacts |
| Impact | Time saved, defects reduced, accuracy improved, incidents prevented | Outcomes are the only honest currency |
| Culture | How many teams share "what didn't work" openly | Psychological safety predicts future experimentation velocity |
8. In Conclusion: Hackathons Are a Leadership Statement
At their core, hackathons say something loud about an organisation: "We have the courage to pause delivery to invest in learning." That is not a scheduling decision; it is a cultural one.
My leadership philosophy has always been empowerment, trust and daring to fail. Hackathons operationalise that philosophy in a way that training sessions and policy memos rarely do: they give people the time, the permission, and the social environment to explore.
And when stakeholders come looking for someone to blame because an experiment did not work, I have always preferred a different posture: I detest blaming and finger pointing, and I gladly give myself to blame, not anyone in my team. That is exactly the kind of leadership posture that makes hackathons safe enough to produce real learning.
If AI is your new competitive advantage, then the hackathon is your rehearsal for the future—where the organisation learns to be brave in public.
Having a dedicated day or two to experiment is often understated. Yet, in my experience, the best learnings and the most honest AI adoption outcomes come from when people gather—not to talk about AI—but to use it, struggle with it, measure it, and then share the lessons with humility.