At Code for Boston, we’re no stranger to the hackathon. We’re about to launch into our third annual National Day of Civic Hacking event this coming weekend and as our core team strategized our programming a while back, we realized we kept coming back to the same question:
What makes a successful hackathon challenge?
That is, what kind of pitch will get participants, interested, engaged, and – perhaps most importantly – willing to give up their spring weekend of freedom to work towards a civic solution?
This year, we tried especially hard to work towards our goal of community engagement for NDoCH. In doing so, we made a concerted effort to reach out to community groups to try to better understand the challenges they face and the problems they deal with on a daily basis.
“It’s easy for us as technologists to come in and say, ‘Here, we made this app for you. It’s going to fix your problems,'” said Matt Rouser, a Code for Boston core team member, “But if we don’t actually have an understanding of the problems these groups are facing, no app is going to be very helpful.”
In order to better understand the issues faced by community groups – both for this year’s NDoCH and for Code for Boston projects going forward – we consulted with groups like the Dudley Street Neighborhood Initiative, the City of Cambridge Department of Human Services, and the Codman Square Neighborhood Development Corporation. We wanted to learn about what these groups see every day in their communities and what problems they are constantly running up against. We tried to combine the information these groups provided with our civic technology expertise to help our problem stakeholders craft what we hope will be successful hackathon challenges.
Because Code for Boston is not just for coders (despite the name), we always try to determine whether a technological solution is necessary or helpful. When dealing with community groups who work with and represent underserved segments of the population, we must always remain cognizant to the fact that access to technology is not a given. Additionally, some of the community groups and populations with whom we work would be better served by crafting a policy recommendation, creating a research plan for a long-term study, or better marketing of currently available resources.
While brainstorming with our partner community groups, we tried to keep our constraints in mind. Because of the nature of our hackathon, we have one weekend to take some initial, actionable steps towards finding a solution to a civic problem, and craft a project that can be long-term, sustainable, and solve a real need.
Things we have to consider:
Scope of the problem. What’s actionable for a weekend-long project. For instance, we’re not going to solve “homelessness” with 12 hours of working on an app, but we may be able to determine that youth between the ages of 13-18 are particularly at risk for homelessness because of certain factors and target ways to address one or two of those factors. So being realistic about the scope is key.
Potential for sustainability and whether or not the project has legs going forward. We all know that hackathons are great at starting projects, but they’re not great at maintaining them. Too many projects with great potential fizzle out after the weekend’s activities are done. Because the projects we’re looking to tackle at our event address systemic problems and not quick-fixes, it’s important that what is completed serves as a proof of concept going forward. In reality, the work that begins at a hackathon should inspire participants and community groups to continue working towards a solution in the weeks and months to come. We look for projects that can be ushered into Code for Boston work at our weekly hack nights or issues that we can continue to address in the future.
Problem definition or what are we actually trying to do/what are we ready to do based on what we know? There are big, systemic problems that we know can be addressed but understanding the actual ask is crucial. For instance, people need access to healthy food, but do we need to do some more research into where food is lacking or the systems in place for getting food where it needs to go? Making sure we’ve defined the problem in as focused a way is helpful. Instead of saying, “We’d like to work on getting people access to healthy food,” we can say, “We’d like to explore ways in which we can make sure school age children have access to healthy meals during the summer.” Specifics are key.
Make it hit home. People care about where they live, but they don’t always know about the problems their neighbors face. If we can open up our neighborhoods and communities and foster community spirit and pride, we can make a huge difference. Make it personal. Make people care. Pitching about nameless, faceless demographics is never as engaging as using specific examples. “Dorchester has a 16% unemployment rate” is not as targeted as saying, “Richard, a father of three living in Dorchester, has been out of work for nearly two years.” Personal details make a huge difference.
“Civic” is by far the more important word in “civic technology,” and the projects on which we work aren’t helpful if they’re not solving a real need and working towards finding solutions to community problems. All of these things are critical to keep in mind as we work with community groups and challenge participants to ensure we have as productive an event as possible and that the effects can be far-reaching.