Most companies judge a hackathon the same way. Which idea won? Did anything ship? How many projects made it into the roadmap?
Wrong questions.
When Debra and I had Fredrik Härén on Corey-osity Unleashed, he said something which stuck with me. Fredrik has spent 25 years exploring creativity in more than 75 countries. His view on hackathons: they're about group dynamics. The ideas are the excuse. The real output is learning who works well together when the clock is running.
I think he's right. And I think most leaders miss it because they're staring at the demo screen instead of the room.
The Ideas Mostly Die. The Data Says So.
Let's start with the uncomfortable numbers.
Alexander Nolte, Irene-Angelica Chounta and James Herbsleb studied what happens to hackathon projects after the event ends. They looked at 73 hackathons on Devpost, with 1,912 participants working on 592 projects.
Here's what they found:
- 35.3% of projects had at least one commit after the hackathon ended.
- By day six, only 17.06% still showed activity.
- After five months, 3.55% were still alive.
So if you run a hackathon to fill your product pipeline, you're betting on roughly one project in thirty. Those odds would get a product manager fired.
Their next finding matters more. Short-term continuation tracked with prep work, the number of technologies used and winning a prize. Long-term continuation tracked with something else: skill diversity among team members. They also found intensive short-term activity linked to a lower chance of the project surviving long term.
Read those two findings together. The all-night sprint to win the trophy doesn't predict success. The mix of people on the team does.
What People Took Home Instead
Nolte and his colleagues also studied a corporate event: Microsoft's One Week hackathon in 2017. They followed five teams before the event, straight after it and four months later.
Most team members said they wanted to continue their projects. Few did. The teams who kept going had prepared carefully, focused on a shared vision, promoted their work afterward and fit an existing product line.
The individual outcomes told a different story. Participants reported gains in skills, careers and networks. One said "I met fantastic people." Another described their network inside the company as having exploded.
Nobody said "my idea changed the company." They talked about the people they found.
A health hackathon study showed the same pattern with harder numbers. Fattah, Gabrilove and Bradley mapped the participants' professional network before and after the event. Network density rose from 0.12 to 0.30. Ties between people from different professional backgrounds rose too, with the E-I index moving from 0.26 to 0.43.
In plain English: after one event, people who never talked started working together across disciplines. You won't find those new ties in a product roadmap. It still shows up in every project those people touch next.
The Fair Counterpoint
I don't want to pretend hackathon ideas never matter.
Facebook's engineering team wrote in 2012 how the Like button, Chat, Video and Timeline all started at hackathons. They also claimed 60% of projects from two recent hacks shipped, either internally or to users.
And a study of 22,183 Devpost projects found around a third of the code written at hackathons got reused in other projects.
So ideas do survive. But look at how Facebook described its teams: cross-functional, "with everyone from engineers to lawyers to UX researchers." The internal wiki was full of posts like "Anyone want to code with me?" The machine producing those features was a company-wide habit of strangers teaming up. The features came out of the relationships, not the other way round.
Why Leaders Measure the Wrong Thing
I get why executives count shipped projects. A shipped feature fits on a slide. A new working relationship between a backend engineer and a customer support lead doesn't.
Here's how it tends to go. Leadership approves a hackathon. Everyone enjoys it. Three months later somebody asks what came out of it. Nobody points to a feature, so the next one gets cut from the budget.
Meanwhile the real return goes unrecorded. Picture it. Two people from different teams now message each other before making a design decision. A junior developer who stayed quiet in standups found out she's good at presenting. A manager learned which of his senior engineers panics under pressure and which one gets calmer.
None of this appears in a sprint report. All of it changes how your next real project goes.
If you only measure the ideas, you'll decide hackathons don't work. If you measure the people, you'll wonder why you don't run them more often.
What a Hackathon Shows You About Your Team
Pressure strips away the performance people put on in normal meetings. For 24 or 48 hours you get to see how your team behaves when the plan falls apart and nobody has time to be polite.
Watch for these things:
Who pulls strangers in
Some people form a team with their usual lunch crowd. Others walk over to the quiet data analyst from another floor and ask what she's working on. The second group builds the bridges your org chart never will.
Who listens when it's late and everyone's tired
At 2am, egos show. Fredrik talked on our show about ego as the biggest blocker of ideas. A hackathon puts ego on display. The person who still asks "what do you think?" at 2am is someone you want leading a team.
Who does the unglamorous work
Somebody sets up the repo. Somebody fixes the build. Somebody writes the demo script so the presenter doesn't freeze. Those people rarely win prizes. They're the reason anything works.
Which pairings click
Two people from different departments who finish each other's sentences by hour ten? Write their names down. You found a pairing no reorg would have produced.
How to Run a Hackathon for the Right Reason
If you accept the real value is in the people, the way you run the event changes.
Mix the teams on purpose. Nolte's research links skill diversity with long-term survival. Don't let engineers cluster with engineers. Invite finance, support, legal and sales. Facebook brought in lawyers. Your company has people outside engineering too.
Stop making the prize the point. Winning predicted short-term activity, not long-term survival. Big prizes push people toward flashy demos and all-nighters. Give smaller recognition for things like "best new collaboration" or "most helpful to another team."
Send a manager to watch, not to judge. Give someone the job of noticing who collaborates well. Not to rank people. To learn who should work together next quarter.
Follow up on the pairings, not only the projects. Four weeks later, ask participants who they'd want to work with again. Then put some of those people on a real project together.
Collect feedback on how people worked together. Ask each team member how their teammates behaved under pressure. Who listened? Who shared credit? This is the same kind of honest, behavior-focused feedback we built BAT to capture. A hackathon gives you 48 hours of fresh examples to talk about.
The Question Worth Asking
The next time someone proposes a hackathon, don't ask "what will we build?"
Ask "who will we learn about?"
The ideas will mostly fade. The data is clear. But the engineer who met the support lead at 3am and fixed a customer problem together will remember it. So will the support lead. Those connections outlast every demo.
So look at your last hackathon. I bet you know which team won. Do you know which two people should now be working together?