Toronto saw its first Urban+Digital event on February 23rd 2013, a conference built upon global Open Data Day in Toronto. Part of this conference was a mini-hackathon themed workshop that took place at the Centre for Social Innovation. The event was a combination of a charrette in terms of speed and output, and a traditional hackathon in terms of topic and focus.
Our time was quite limited, so the hope was to have a focused learning experience for the attendees. We led the event based off of our backgrounds in social science, design, new media, and software development. This translated into the technology component being de-emphasized with respect to the ideation process, but allowed for a fairly smooth translation between idea and on-the-ground potential for the different projects.
We started off with about forty people interested in taking part in the hackathon. After arbitrarily splitting people into four groups, we tasked them with introducing each other and coming up with a direction that they would like to investigate. They had fifteen minutes to accomplish this task, and specifically had to record their ideas and discussions on a piece of butcher paper as they went through the process. This was followed by a brief presentation, and finally an opportunity to re-order themselves between groups.
What we saw was two ideas emerge immediately as being strongest, and groups gravitated towards those spaces. These two groups, “Local Layer Library” and “Neighbourhood cheat sheet,” proceeded to work for two and half hours, at which point they presented their work and findings to the rest of the Open Data Day audience.
Broadly, participants reported satisfaction and happiness with the process, but there were some great notes for next time.
In speaking with some of the participants afterwards, they saw the early ideate-and-resort process as a valuable technique to both meet people within their group. It allowed ideas to emerge naturally, but for people to not feel trapped by the ideas that they may or may not agree with. There was an added benefit in allowing natural leaders to emerge in the pitching process, and for those leaders to gain trust early on.
A frequent challenge with hackathons is that organizers or members see it as an opportunity to get “free labour” for an idea that they don’t feel empowered to act upon. We found that already conceived or baked ideas had relatively little traction within the different groups, because other participants felt little or no agency in working on these ideas. What ended up happening was that these ideas didn’t attract group members when we resorted, but did allow those people who had come up with them a space to articulate their interests and expertise.
Throughout the process, we stressed the importance of communication in presenting and selling ideas to an audience, suggesting that the participants focus on creating communication artefacts versus bits of code in the small amount of time they had to work. This issue of time was foremost in the structure and outcome of the event, in my opinion. A hackathon that expects tangible software artefacts cannot take place over several hours. In fact, one should not expect more than a shoddy prototype out of a three day weekend event. The value of the hackathon comes in how it connects individuals within a domain of interest, and surfaces new knowledge and capabilities around that domain. Put another way, the artefacts of the hackathon ONLY have value in that they facilitate building soft connections between people and ideas, and possess no intrinsic value outside of this process.
The presentations at the end of the hackathon were exciting for the participants, but less so for the audience. We believe that giving people a forum to present their ideas gives closure and an opportunity for evolution, and so in the future, a thirty-second or one-minute pitches would be more effective for exciting the audience. More information can be created in a conference poster/booth approach for those seeking a deeper understanding.
Following this event, future hackathons and charrettes can be better facilitated by increased clarity around what participants can expect from their time investment. This event saw a lot of its challenges emerge as a result of the expectations set around the “Hackathon” format: some participants came to create existing ideas, others came to generate new ideas, many others simply came to learn. By not normalizing these expectations prior to the event, many of the former group were frustrated by the seeming unwillingness of the latter two groups to follow their “brilliant” plans, while the former two groups felt marginalized by those who were asserting themselves as experts in this space.
Facilitating groups of mixed expertise but similar interests is always a challenge. We had to constantly be moving between the groups to make sure that ideation was being tied to artefact creation, and to help the participants get past perceived roadblocks around technology or presentation format.
One of the biggest challenges was making sure that the technology minded felt engaged in the ideation process, but didn’t jump to implementation. Fundamental to this whole process is empowering all the participants to feel like they can engage in a complex problem and realize solutions through a network of supportive peers. We want to open doors and let people dream big (though realistically), instead of forcing a conservative outlook on the broader technologies or infrastructural capabilities. Tying these ideas to on-the-ground realities is vital, but for a different context.
We were excited with how the hackathon went, and in the future, we think events should be longer, more focused around a hackathon OR charrette format, and very conscious of the expectations being set around language and format. We should be careful about the language we used to describe our facilitation techniques, but not be hesitant to take new or unknown steps in bringing people, ideas, and problem spaces together!