Hackathon 2.0 - Experimenting for Change

After months of planning, iterating, exploring and experimenting it was finally there. The CoJam weekend. What is CoJam? A hackathon. Yes, and… A social change initiative. Yes, and… An experiment. Yes, and... 

My work in design strategy and change mentoring means that I am often asked to facilitate, run and/or participate in a number of large scale group ideation sessions - the most popular format currently being hackathons. Most hackathons are very output focussed: Start a business, build a chat bot, solve a problem of some phantom description. Companies love them. And participants get a buzz out of them. Win-win, right?! 

Unfortunately, organisers are often less focussed on other - arguably just as important factors: What problem is the one that needs solving and why? What is the right (mix of) people we need in the room to be able to solve the challenge we have set for the event appropriately? How do we reach them? And what does the problem-solving experience for our participants look like? Being deliberate in answering these questions made CoJam a unique experience for me because the event generated opportunities for outcomes over outputs in a number of ways:

Following a process vs. Exploring a practice

Variations of the design thinking process are generously applied, in organisations and communities. They are more or less explicit and are usually conveyed through a number of instructions - a funky slide or a team coach trying to give people a set of tools to work through the challenge, based on their own experience. But understanding and then applying a new way of working in a matter of hours is a big ask, it’s not something people just ‘do’ because you ask them to.

The CoJam organiser team invested heavily in making a simplified vision of the design thinking process accessible by visualising the stages and enabling a potential ‘new’ behaviour. Instead of prescribing ‘the way’, CoJam organisers put together a suggested pathway that explained helpful behaviours, mindsets and tools while allowing the teams to diverge where useful and build on their own lived experience of problem solving. The expectation wasn’t to do things ‘our way’ - the expectation was to find a way that would work for the team, with some tools available if the team found them useful to progress through the challenge. 

The difference? One is a compliance exercise, the other is a learning experience. 

Designing with vs. Designing for

Giving up 2-3 days (or more) of your time to work (for free) on a topic you are passionate about is a privilege. As organisers, it is important to recognise that the hackathon model in and of itself excludes a large chunk of the population who are unable fit it. Be it care and family commitments, access or participatory limitations, associated attendance costs (financial or emotional, that a person incurs even if the event is free, including transport costs, care replacements, special dietary requirements, inability to meet family commitments, etc.) or ‘simply’ the nervousness around being in a room full of strangers that limits the participant audience. It is not uncommon for the same set of people to attend a variety of different events, because it’s fun of course and you do meet a lot of likeminded people - by default with similar interests. No matter how small or large the challenge, if we are not aware of this bias, we are designing without the same segments of our society every time. The result? We tend to design for ‘people like us’ and everybody else will just need to adapt if they want to access the solutions we are providing. At best, we are creating solutions we are building with someone else in mind, but that does not allow for those with relevant lived experience to participate in co-creating collective futures. 

Dependent on the challenge context, it is up to organisers to try and mitigate 'exclusionary' factors as much as possible to ensure the right mix of people are able to participate in the challenge.

Taking part in vs being part of

Grounded in the concept of belonging - this wasn’t just CoJam’s challenge to tackle during the weekend. It was also the overarching theme that we used to curate the event. What does it mean to feel like you belong? What are the opportunities for us as organisers to make people feel like they are meant to be in this room - like they have a role to play in solving this challenge? It’s a conscious effort - a deliberate experience - that brought the teams closer together, and allowed all of us to connect more deeply. It’s one thing to participate in an event and solve a problem, then go home and get ready for work the next day. It’s another thing entirely to feel like you were (or continue to be) part of a group that collectively explores opportunities to make the world a better place. 

Maya Angelou explained the difference perfectly, “I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.” Be intentional about the feelings you evoke among a group of people who need to get something specific done!

The role of the coach

A note on coaches. Every hackathon has them, but not every person is well equipped to be a coach. Just because you are experienced in a topic or an approach, doesn’t mean you are good at enabling others to access your knowledge and learn from and through it. 

A deliberate selection of coaches is important. But equally important is it to equip and empower coaches to support teams on the day. Many hackathons I’ve participated in simply throw coaches in the deep end. Brief them for 15 minutes on the day and then let them loose on the teams. That's hard on everyone - the teams and the coaches!

An integral part of the CoJam toolkit was a coaches guide that set a framework for the role of coaches during the weekend and a mental framework for understanding if teams were performing well or not, in which case support was at hand. The teams were supported by the coaches, the coaches were supported by each other and the organisers so that everybody had the opportunity to sense check and seek help if need be. We also had a briefing prior to the event, to allow coaches to get to know one another and explore aspects of the common process we designed for the teams. This way, coaches could guide and support, based on their own experiences but also knew what language and tools they could use to create a common understanding of a way forward across different teams.

Experiments never guarantee a particular outcome and we certainly didn’t get everything right with our first iteration of CoJam. But they are bound to create opportunities for reflection and learning, and a foundation from which to run even better experiments in the future. Old thinking suggests that we develop a thing and get it right, then roll it out and reap the rewards. When was the last time that worked for you? Modelling the expectations we have of hackathon participants means approaching any initiative as an experiment, as a starting point of exploration and see where the journey will take us. 

What I am most curious about with this experiment is where the sparks of this weekend have landed, and if they have seeded into little fires among our communities. 

—

CoJam is a joint initiative of community organisations, catalysts, collaborators and participants, spearheaded by Foundation North. Sarah supported the CoJam through event experience curation, facilitation and recruitment of coaches.

Wearing different hats, Sarah works at intersections of people, communities and organisations to co-design change experiments that empower others to imagine and follow new futures. She leads her own human centred design practice and when not found buried under post-it notes and workshop run-sheets, Sarah facilitates learning experiences with New Zealand’s customer advocacy community that help organisations shift focus from profit to people.