How to unsuck the hackathon experience in five easy steps
Building the next great billion dollar company in a weekend is only one of many vastly overrated hackathon myths
Rolling through the southern Louisiana swampland on a bus with an overflowing toilet isn’t the best way to spend an afternoon hacking. Nor does a stinky toilet alone rank as a disaster.
As a hackathon participant, I’ve been blessed to end up on my fair share of winning teams. I’ve also managed to hack my way into situations that could only be described as a dumpster fires. Sometimes both descriptions managed to describe the same team.
As an organizer, I understand how directly connected the attendee perception of an event is related to the work that an organizer does or does not do when designing the event environment.
In truth, a surprising amount of good can come from cramming several overcaffeinated strangers into the small space for 72 hours. What dictates whether people have a great time at the event or hate themselves afterward often boils down to expectations we project for the event, the teams and the individuals involved.
Step 1: More problem-solving, fewer business plans
Meeting new people is one of the big reasons people endure hackathons to begin with. The idea of being placed on a team allows attendees a natural way to enter conversations with one another and the whole ‘community of makers’ vibe is generally awesome.
Until someone shouts out “this idea is worth a million dollars.”
Seriously, screw that guy.
As an attendee, you can avoid this issue automagically by only participating in events that are focused on building open source projects. This immediately removes the typical ‘bros’ that show up to prospect for quick money projects and replaces those individuals with a room full of quirky individuals who just want to build weird stuff.
The CANVAS hackathon hosted by Al Jazeera in Doha, Qatar provided a good example of how the dynamic of an event can pivot on this single concept.
The participants were given open-ended objectives centered on specific topics that they were tasked with building around. The projects created were bundled together and made available for anyone to use.
Some of the projects were awesome. Others were outright weird, which is awesome in itself. While there were awards for the projects, the biggest payoff was seeing the work begin springing up online in other forms.
Eighteen months have passed since that event and I still find myself having a conversation every week or so with someone from that event.
Contrast that to something like StartupBus where days of building together as a team can dissolve the instant one VC says they like an idea. What started out as the joy of making becomes who-owns-what of something that didn’t exist 48 hours earlier.
While that didn’t happen to all of the StartupBus teams, I know it didn’t happen to any of the CANVAS teams.
Step 2: Embrace diversity on all levels
This one seems obvious but I would challenge organizers to think beyond age, race, gender and orientation. We need people from different industries and different socio-economic backgrounds to begin solving problems.
You get two major things in this adjustment.
On one hand, you bring people in with skills that simply haven’t considered the problems of a given industry.
I recently participated in a SNDMakes event in Chicago focused on the gaming community. The closest that I can claim to having experience in the gaming space was working on an iOS app five years ago. The entire concept of the event was a bit foreign to me. So there I was at the Cards Against Humanity headquarters (nice space, btw) in a group with a journalism student, a social documentary gamemaker and a cartoonist.
What the hell were we suppose to build together?
After a fair amount of whiteboarding and coaching from the roving mentors, we had a concept for a project about a problem that 24 hours earlier I didn’t even know existed. And I met a boatload of awesome people along the way.
Big win, all involved.
On the other hand, finding participants from different socio-economic backgrounds can add understanding that is often lacking from these events.
This isn’t simply about finding an unemployed person to go talk to. There are plenty of people that are struggling to find ways to pay the rent in some of our cities. Many teams at these events lack the required perspective to see an issue they are trying to address accurately.
Perspective is often the element needed to unlock the empathy necessary to solve the problem in front of us.
So finding a preschool teacher or sandwich shop owner for your hackathon team might not add a lot of bandwidth for backend development but it could add a ton of perspective which is crucial if you want to get anything done.
Step 3: Practice the art of receiving gifts
We are taught from a very young age that if we are given anything that something is going to be expected in return. This mentality has given root to a dangerous do-it-all culture in both our workplaces and society-at-large. For many, you either shoulder the burden of all the important tasks related to your job or you are shrouded in shame because you needed the help of others.
Luckily, hackathon time constraints won’t allow any one individual to dominate the team and attempt to shoulder the entire workload. But that doesn’t mean that it won’t be tempting—especially for people who have a predisposition to feel shame when asking for help.
Both attendees and event organizers should share the same goal—everyone participates.
Organizers typically do a good job of mixing in junior members or students into every group, but every group does not do a good job of managing this dynamic.
If you consider yourself to be a senior member on the team, it is your job to make sure that everyone in your group has a significant part to play. As a junior member, you also play a key role as it is your responsibility to speak up if your skills are not being leveraged.
Having been on both sides of the table, I’ve relied heavily on past opportunities to guide how I work with fellow participants and organizers during these events.
At CANVAS, Evan and Hari could have easily tackled the project on their own, but they made room for myself and others to participate. Handing over a significant portion of any project can be difficult, but our Street Stories team benefitted from everyone being invited to bring their individual gifts to the effort.
The Street Stories experience was in the back of my mind when I asked Eunice to handle the homepage design of our SNDMakes project. She was already our team stenographer, but that task alone didn’t feel significant enough and I suspected that she probably had more to offer. Not only did she do a good job for the team but she also learned more about Git and SASS along the way.
It is important to also recognize that there are always tasks to be tackled at these events that do not require coding skills or unique domain knowledge.
At CANVAS in Doha, journalist Yana Kunichoff lead our team through her eyewitness accounts of what it was like to be a reporter in Ferguson, Missouri during the first days of the Michael Brown riots. By helping us construct the virtual environment, Yana provided most of what was needed to build the project foundation. Given her impact on the project, it only made sense to have her lead the presentation when it came time to present our Street Stories project to the group.
At SNDMakes in Chicago, cartoonist Jackie Roche not only provided the backbone of the visual direction for the project but she also crafted custom illustrations on a tight deadline that we relied on to tell the story of our project during final presentations.
A cartoonist and a reporter might not seem like the obvious anchors to build a hackathon team around, but that would be undervaluing the art of storytelling. Your job isn’t just to build things, but to also explain why what you built is important. If you possess the ability to craft a compelling narrative, half your work is already done.
Both instances stand as examples of what is possible when you make room for others to fully participate in the process of solving problems.
Step 4: Go to sleep
Show me a happy group of event attendees at the end of one of these events and I will show you a group of people who managed to sleep more than four hours over the course of a weekend.
Destroying your body and mind are not badges of honor. They are signs of stupidity. The most productive teams I have been around, whether on a moving bus or a dedicated space, all have sleep as a common denominator.
Stumbling around with your eyes burning isn’t going to make the project any better. If anything, your sleep-deprived mind will make it impossible for you to be productive and that is the easiest way for you to let your team down.
Aside from the obvious upside of being rested, by limiting number of hours you have access to the event space, organizers manage to raise the value of the time together and participants find it easier to focus on the task in front of them.
Literally everyone wins.
This is an issue that I have professionally and personally struggled with for years and I know that my Hacktucky event in 2013 would have gone much, much smoother had I simply encouraged everyone go back to their rooms and call it a night. It was a good event, but it would have been better if everyone wasn’t so damn exhausted at the end.
We build better products and solve more substantial problems when we take care of ourselves and are more considerate of the people around us.
As much as I would like people to naturally manage this tendency to work through the night, it’s the task of the event organizer to signal to attendees that it is ok to hangup their superhero capes.
So shut down your event space for the night. Everyone will thank you later.
Step 5: Slack all the things
If you get too focused on ‘winning the big prize,’ you end up missing 90% of the event that you are sitting in the middle of.
While you are at the event to work with you team, there are other interesting people at the event that could use your feedback or insight.
In the past, giant email chains were past around and often got too noisy to be functional. Some folks still try to flyer the event space looking for help, but those efforts are often ignored when people put their head down and get to work.
The idea of a hackathon that doesn’t leverage Slack might seem crazy now, but just a couple of years ago people at hackathons were still largely communicating with each other like it was the 90s.
It isn’t enough for organizers just to have Slack, people have to be encouraged to use it. By preloading announcements, the code of conduct and team channels before the event, the SNDMakes team had a deep discussion of potential projects between all members of the community days before the event started. This created a place to focus event communication and allowed the teams to work together and help one another, even as they sat in separate rooms.
This tightly-focused din of discussion ends up providing just enough interaction between the teams for community building without being so disruptive that people don’t get anything done. When people who create can both build community and build products in the same weekend, they tend to leave very happy.
So go forth to solve, build, and create. And if you do it right, it might not even suck at all.