Why hackathons should conclude with an Expo
It’s all about building community
A year ago when we started MHacks, we were pushing the limits of hackathons by bringing in more than 500 hackers. To scale the hackathon model up, we needed to eliminate some of the bottlenecks. In doing so, we discovered the science-fair style expo for demoing, which I think is actually something every hackathon both big and small should do. Expos build community, draw focus away from judging and towards the hacks, and are a much more interactive experience than being lectured at for hours when you haven’t slept for days.
The Old Way of Doing It
Prior to that first MHacks, most hackathons would end with everyone demoing on stage in succession one after another. While this is a great way for people to practice public speaking in front of a large audience, getting lectured at for hours is a really weak way to end a high-energy event, especially when everyone is already tired. Additionally, making students better public speakers isn’t the goal of a hackathon.
Luckily for us, PennApps, the largest student hackathon at the time, was only two weeks before so we got to see first-hand some of the bottlenecks we should anticipate. They actually thinned down the number of demos to a top 20, but even that was a long enough time for half of the room to fall asleep and the energy at the event to come to a lull right at the end. Rather than students leaving wanting more, we left ready to get out of there and back on our buses to pass out.
Expos build community
The biggest benefit of the expo is how interactive it is. Rather than simply watch a team demo their hack, you get to jump on their laptop or smartphone to try it out for yourself right there. On top of the interaction with the actual hack, you get to interact on a personal level with the team. The most prime way to build relationships at a hackathon is to share what you’ve built. The expo facilitates this very experience. This sounds obvious, yet at so many hackathons we code until the end and then drag everyone from the new friends they are making to sit in an audience.
At expos I run, I encourage teams to have only one team member demoing at any given time, so that the rest of the team can roam around and check out other demos. This does two things: one, team members get to spend way more time with awesome hacks that they are actually interested in and two, each hack gets to demo tons of times to a bunch of different people who end up giving generally positive feedback rather than once to a judging panel who simply critiques their hack. While I would love to help students make their hacks better, I’m much more concerned about encouraging them to continue building. Expos produce a much more positive feedback loop.
Expos draw focus away from judging and towards the hacks
While it was really exciting to see 20 awesome demos, hackathons aren’t about the judging or the prizes. They are about hacking, and if you didn’t make it to top demos, you’re stuck in an auditorium getting demoed at for hours. At that point, the only thing you care about is when you can get to sleep and maybe seeing the one or two cool hacks you really liked.
[someone find me a pic of the quidditch line at the mhacks III expo]
At an expo, the energy level is high because people gravitate towards hacks that pique their interest. You still have the option to check out every hack if you want to or you can just spend a lot of time at the few hacks that blew your mind. This more opt-in structure lets people do what they want after hacking is finished, and it’s a win for everyone — you can check out hacks, hangout with your new friends, or even pass out right then until it’s over.
Expos scale
Expos are an especially good move if you’re throwing a larger hackathon. As you scale hackathons up, the number of demos you would probably be doing goes up. Letting everyone demo in front of an audience is nice, but at a large-scale you would be there all day. As long as you can provide enough wifi, power, and space for the expo, it scales extremely well. You can even invite the public to come check out the hacks people have built over the weekend.
No matter what your size, traditional demoing will always be plagued by technical difficulties as you have to bring each new team up to the stage and get them plugged in so they can demo. In an expo, everyone is demoing synchronously so you only need to set up once, then you’re good to go.
Expo Judging is tricky
The number one tradeoff of the expo is that it’s harder to judge. To combat this, we have figured out a decent distributed way of finding the best hacks. First off, you’ll want to number the tables in an orderly manner so that each number corresponds with a hack and an easy to find location in the room. Next, you’ll want to make sure all of your sponsors have a list of the hacks with their table numbers to decide on their own prize winners. Following that, you need a ton of manpower so you should enlist at least one experienced hackathoner for every 10 hacks. Send each of these “judges” to a segment of 30 hacks, so that every hack gets seen by at least three people. Have each of these people bring you back a list of their top hacks in order. Use these lists to, in effect, thin down the number of hacks you are judging. Send more judges to the hacks that are making it onto those lists. Voila! You have found the best hacks in the room, and everyone gets to continue demoing uninterrupted.
We commonly receive complaints that some teams don’t feel as though their hack has been judged. One of the reasons is that I deliberately don’t mark off the people I’m sending as judges, but you could easily combat that by doing so. Additionally, you may want to consider having some sort of crowd vote to play into the judging. I highly recommend using twitter. All of this said, the expo model is still very new and we can do 10x better especially with respect to judging. If you have any ideas, let me know: twitter.com/davefontenot
MHacks W2013 Expo in The Crisler Arena
