Ask HN: What makes a good hackathon?

I think of hackathons (and game jams, which I'm more experienced with) as extended parties. You do sit down and get work done, but the atmosphere and presentation are important and make it special. Everyone wants to start near their comfort zone, but also leave happy and with some new perspective.

That means getting all the details right, starting with clear statements about what the event is and what kind of people are expected, the time and schedule, achieving physical access to the venue, who to contact for questions, and what kind of refreshments(if any) will be on tap. Every one of these things will change who actually decides to come: For example, if the venue is in a seedy part of town, people who feel most vulnerable will stay home without assurance of a ride or escort. Photos of an appealing venue can often swing people who were on the fence. Prizes are a question mark as they can massively shift the participation incentives from "do something I like" to "beat the competition", putting a sour note on the whole thing. Unless you have a specific agenda that naturally leads to a competitive context, I would keep it light and try to achieve an "everyone wins" model.

Once on site, the role of the host is one of making sure quality conversations are being had. Team size and makeup is important; teams that are too large and too full of strangers tend to get bogged down in establishing a process and buying in on a project idea. Teams that are too unbalanced in their skillsets get bottlenecked. Teams entirely consisting of friends can usually be very productive, but sometimes the event just becomes a vehicle for whatever they planned to do(which is not always bad). The host can help in all of these by using their position to reach out and make connections that the teams aren't inclined to make on their own.

After the event is over, it's time for followups. A little push can help everyone finish and clean up their project - if you offer to put their project in the spotlight, they'll do a little more than they would if they feel like it's a throwaway, and they'll develop more of a lasting connection with you, the organizer.

Rigid flexibility. Have a well defined end goal, with judging criteria available from the start, but don't restrict contestants in what resources they can use, tech, people, etc

Along the same lines, participants who spend all their time running around and "networking". Socializing and meeting people is obviously one of the draws of these events, but a few bad apples do tend to ruin the atmosphere for everyone.

We did a hackathon today. Several things made it a successful hackathon. First; a Product Owner ran the early brainstorming and problem setting. This made a big difference. The engineers were coming up with new products but with the discipline of what works in defining a real product.

Next they broke up into teams of two or three and worked on a specific product idea or feature/improvement. There was a break in the middle of the day when everyone had lunch together, and then back into coding afterwards. The hackathon started at 9am and ended at 4pm with every team having working features to demo.

At least one of the features demo'd will go straight into the existing product, the others will be demo'd to other stake holders and will most likely end up in the existing product but as a more polished feature.

So in summary having a Product Owner over see the brain storming, having everyone work in the one branch together in small teams, and making the new features or products demo'able by the end of the day.