Published: May 15 2011

This is a second in series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook over the summer.  For other posts in the series, see here.

With finals over, we are starting to lay the groundwork for the next PennApps 2011 hackathon, scheduled from September 2011. As we go through the process, we're making sure to have an organizational structure that ensures that key tasks have owners who are ultimately responsible for getting things done.

It's (theoretically) possible to organize a hackathon by yourself, but the task is pretty large if done right. At least three distinct skill-sets end up being required:

  • Technical Your hackathon is going to need a website.  Depending on the technology being used, you may want to provide simple hosting/accounts for participants or unlock a number of phones if you're offering loaner units.  If you have any sort of popular voting or demos after the competition, that part probably needs to be built as well.

    Somebody who understands and can (at least competently) put together a website and administer a Linux VPS somewhere is going to be helpful. We had several people work on the technical side for PennApps, but having a key person understand the entirety of the tech stack meant that there was a central go-to person who could troubleshoot and distribute work.

    Gareth adds: One thing we found in 7Cubed was that it was a huge headache if we used personal accounts for blogs/website registration/etc. This made it so only a single person could make changes to these resources, which caused a bunch of friction. 

    The solution there (or at least one we've been using) is to create a your-hackathon@gmail.com (or, if you don't mind configuring Google Apps, hackathon@your-domain.com) and share the password across the people that neeed to register/maintain everything.  This is not a particularly high-security approach, but works splendidly for something limited like a hackathon.

  • External Hackathons require a lot of conversations, from sponsors to judges to the University administration to the providers of the location to the students themselves.  We also ended up working with the University's innovation hub and the student government as well.

    Reaching out and keeping all of these stakeholders happy is a job all in itself, requiring a diplomatic approach and an enthusiasm for convincing people to help you.  In practice, the external person tends to also make sense as a reasonable MC for the kick-off and the person who gets enough sleep during the hackathon itself to be coherent enough to run the demo session.

    Gareth adds: There should be a single person operating external relations, or at least a single person assigned to manage each single external relationship. This prevents the "oh I thought you replied to that three days ago!" syndrome.

  • Operational We've found that a hackathon demands a reasonable amount of 'running' during the event itself. From registering participants and making sure they have a place to work and sleep to ensuring timely food delivery to ensuring that judges and speakers are able to arrive on time to are well treated during the event, to running midnight raffles, we've found that having a dedicated "behind the scenes" role ends up being critical to a smoothly-running event.

    Unlike the first two, the operational role doesn't require a substntial amount of work until a few days before and during the event. Bringing in somebody who hasn't spent the past several months sweating over the planning details helped us get a fresh perspective and not worry about the quality of day-of execution.

Your organizational structure may have multiple people wearing multiple hats or certain roles split; regardless, make sure everybody on the organizing team (and probably amongst the participants as well) knows who the go-to people are when questions arise.