What running a Cross-Government AI hackathon for 150 people taught us

Most hackathons produce clever outputs nobody uses: this one didn’t. We ran a cross-government hackathon with over 150 participants earlier this year. It was the biggest we’d organised, and like most events of that size, it raised as many questions as it answered.

Four things stood out. Not the logistics or the headline numbers. The things that actually changed how I’d approach it next time.

Real challenges produce real outcomes

Most hackathons are technology exercises. Teams pick an interesting problem, often one they invented that morning, and build something against it. The results are clever, sometimes impressive, and rarely useful afterwards.

We tried something different. Before the event, we spoke to senior leaders across public sector organisations and asked them to articulate genuine business problems, not technical wish lists. Actual problems their organisations were sitting on. Those challenges went onto GitHub in advance so teams could read them before the day started.

This changed the character of the outputs. Teams weren’t building solutions to hypothetical scenarios, they were responding to real pressure points that real organisations recognised. The difference showed when it came to presentations. Judges weren’t asking “but who would use this?” They were asking “how quickly could this be piloted?”

Several of the prototypes from that day have since been presented back to the organisations that contributed the challenges. Some are now forming business cases. That doesn’t happen when teams invent their own problems on the morning.

The lesson is simple: a hackathon without a real problem produces a solution nobody needs. Spending time upfront sourcing genuine challenges from the people who own them is not extra work, it’s what makes the rest of the day worth doing.

A leaderboard changes how people work

Judging 150 participants across multiple teams with multiple judges is a coordination problem. A show of hands doesn’t scale, and a spreadsheet shared between judges invites chaos.

We built a small app before the event using Claude Code which felt appropriate, given we were running an AI-focused hackathon. The app gave judges a shared set of criteria that progressed through the day: has the team defined a problem, have they started building, do they have a working prototype. Each judge could tick off against those criteria in real time. The scores fed into a leaderboard displayed on screens around the venue.

That leaderboard did something we hadn’t fully anticipated. Teams watched it. When a team saw they hadn’t checked off an early milestone that others had, it created a nudge to move. The gamification wasn’t about competition for its own sake; it gave teams a shared sense of where they were in the day and what came next.

It also made the judges more consistent. Because everyone was scoring against the same criteria at the same points in the day, the final scores reflected actual progress rather than how impressive a team’s final presentation was.

In the age of AI coding tools, the bottleneck is not speed, it’s the courage to start again

We watched teams approach the day in two distinct ways.

Some jumped straight into building. They had an idea, or half an idea, and immediately started working with AI coding tools to give it shape. For some of those teams, that worked. Getting something on a screen quickly helped them understand what they were actually building. The prototype told them things the conversation hadn’t. Others mapped and debated until the clock forced their hand.

Here’s what I think this tells us about modern development more broadly: AI coding tools have largely collapsed the time between idea and working prototype. You can have a rough version of almost anything in minutes. That changes the calculus. The old argument for extended ideation (that building too early locks you into bad decisions) is weaker now, because rebuilding is faster than it used to be.

But there’s a catch. The teams that got stuck were not the ones who built too quickly. They were the ones who built quickly and then couldn’t bring themselves to throw it away when the prototype showed them the idea wasn’t working. They iterated on a bad foundation instead of starting clean. The psychological safety to say “this isn’t working, let’s scrap it and go again” matters more than it used to. Speed removes one bottleneck and exposes another. That’s as true in a government department running a product team as it is in a hackathon.

Networking is a feature, not a side effect

This was a cross-government event. Teams came from different departments, different organisations, different professional cultures. The benefit of that is not just the prototype you produce. It’s the relationships, the shared problems you discover, the realisation that the thing your team has been struggling with for six months is something another department solved differently. That value is as real as anything built on the day — but it doesn’t happen automatically.

Next time, we will design for this more deliberately. Structured moments during the day that pull people out of their team and into the wider room. Not forced networking, but intentional pause points. The informal collisions that happen naturally in an office need to be built into an event.

The practical ask for attendees is simple: decide before the day what you want to get out of it. If you leave having built something but spoken to nobody outside your team, you’ve left value on the table. If you leave with ten new contacts but no prototype, same problem. Setting that intention at the start, even informally, changes what you pay attention to.

These are not lessons unique to hackathons:

• Real problems over invented ones.
• Feedback loops that show progress honestly.
• The confidence to scrap something that isn’t working.
• The discipline to treat the people in the room as part of the output, not background noise. Any short-horizon delivery lives or dies on the same things.

We know what we’d change next time. That’s not a small thing.