A reflection on Hackathons in 2011

While I am reflecting, I thought it a good time to consider hackathons. In 2011 the term “hackathon” became common and many cities all over the world opened datasets for developers to build applications around. Below are some lesson’s learned to better position a hackathon to a government context:

Lesson learned #1: A hackathon is a means to an end, not the end.
Hackathons are often talked about as if the event itself were the goal, overlooking the actual content of the event. A hackathon is not a box on the “is my government being innovative” checklist and it is not a thing. But rather, a hackathon is a method or an approach, a way of developing solutions. If a hackathon is to be part of the government problem-solving toolkit then, like any other method, it should be documented and improved upon. Watch out for Matt Chwierut‘s thesis on the Summer of Smart hackathon series!

Lesson learned #2: Don’t just make solutions, spend time identifying problems.
Government has to calculate its risk carefully, has to think long-term, and balance numerous social and economic metrics. As such, problems need to be clearly identified and scoped. I have seen few hackathons that clearly state the problem to be solved. The result is usually lots of solutions for niche end-user problems. While this is useful and has produced some great solutions, knowing where the highest impact could be made might help to align solutions with problems faced by many as opposed to a few.

More focus on problem definition would also better identify communities to solve the problem, thus creating richer solutions. For example, a hackathon to generate solutions for patient-centered healthcare might be of interest to medical providers, heathcare recipients, service designers, coders, and healthcare or ICT NGOs, as opposed to a hackathon with a bunch of disparate datasets, likely the attendees would primarily be software developers assuming a need and designing the service delivery in addition to coding the app.

Lesson learned #3: It doesn’t end at the hackathon
As much as it doesn’t begin with the hackathon, it also doesn’t end there. A hackathon as a means, not an end, highlights that there needs to be a driver and a motivator. The driver is a good problem definition (see #2 above). The motivator, considers what are the incentives to ask smart and busy people to work together for free to solve a civic challenge? Altruism, public service, and a mission-driven ask can go far (consider the development of Linux being done by an unorganized unpaid workforce who challenged one of the largest corporations of the world), but how about being rewarded with access to an incubator, something like the Y Combinator or Code for America’s Accelerator to shape your 2-day concept into a working prototype, a product, a business? Or working with the City to deploy your prototype as a pilot? And if a civic hackathon could spin out start-ups, products, and entrepreneurs, in addition to creating some really great apps, then we have demonstrated a model, not only for problem solving, but also for economic growth!

As a quick mention, I think the Summer of Smart hackathons did a great job diversifying the community of problem solvers and the Code for America Iconathons did a tremendous job scoping the challenge around different topics.

2012 will be a very exciting time to shape the hackathon into a sustainable approach to civic problem solving. Here in SFgov, we are using these lessons learned to inform the design of a platform called ImproveSF that will launch in early 2012. By book-ending a hackathon with ImproveSF on one-side and an incubator on the other-side, then we have a better chance of aligning solutions to actual problems and making those solutions sustainable by generating new business!