Hack the Crisis NZ was a response to the COVID-19 situation similar to other weekend hackathon challenges – some 30-or-more countries have run online #hackthecrisis events aiming to help address some of the many health, social and economic challenges posed by the pandemic. The NZ event was a collaborative one, co-organised and supported by Callaghan Innovation, and various innovation networks and businesses around the country. Quite rapidly, a website was built, and challenge themes established: supporting businesses, connecting communities, resilience and wellbeing.
During the week prior to the event idea submissions were made responding to the themes. Ideas were effectively voted on during the team-formation phase, as people attached themselves to proposals, clustering into teams that would work together over the weekend. From some 210 original idea submissions, 55 teams emerged. The total number of participants was just under a thousand, equating close to 900 team participants, over 50 mentors and coaches, and a couple of dozen other support staff. Sufficed to say, this was a large event for its type – an online collaborative ideas competition spread across the breadth of the country.
I volunteered to participate as a team coach. There were about 10 coaches for the event, and each was responsible for overseeing four or five teams over the 48-hour duration. More a manager or facilitator, a coach would regularly check in with teams, identify any problems, suggest strategies and, importantly, find mentors to provide assistance with specific issues.
Compared to my experience with other jam-style events, the lack of face-to-face contact presented immediate communications challenges. Co-location is often an integral aspect of such events (Briscoe et al 2015): it provides an immediacy for communication, knowledge transfer and trust building, as well as socialising. And, for those helping to supervise, co-location allows for an easier interface with groups.
Under COVID conditions, however, and with social distancing in place, organisers employed a suite of online services to facilitative communications, workflow and knowledge sharing. Key tools were Slack, a collaborative communications platform; Zoom, an online videochat application; Crowdcast, a livestreamming platform; Google Docs; and Guaana, an organising platform developed specifically for hackathons and online challenges. And, while participants largely managed to make things work, this was by no means a smooth process.
To the credit of the organisers, they had sought advice from those who had run Crisis events in other countries. They had devised a clear structure for the event, breaking up the 48-hours with informational meetings, short talks, and space for discussion (following the format of a typical multi-day hack or jam event). However, as is often the way with relying on technology, sometimes it works ok, and sometimes it doesn’t. The virtual nature of the event made it an experience full of delays, lags and drop outs. Crowdcast streams, when they worked were great, but when they didn’t created awkward pauses, uncertain transitions, and ‘dead air’. Perhaps the most messy livestream was, unfortunately, the culminating one in which organisers had arranged for judges to ask questions of team finalists. It may well have been that early-evening bandwidth was thin, but the result was a glitch-filled session punctuated by lags, screen freezes and awkward silences.
From a coaching point of view the distanced experience was challenging. The task of interfacing and building rapport with unseen groups of people who, in all honesty probably just wanted to get on and focus on the task, was difficult. On one hand I was able to monitor the messaging activity in Slack as an indicator for how well the group was working. However, such a strategy relied on the group actually using the platform – at least one of my groups appeared not to find Slack useful, avoiding it for general discussion. Similarly, bi-hourly ‘check-ins’ via Slack messages were largely ignored by teams, and there was little I could do to get a direct response on progress.
Despite the aforementioned technical challenges and glitches, the event proceeded relatively smoothly. Friday evening’s introductory and kick-off session was followed by further instructional and advisory sessions on Saturday morning. Sunday morning’s livestream session provided final advice and inspiration for teams as the mid-afternoon deadline approached. Unfortunately, technical issues vexed the project assessment and judging process. As the submission deadline passed teams sent out fraught messages detailing critical problems with uploading videos – lags and crashes – that meant that some final presentations missed the cut-off deadline.
However, it was situations like these that revealed the generous and innovative nature of the event as organisers and mentors trouble-shot problems and devised work-arounds. The event embodied a ‘hack’ ethos, being very much an activity following a sketched-out structure but requiring ongoing trouble-shooting, innovation, and adjustment. Fuelling this was a sense of purpose and generosity – reminding me of ideas encompassed within the framework of ‘geographies of generosity’ (see Barnett and Land 2007). We humans are want to care about others – even those we may not personally know or have met; an act that is strengthened in times of duress, as evident in disaster or crisis situations where those affected respond charitably to shared adversity (see Clark 2007; Solnit 2010).
The hackathon itself was an emergent response to shared adversity – as were the 30-or-so other crisis-response events run in other countries; alongside countless other activities and projects sparked by urgent need (whether for simple face masks or, more critically, medical ventilators). Throughout the NZ event an atmosphere of generosity and enthusiasm pervaded. This was evident not just in the generosity of time and resources volunteered to organise the event but across the span of the weekend, reflected in the enthusiasm of the support mentors. Visible through the Slack channels was a willingness to turn up when needed and respond to calls of help of all sorts: from organisers, coaches and other mentors, and from the challenge teams themselves. At the start of a mentoring shift (nominally a 3- to 4-hour period), mentors would announce their arrival, look for mentor buddies to work with, respond to calls and, often, report back on progress with some of the teams. Overall, the online chat was permeated by a can-do attitude and a clear eagerness to help.
Progress of the teams was difficult to gauge from a distance, and because of the aforementioned lack of response. While each team is different, with its own dynamics, I noted a lack of mentor engagement within my own teams. Of the four, only two of them called in mentors to help with their projects. One team – quite a large one of about ten – encountered some internal issues amongst its members at about halfway through the weekend, however, after some dialogue it was back up and running again.
At the end of the weekend – and despite the final upload technical problems – 47 of the 55 starting teams presented pitch ideas – a reasonable completion ratio. Initial project assessment was a swift affair – given the short timeframe – with mentors allocated four or five project submissions to grade. The top eight entries would move into the final judging round.
Within my allocated assessment projects there were common underdeveloped elements, such as clarity with the proposal’s unique benefits, convincing research or validation, and clear and succinct pitch presentations. Other aspects, however, appeared well attended to: structural systems design, working technical prototypes, and potential funding strategies. It seemed that time and effort had been focused more on structural and technical features, and less on support for and packaging of the idea. Such results highlight the need to carefully balance and budget time spent across the 48-hour time frame, allowing for each aspect of project development to be attended to – undoubtedly easier to admonish than enact.
Some teams managed to find such balance. The top-rated projects showed clarity in concept, and communicated it clearly. The eventual winner, ‘Draw This’, proposed an online platform that would connect young and old through collaborative storytelling. Relatively simple as far as technology was involved – no AI, for example, rather a basic online matching service – it’s pitch was clear and compelling. Other top contenders had also developed clear and relatively simple proposals: ‘Peer Postie’, a localised peer-to-peer delivery service; ‘Power Move’, a platform to assist those facing power poverty; ‘Wanderble-Riposte’, a personal mindfulness support app.
Yet, while project outcomes across the event showed a range of interesting ideas, a I had niggling questions as to how effectively these would respond to the NZ COVID situation, as well their sustainability over the longer-term. It is not the first time such thoughts have arisen. Having been involved in a number of similar collaborative events, a couple of which have focused on environmental sustainability, I have been left with questions of just how effectively responding ideas and devised ‘solutions’ attend to the inherently complex nature of the issues they attempt to address.
The nature of a hack or jam event is short and sharp – by all means an effective way to stimulate ideas, responses, and develop working outcomes. Rooted in software development, the strategy of throwing a couple of coders in a room for a weekend with pizza and caffeinated beverages and locking the door is surprisingly effective. However, this works best when the task is clearly defined. Even though software is inherently complex, it is possible to focus on a particular component feature or technical aspect and discretely address that problem.
There is also a notable difference between hack and jam events in relation to the design thinking process. Jams focus more on the middle of the process, that is, definition of the problem, creation of ideas, and prototype development. Hacks include some aspects of definition and ideation, but are more concerned with prototyping and testing. Indeed, the push for the CrisisNZ hack was to have a working prototype of the product/service by the end of the weekend; more astute teams had even signed up customers and secured funding for their product.
The skill set of the mentor cohort volunteering for the weekend also displayed a particular bias. People were asked to identify their expertise so this information could be used to match skills to team requirements as needed. A large proportion of mentors had business and startup expertise, as well as applied technical skills such as coding and development. These were useful people to have for practical product and service development: market strategising, as well as technical prototyping purposes. However, missing was a diversity of expertise that could be drawn on for the front-end of the design-thinking process – empathising and problem definition. It would have been great to have input from across disciplines – psychology, social sciences, economics, education, philosophy, and more.
Given current interest in collaborative methods for creative process and social engagement, there is growing literature focusing on hack and jam events. Some of this is simply descriptive, documenting either events themselves or detailing methods and tools for producing an event. But, other more critical studies focus on broader issues of methodology and impact. Aside from social or public engagement, hack and jam events are also viewed as a useful pedagogical tool, a way to expose students across disciplines to the design thinking process (see for example Page et al 2016, Snow et al 2019). As an educator myself, I can see the value that such an immersive experience can bring to learning – not just for students but all involved. The jam events I have been involved with allowed a diversity of people to participate, exposing people from business and local government – as well as students – to design thinking and innovation processes.
However, there is a shortcoming with hacking and jamming methodologies similar to something I have noticed more broadly within designing professions, where the design method is seen as a cureall for all problems and projects. There is an adage about design that suggests to be a designer is to be an optimist. Designers, it is argued, dream of a future not yet made, and apply themselves to mobilising that future – seeing a pathway of opportunities where problems can be solved (see, for example, Kolko 2013). Underlying this thinking sits a kind of hubris shaped by modernist logic: faith in human capacity to deconstruct the world and piece it back together in more ordered and productive ways. The debate around this – how we humans go about problem solving and refashioning the world – is part of a much larger philosophical debate about how we understand the world and humans in relation to it; humans, and human activity. Systems thinking, and ideas of complexity, interdependence and entanglement complicate the idea that problems can be isolated, dissected and innovatively realigned. A problem-solution at a small scale can, in fact, turn out to be a larger-scale problem. We all know this now: the production of the cheap, plastic biro, for example, solves the problem of an affordable, mass-produced writing implement, but creates another problem of material waste and ecological contamination. Such design solutionism is mirrored by a technological solutionism: a belief that throwing technology at a problem will provide an effective solution. Of course, it won’t necessarily.
A critical perspective is useful, especially where broad claims are made. In relation to hack and jam approaches to addressing wider social issues, what looks to be more effective is employing such methods in a more considered manner. A one- or two-day event can still be an effective way to resolve a discrete issue. But for complex issues, a more considered and longer-term process allows for multiple stages to be run. Broken down, this includes critical initial stages of problem understanding and definition and, importantly, engagement with audiences and publics – given that any good solution will seek to attend the needs of those it aims to serve. Subsequent design-thinking process then serves to open up potentials for different approaches for appropriate solution pathways. A hacking stage then follows, bringing in potential use of technologies which may help support the refined idea (see To 2016). Throughout all stages, diversity of input is important to both broaden and deepen thinking. Reducing barriers to participation is important, inviting people across gender, age and culture to input into the process. And, perhaps more radically under a planetary systems lens, it is appropriate to invite more-than-human contributions into the problem-solving process (Coulton and Lindley 2019).
At the end of the day, the outcomes of Hack the Crisis NZ were not critical. The situation in NZ has been well contained, and health and support services were not pushed to critical limits as they were in other countries. Indeed, Hack the Crisis events in other locations included a focus on more immediate needs such as the supply of personal protective equipment, increased space demands for treatment, communication of information, public resource supply, and the like. However, for the other longer-term impacts, while it may be potentially useful to have a pool of fresh and novel ideas, at the same time we can assume that exisiting organisations, service providers and governance agencies across sectors will be developing strategies as the peak crisis situation moves in to its chronic phase. Here, I’m thinking about things like mental health, safe access to resources – especially for vulnerable citizens, financial stresses, broader economic development, and the like. Responding to such issues requires an understanding of system complexities, national resourcing, and ongoing management and adjustment.
My ultimate ‘take away’ from involvement with Hack the Crisis NZ supports ideas I explored under the framework of ‘Anthropocene dwelling’ developed in my doctoral research. There I argued that, for humans, living on a planet under conditions of ongoing flux and instability calls for a wider openness to both personal and cultural unsettlement, as well as an openness to experimentation. By this I mean a receptivity and adaptability to new and novel strategies for – very broadly – doing things at all scales – personal, organisational, social. Hack the Crisis NZ was, ultimately, an experiment. It adapted an innovation framework to a novel situation, bootstrapping together what was necessary to foster outcomes. The project outcomes may or may not lead to tangible solutions, but more broadly the activity was productive in many other ways: helping to build relationships and community; proving that an event like this can work virtually; and providing a rich learning experience for those participating.
References
Coulton, P. and Lindley, J.G., 2019. More-Than Human Centred Design: Considering Other Things. The Design Journal, 22(4): 463–481.
Kolko, J. 2013. The optimism of design, Interactions XX.4
Page, F., Sweeny, S., Bruce, F. and Baxter, S. 2016. The use of the “hackathon” in design education: An opportunistic exploration. International Conference on Engineering and Product Design Education, 8–9 September 2016, Aalborg University, Denmark.
Snow, S., Filipczuk, D., Viller, S. and Gomer, R. 2019. Design Jam as a Pedagogy: Teaching Design Thinking to Computer Science Students at Scale. 31st Australian Conference on Human-Computer-Interaction (OZCHI’19), December 2–5, 2019, Fremantle, WA, Australia. https://doi.org/10.1145/ 3369457.3369468
Barnett, C. and Land, D. 2007. Geographies of generosity: beyond the 'moral turn’. Geoforum 38(6) 1065–075.
Clark, N. 2007. Living through the tsunami: Vulnerability and generosity on a volatile earth. Geoforum 38: 1127–1139.
Solnit, R., 2010. A paradise built in hell: The extraordinary communities that arise in disaster. Penguin.
Briscoe, G., Virani, T. and Dima, M. 2015. Hackathons: Why Co-location? Creativeworks London Working Paper No.11, Creativeworks London.