I spent last weekend at Hackcon, the hackathon organizers conference. On Sunday, I was tasked with taking notes for a workshop entitled “Being Different,” which spun out from Jeff Hilnbrand’s talk on the same subject. Instead of publishing my messy notes, I’m publishing a summary of our discussion, and some points I didn’t get to make day of.
The general zeitgeist going into the “Being Different” Hackcon workshop was that hackathons are all pretty similar: 24–48 hours, sponsors, prizes, apps, food, caffeine, and probably a midnight surprise. Each event might have it’s own little spin, but for the most part we were all working off the same model. This model, while tried and true, has several problems in it, which prompted our group to think about how to change it. The core of our discussion centered around two questions:
1. Why are hackathons so similar?
At first, the answer seemed to be simple: The model works.
Hackathons haven’t changed drastically since the first generation of student hackathons (hackNY and PennApps) largely because these events were so successful. In our discussion, many organizers recalled experiences of attending a hackathon early on in college, and seeking to bring the event back to their schools. Hackathons have an inspirational quality that makes attendees want to throw hackathons at their own schools. The answer is simple: organizers think hackathons are pretty much fine as they are. Problem solved, right?
Not quite. Hackathon organizers aren’t blind. They see room for improvement and growth in the hackathon model, but there are other factors at play that make organizers resistant to change. Here are a few justifications that were made for the similarities between hackathons:
- Drastically different events might make hackers from other schools less likely to attend.
- Changing your event can backfire. (One organizer told a story about how hackers complained when they threw a hackathon and didn’t invite sponsor representatives into the hacking space.)
- There’s no reason to differentiate because our local communities have not been exposed to hackathons, so they don’t realize that the event is the same as one from another school.
While these concerns may seem justified at first, they have the same logical flaw. They assume differentiation for the sake of differentiation, rather than differentiation for some larger purpose. Finding that larger purpose became the second question.
2. Why should hackathons differentiate?
In my opinion, this was really the wrong question to ask. For the hackathon community, differentiation shouldn’t be a goal. We shouldn’t be fighting over attendees; there are way too many students eager to attend hackathons for events to feel the need to compete. No organizers should elect to arbitrarily change their event to stand out in the crowd.
In our discussion, we discovered that many of us hadn’t thought carefully about why we were organizing hackathons in the first place. Without thinking through some basic motivations, the events become nothing more than copies of each other with slight variations. Throwing a good hackathon doesn’t mean looking for ways to differentiate, it means taking a step back an evaluating what the community needs.
First, find your audience and get to know them.
Are you hosting a hackathon for first timers? For burnt out veterans? For entrepreneurs? For designers? Depending on your audience, you should make different decisions about how long your event is, whether or not you have prizes, etc. In our discussion, many of our disagreements stemmed from the fact that we were organizing events for different kinds of people.
Make sure you know your scope.
Hackathons change lives. They create Computer Science majors, they make software engineers, and they can also do the reverse. A single bad experience at a hackathon can color someone’s view hackathons and the tech industry as a whole.
Many organizers had the attitude that by bringing the traditional hackathon model to their school, they were making an exclusively positive impact on their community. However, without addressing issues of inclusivity, health, and intimidation that come with that model, an organizer could unknowingly do great harm as well.
Finally, have a vision and a value proposition.
What will attendees get out of your event? What will keep thing there for the duration? What do you want to achieve? Way too often hackathon organizers get so caught up in planning that they lose track of any vision grander than hosting a hackathon. By solidifying a value proposition for your attendees, you can ensure that they leave the event satisfied.
Here are examples that were brought up of events that differentiate for the right reasons.
As Shy Ruparel will proudly tell you, hackNY has remained relatively the same for the past five years. Despite this, hackNY remains one of best hackathons out there. It doesn’t have the best prizes, or food, or anything really. The hackNY team has crafted the right event for those that attend it. It goes to show that being different isn’t always the solution. Execution on the basics goes a long way, especially at a time where hackathons gimmicks are all too common.
Three years ago, DevFest was a week long hackathon that intended to give participants the time they needed to build high quality products rather than basic hacks. Not a bad idea at all, but it was a bad fit for the Columbia community. With the Computer Science major ballooning in size, there was an influx of inexperienced programmers on Columbia’s campus. In 2014, ADI pivoted DevFest to focus purely on education, moving the hackathon to the last day of the week, allowing for the rest to be spent on workshops. This refocus made the event take off, allowing ADI to reach hundreds of students that would have otherwise felt unqualified to attend.
Building a better hackathon
My biggest realization in this discussion was that when we talk about improving hackathons, “different” is a red herring. So was Jeff wrong to say that we need more differentiation in hackathons? No. We shouldn’t aim to be the best in some category, rather we should aim to be the best event for our attendees. There are too many ways to do “different” wrong to allow that to stand as a goal strive for. Instead, lets focus on a more straightforward approach: finding an audience and serving them. We need hackathons to change, but we definitely need them to change for the right reasons.
Too often, I realized, we argue about how hackathons should change or what they should be, without realizing, that not all hackathons serve the same purpose. Computer Science communities differ greatly between schools, and so it’s only natural that hackathons should bend to accommodate them. If organizers are upfront and transparent about their values when organizing an event, we can hold them accountable for not taking the hackathon model for granted.
Have a Hackcon story?
Did you have a memorable experience at Hackcon? Write about it in a response to this post, I’d love to hear stories from conversations I missed out on.