challenges and lessons learned

Building a global hackathon from the ground up – The Global Hack organizers’ notes

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 (Accelerate Estonia & Garage48), 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: let’s 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 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 The Global Hack

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 something bigger together. 

And so The Global Hack (TGH) was born, to organize a collective response to the ongoing crisis and build solutions for the new world we would face once the virus’ curve would be flattened. 

Right away, we saw that this event might become massive. The German hackathon alone had 28,361 participants. Our thinking was that we had 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, 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 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 TGH 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; America. 

In the three weeks from inception to end, our initial core team of four people—Kai, Calum, Marko, and myself—quickly grew to include 40 volunteers from many different organizations. Kai was our main boss lady, 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 hackathon flow and tooling. 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 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.

Challenge 1:
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, 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 having to answer the same one repeatedly, and determining how we would perform evaluations. We started with a lot of unknowns.

Challenge 2:
How to facilitate ideation and team formation for a Massive Online 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, 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.

Challenge 3:
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 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 😉

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 fight the firefighting and in making the flow and tooling mission a success.

Challenge 4:
How to get large groups to move quickly online.

The Indian Hack the Crisis with 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 from the participant perspective. 

Challenge 5:
How to be efficient when working with a large number of people.

To make an MOH 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, and have a specialist focused on communication for the hackathon 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.

Know this—people will be blind to announcements and information, even when 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.

Challenge 6:
How to keep things going as planned in a Massive Online 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 use it for. Read: use Vimeo or YouTube for video uploading). 

Manual work or partially-built tools can result in a lot of delays, which aren’t an option in an MOH 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, 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.

Challenge 7:
How to set up mentoring in the context of a Massive Online 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.

Challenge 8:
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 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 to the last minute, so we ended up keeping submissions open after the deadline, too. 

One thing is sure—minimise manual processes and plan for mess-ups as much as possible. Because every process is prone to have a surprise in an MOH.”

Challenge 9:
How to evaluate a large number of final submissions.

We looked at this as a mass filtering problem. We wanted to maximize quality and minimize cheating, so we applied the following layers of filtering. 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 on every project in the team mentor picks, scoring teams based on evaluation criteria (on Guaana). This resulted in a ranked list for a track and helped us get to 15 top teams. 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 to 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 fundamentally broke, and that our processes and tooling survived. I personally had more stress preparing than during the actual hackathon.

We learned plenty, too. Newcomers need training on the very 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 an MOH, you’ll always have to cope with either immature or partial tooling. Apart from this, prepare for things going sideways and breaking down.

This 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 🙂

Happy team looking back at the event 🙂

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.

Published by Priit Salumaa

. Priit is an indispensable idea generator, problem solver and innovation seeker, an entrepreneur, startup activist, and a software engineer. He’s the co-founder of Mooncascade, and behind several other tech community initiatives such as Latitude59, Garage48, Estonian Student Satellite Foundation and MobileMonday Estonia.