I was looking down the empty toilet paper aisle in my local supermarket at 10am when I received two consecutive phone calls from my friends Calum and Kai (From Accelerate Estonia & Garage48 respectively), asking if I was particularly busy that evening and whether I had any time to spare in the days to come. It was Friday, March 13th, and Estonia had just declared a state of emergency.
The idea was simple: to do something about the corona virus crisis. Let’s empower people and give them the means to do something about this situation. Before I knew it, we were kicking off the very first Hack the Crisis hackathon, with over 1,000 people in attendance and 30 teams eager to build innovative solutions for the crisis, without ever meeting face-to-face.
Our approach caught on. Within a week, twelve other digital hackathons had been started, and we were already planning to leverage their momentum and put together a global hackathon to fight the corona virus crisis as it happened, and build resilience for post-pandemic life. We called it The Global Hack.
From analog to fully digital in 6 hours
As part of the founding team behind Garage48, I had been organizing, acting as a mentor, and taking part in hackathons for ten years prior to all of this. But the hackathon on March 13th was our first experience working entirely online. We found ourselves in uncharted waters, but luckily this taught us quite a few things.
The first lesson we learned is this: although digital channels are almost limitless and enable unprecedented growth, they can quickly get very messy.
In-person hackathons usually bring together 60 to 200 participants in a physical venue with a big hall that can fit everyone in one place. For Hack the Crisis, we chose Slack as our main communication tool and de facto venue. The choice came naturally, as we had been using Slack professionally for years. Getting others to take part was as simple as a single click: “Join our Slack.”
And boom! There it went. We had 600 participants in less than six hours, with a total of over 1,400 joining over the course of the event. I believe that this result was produced by a combination of two key factors: no-friction signup paired with a powerful message.
From regional hackathons to a global hackathon
As Hack the Crisis came to a close, we were in awe of the amazing efforts made by local organizations to put together their respective initiatives, with a total of 62 produced to date. We saw just how powerfully the corona virus crisis had united people and driven them to act. Inspired by this success, we decided to take things a step further and join forces with these regional hackathons to build a global hackathon together.
And so The Global Hack (TGH) was born – a global hackathon designed to organize a collective response to the ongoing crisis, and build solutions for the new world we would face once the virus’ curve had flattened out.
Right away, we saw that this event might become massive. The German hackathon alone had 28,361 participants. Our thinking was that with a global hackathon we’d have to prepare for a large, unpredictable number of users, so we built our tooling to be able to survive between 20,000 and 200,000 participants.
Apart from the scale of the event – a ‘global hackathon’ isn’t going to be a small affair, after all – I had two main concerns. How do we organize a Massive Online Hackathon (MOH) to run simultaneously with a range of different languages, cultures, and time zones across the globe? And how do we do this while maintaining the level of quality expected in an in-person hackathon with hands-on mentoring?
Maintaining high quality and putting just enough mentoring pressure on teams have been some of the key things that set Garage48 apart from other similar events out there. Not only does this approach result in better functional prototypes, it also leads to a higher number of solutions surviving after the hack ends.
Our solution to these two issues was to split our global hackathon into a number of themed tracks. Each one functioned as a separate hackathon running parallel to others in three major time zone slices across the globe: Asia and Australia; Europe, the Middle East and Africa (EMEA); and finally America / the Americas.
In the three weeks from inception to the end of the global hackathon, our initial core team of four people—Kai, Calum, Marko, and myself—quickly grew to include 40 volunteers from many different organizations. Kai was the one to take charge, dividing the organization into different workgroups, internally called “missions,” that helped each of us focus on the tasks we were responsible for.
Processes and tooling—9 challenges we faced
I took on the mission of organizing flow and tooling for the global hackathon. I loved doing it and learned plenty, so I won’t cover the heroic achievements of the 12 other missions we had to carry out, which included Calum and his team fundraising for the prize money, Marko securing the inspirational leads and an Erykah Badu concert, Elis and her team getting us on CNN, and Anniken’s team handling web and social media channels, among many others. Each of these missions deserves an entire blog post of its own.
To organize the global hackathon’s basic sequence of events (or ‘flow’), we used a simple spreadsheet listing the hackathon’s various stages, the activities set to happen in each stage, the parties responsible, and the tools available. This document was iterated countless times and grew progressively more complex as we moved forward. Here are some of the challenges we faced along the way, and what we learned from them.
How to scale an event with X people to one with potentially Z hundred thousand people.
Not only did we have to try and predict an unpredictable number of people in attendance at a global hackathon like TGH, we also had to figure out how many mentors we would need and how mentoring would take place on a global scale. This meant determining processes for answering questions (including minimizing the number of repeat questions), and determining how we would perform evaluations. Indeed, we started the journey towards a global hackathon with a lot of unknowns.
How to facilitate ideation and team formation for a global hackathon.
Our aim was to have participants forming cross-functional teams around their ideas, to allow them to build real, functioning prototypes within 48 hours. Though we tried to facilitate this process by creating #discussing_ideas and #teamformation channels on Slack for the first Hack the Crisis hackathon, when upscaled to a global hackathon these quickly turned into endless message and repost link walls nobody could follow.
For TGH, our initial approach to participant onboarding and team formation was to have them pass through Reddit, because Guaana couldn’t facilitate this process and we wanted to avoid a wall of noise and endless links on Slack. The problem is that Reddit is complicated for newcomers who aren’t used to channel logic, flagging, how to comment, etc. So we pivoted and went back to Slack, using an updated channel structure in combination with Devpost. Even this wasn’t ideal, but it worked as long as we gave users heavy Guidelines.
How to keep noise levels to a minimum and focus on work.
To further minimize noise on Slack, we created separate workspaces corresponding to the tracks we had organized the global hackathon around. This allowed us to break down what needed to be done into parallel structures, and guide participants and mentors to the places they needed to contribute to. To connect these workspaces we used an experimental Slack feature: multi-org shared channels (as a pilot), which caused hiccups as the feature wasn’t quite mature enough to deliver what we needed.
Interlude: A personal lesson: if you’re so busy firefighting that you don’t even have the time to make a To-Do List, it’s time to recruit help. Maret Kruve and Kristo Mägi were invaluable in helping me control the firefighting and in making the flow and tooling mission a success.
How to get large groups to move quickly online.
The Indian Hack the Crisis which involved 295 teams, noted that large groups move across digital environments much more slowly than they do in the real world. It took 24 hours for their participants to get settled in the right channels and ready to go.
In a way, this is obvious: people can’t always see where they have to go online. Schedules, maps, room numbers, signage, and crowd movement all help participants get around easily when moving through a physical space. As a newcomer, you often just go with the flow. When you’re the last person standing in a room, that’s a clear sign you should get moving. In a digital environment, everyone is always kind of still there even when the chatter has died down.
The trick to getting people moving online is to start moving them early—prepare for that, and make sure you think through the communication channels and flow for an event like a global hackathon from the participant’s perspective.
How to be efficient when working with a large number of people.
To make a global hackathon work, you have to be transparent and over-communicate. This means maintaining internal communication with stakeholders (participants, mentors, track holders, organizers) but also external communication like PR and social media. It helps to have an entire system to facilitate this process across digital channels. Create guidelines and FAQs, enlist the help of moderators to have direct human support at your global hackathon, and have a specialist focused on communication for the flow and tooling. Our team went from a process and tooling team to a communication team during the actual hackathon, working alongside moderators and others on comms.
Understand and accept this though—people will be blind to announcements and information, even when they’re right in front of their eyes. People will be new to basics like knowing what a hackathon is or how to use Slack. Be ready to teach these basics, and be ready to repeat.
How to keep things going as planned during a global hackathon.
Use mature tools, ideally specialized in solving problems for your use case. Any system can break under a heavy load (especially if it’s not meant for the tasks you’re using it for).
Manual work or partially-built tools can result in a lot of delays, which aren’t an option in a global hackathon with open communication. Mere minutes of downtime or sluggish UI in the face of deadlines can generate hundreds of angry direct messages and plenty of bad will from participants.
Remember: when you’re dealing with tens of thousands of people (as you may well be at a global hackathon like TGH), contacting customer service to solve your problems won’t be fast enough. We had to get in touch with HQs at Slack, Zoom, Devpost, and Guaana, to make sure our needs were being met quickly, efficiently, and on a large enough scale.
How to set up mentoring in the context of a global hackathon.
We used Google Forms to register mentors and split them into three roles: response mentors (to help deal with problems); team mentors (responsible for one-on-one mentoring, video check-ins, and team communication); and lead mentors, who managed a given track across time zones. (Our minimum number of team mentors = total Participants / 100). The main issue here was that all sorts of people signed up, which meant that mentoring quality varied. Next time we’d like to create a better way of validating mentors.
The role split worked nicely, though. Tracks having enough flexibility to structure specific mentor help and team mentor batches with Slack channels helped keep the levels of white noise chatter down.
How to avoid issues in the final submission process.
When Guaana went down 30 minutes before the submission deadline came around (and seconds after we made an @channel announcement to thousands of people), the lesson learned was that any system involved in a global hackathon can be overloaded. (Luckily the downtime lasted just for 2 minutes.)
To prepare for this, I suggest opening submissions twelve hours earlier. We may have done that but, as you can guess, no one listened to our advice not to leave submissions until the last minute, so we ended up keeping submissions open after the deadline, too.
One thing is for sure—you need to minimise manual processes and plan for mess-ups as much as possible. When you’re running a global hackathon, you need to expect the unexpected from your systems.
How to evaluate a large number of final submissions.
We looked at this as a mass filtering problem. At TGH we wanted to maximize quality and minimize cheating, so we applied the following layers of filtering at our global hackathon. First, for quality, we had team mentors choose their personal top 30%. They knew their teams, having worked with them for the full 48 hours. Second, for objectivity, we had randomized sets of three to five pairs of eyes look at every project that made a mentor’s top 30%, scoring teams based on evaluation criteria (on Guaana). This resulted in a ranked list for a track and helped us identify the top 15 teams across the whole of our global hackathon. Then, a track jury chose a top three for their track, and a grand jury chose a top three from all tracks combined.
We prepared the process with stakeholders and managed to squeeze it into roughly 5 hours. The only problem here was that evaluations took longer than planned, delaying the final by an hour. The lesson: make sure your risks are properly perceived and mitigated, especially concerning manual work.
The Global Hack had a total of 12K+ participants, with 1,032 ideas presented and 507 projects built (making it to final submissions).
It was great to see that we had prepared well enough that nothing fundamental broke during this global hackathon, and that our processes and tooling survived. I personally felt more stress preparing than during the actual hackathon.
We learned plenty, too. Newcomers need training on the absolute basics. Large groups of people still move slowly and better tooling is needed for digital environments. There really are no “perfect” tools for massive online hackathons. The use case is just too new to the world. When organizing a global hackathon, you’ll always have to cope with either immature or partial tooling. Apart from this, just prepare as best you can for things going wrong and breaking down.
This global hackathon was an amazing amount of adrenaline and fun for just 3 weeks. I’d do it again, any day! We’d need twice the time for preparation, but the entire process would also be twice as easy thanks to the experience gained this time around.
Want to stay competitive in the post-crisis world?
With billions of people and millions of businesses affected by the crisis, the only way for businesses to survive is to go digital – you need to tap into hidden opportunities, make smart decisions and get to the market fast. Mooncascade can help you with that.
Discover the right opportunities for your business with our contactless workshops tailored to companies working remotely world-wide.