Last weekend was the National Day of Civic Hacking (NDoCH), a country-wide effort to bring people together to solve problems through hackathons, brigade meet-ups and block parties. At their core, hackathons are a simple idea: get a bunch of people together to come up with ideas to solve a problem, particularly through the creation of a working prototype and a short presentation. Beyond this, there are wide variety of ways companies, agencies and groups can integrate it to promote ongoing concerns. Hackathons can be used to locate talented coders as a kind of outsourced headhunting. Activists use them to solve problems as a collective. Companies may be interested in promoting the use of a certain platform, to populate an “app store” or gain traction in the developer community. Yet they can frequently afoul for a variety of reasons. Here are five pragmatic suggestions to keep in mind when running a hackathon:
Balancing – while groups can arise organically, it’s also important to make sure they have the right mix of participants and resources to keep them going. San Francisco State University’s model was closely aligned with the national effort, and presented participants with a selection of ideas to implement. This hackathon was more specifically focused on coding, which worked out well because engineering-inclined students from a local coding boot camp showed up. When ideas presented aren’t well-matched with participant groups, balancing qualitatively different skill sets can be a challenge. The most obvious example of a problem with balancing is when groups find themselves asking a technical question they don’t know the answer to, but can equally be developers who latch on to an implementation before exploring all options. As a loose guide, at the Innovation Lab we advocate for an even mix of hustlers (business), hackers (coders) and designers.
Scaffolding – hackathons can be valuable learning experiences where ideas come from the ground up. This requires scaffolding where prompts and short segements moved through different stages of design. If it’s difficult for a team to understand where they should be working towards as a team, they can lose focus and drift apart. It can feel overbearing to say “now we’re moving on from idea generation to narrowing down to three ideas” but clear prompts help groups stay on the same page and make progress. There may be times when participants have their heads down working – coding, creating wireframes, making powerpoints – but they should be clear on the goals and task at any given time.
Timing – Along with scaffolding towards specific goals, hackathons by definition take time. Hack Palo Alto had four “idea hackathons” which had a number of local agencies contributing to prompts that helped focus participants on local problems. However, the activities started late, had vague prompts and were rather rushed, leaving us scrambling to put together ideas for an unclear goal. It should be noted that delays were often not the fault of the organizers – at one point a jr. college band started playing an amazing but extremely loud cover of the Black Keys. So keeping control over the space is an issue as well.
Openness – openness is a complex term with many implications that deserves a more careful unpacking at a later date. For now, let’s just say that openness was a central motivation of agencies and participants. Government agencies want to have their data used to demonstrate the effectiveness of various initiatives. One member of the team I was part of at SFSU was part of Lucas Arts until it was acquired by Disney and he was laid off, meaning that he couldn’t use much of his work over the previous six years on the job market. Participating in open-source projects was a chance for him to create a public portfolio and show evidence of being able to collaborate.
Deliverables – be clear about what the final product can be, and if a winner is to be declared, what criteria the team will be judged on. Also, where will these project ideas go? There are well-known examples of products developed out of hackathons, such as Adobe’s Phonegap, and it’s clear projects can find a home in companies. But a more open perspective can leave the next step for projects unclear. Uploading a project to Github is great, but what would be better is suggesting what the next level is. Don’t simply say that the projects will be “evaluated” – what will happen to them? Will they be tested in the field? Can organizations offer other kinds of support for people wanting to develop an idea further?