Jan 13, 2021Team culture15 min read

Why your next virtual team gathering should be a Hackathon

The importance of team gatherings

Most veteran remote companies (those who were remote before the pandemic), know the importance of having in-person team gatherings. At SafetyWing, we feel this deeply. We used to have 4 of them a year, scattered around the globe. Our past few were in San Francisco, Mexico and Norway. Our next one was (and is) planned to be in Ljubljana, Slovenia.

This was one of our company's biggest disruptions during the pandemic. We may be pros when it comes to working remotely, but 6 months after our last in-person gathering, we were craving some connection. Unfortunately, it quickly became clear that flying the entire team across the world to meet in one place would be the last component of our "normal" life to return. Another solution was needed.

Our first attempt at a virtual gathering

In August of 2020, we attempted to hold our first virtual team gathering. This was a moderate success. We enjoyed talking and joking with each other like we did at physical gatherings. There were some games and activities like "bring a snack from your country" that were quite fun, but it certainly wasn't the same as our normal team retreats. The problem hadn't really been solved.

At this point, we decided to take our own advice from one of our recent podcast episodes on Building Remotely: don't try to replicate the physical environment virtually. This never works when going remote. So, we decided to build our ideal virtual gathering from scratch.

The hackathon solution

We wanted to fix some problems we had with our first attempt:

Too much time was spent on video chat, creating Zoom fatigue
It took quite a bit of work time out, but still added scheduling stress
At the end of this time, we didn't have any tangible outcome of the time spent
Creating "fun" activities for everyone's preferences was tricky.

The solution, we decided, was to have a virtual hackathon.

What is a hackathon?

The term is pretty broad, but comes from the tech world. Traditionally, a group of developers will unite to tackle a unique problem. Naturally, it doesn't have to be specific to developers. The hackathon concept has evolved into any group of people getting together to focus on solving a specific problem in a short amount of time. Usually, this involves building something.

We decided to center our second team gathering around a hackathon.

Why is this a good solution?

There are quite a few reasons why hosting a hackathon is the perfect solution to create a rich virtual gathering experience. Most are synonymous with those of hosting a team gathering in general, which was a great early indicator it would work.

It fosters productive bonding

Icebreakers and games are great (for some...), but they don't necessarily create co-worker bonding. In fact, if awkward and uncomfortable, they can have the opposite effect. But when you are collaborating on something fundamentally important and exciting, it's difficult not to bond. Particularly when all parties are invested in the outcome.

You work with new team members

This is one you'll need to put a little effort into making happen, but it's well worth it. If possible, structure each group as a new miniature team, not an existing department. Pair up marketers and developers who might not usually work together.

End up with something new that otherwise wouldn't exist

What cool idea has your company been bouncing around for months (or years), but is never a high enough priority? Working together is a lot more fun when you have something to show for it at the end. The company gets the fun of having a shiny new thing, but also the pride of having created it.

What makes a good hackathon project?

Mission focused Don't make an internal dashboard. Don't make a new marketing campaign. Don't even add a new feature to the website. Choose something bordering on the abstract. Make something that will truly be meaningful to the whole team. The best way to do that is to make something centered around your long-term mission. A good way to think about it: What is an MVP you could launch that directly ties to your mission?
Hard to achieve (but still possible) Most people are fully aware that the most satisfying accomplishments are hard to achieve. The same remains true here. If you build something anyone can or could, it just won't be motivating. Still, make sure it's possible. If you do something that the team doesn’t believe can be accomplished in the allotted time period, they won't push to accomplish it.
Something not on the roadmap This is an important one. It will be tempting to make something that keeps getting bumped on the product roadmap. Resist the urge! If it's something you have already planned to build, it's just going to feel like normal work (but accelerated). This is the easiest way to ruin your hackathon.
Something the whole team will feel proud of The good news is that if you've succeeded in #1, you'll nearly by default succeed in this point. After all, if your whole team isn’t completely bought in on the mission, you have bigger problems than hosting a successful team gathering. Still, it's worth considering this point directly not only when choosing the project, but also designing it. Another good way to make sure the project has a "pride" component is to make it public. Something that, if you succeed, can be launched to the world. Finally, make sure you discuss with your team the theme of the project. Brainstorm together, and then vote! This will start things off with energy from the beginning, but also ensure everyone has skin in the game right off the bat.
Make it useful and with longevity Have you ever built something that falls by the wayside directly after its completion? If you've done much building, the answer is almost certainly yes. It's a terrible feeling you don't want to put on your team. The best way to do this would be to add a "next steps" plan into the project itself. Have one of the groups make a plan for what the post-launch actions will be.

Some example of GOOD hackathon projects:

An MVP new product launch
Build a new community
Create a tool for your existing community
Conduct research and produce a publication to answer a question you currently can't
Launch a new app.

Some examples of BAD hackathon projects:

Rebranding the website
Boosting your analytics
Setting up ads on a new platform
Fix all the existing bugs in your product
A slideshow or spreadsheet as the final project.*

(*There might be exceptions here, a spreadsheet can become something truly spectacular....)

In summary, the good litmus test is: are you and the team excited about what you'll be doing?

Costumes never hurt - our theme was "The survivor"!

How to structure your hackathon

There is, of course, no one single best way to do this. Hackathons are by nature creative, and the ideation process should be as well. Still, we learned some things during ours that helped add a sense of organization to an inherently chaotic process.

Choose a time frame

To discover how long your hackathon should be, there are variables you'll need to address, depending on your team.

Are you in the same time zone?

If so, you might be able to do the entire thing in one day! If not, this will be almost impossible. Don't require your team to lose sleep over this. It should be tiring in a cognitively satisfying way, not a physically exhaustive way.

How big is your team?

If you have several dozen people taking part, you'll need a bit more time for coordination and pass-off. If each team is only a few people, it's much faster.

How complex is the project?

You'll have to be honest with yourselves here. How many days will it realistically take to complete? How many separate components are there? Do you want to devote a whole day to the launch? Make sure there is enough time to complete the project in a hackathon-style rush.

Choosing the teams

There are three major considerations when selecting the teams:

Pairing groups who normally don't work together
Choosing the right number of teams
Choosing the right number of people on each team

#1 is debatably the most important. One of the goals, after all, is to get people working together who otherwise wouldn't. This means you'll have to make conscious decisions to deliberately ensure there are new team interactions.

#2 will depend largely on the number of days you have chosen for your hackathon. A good rule of thumb is to have one team per day, although it may be possible to have several stages of the project done in a single day.

#3 is more universal, but larger in variance. You, of course, don't want a single person working on a component, but you also don't want so many people that not everyone gets to play a key role.

Schedule on/off days for each team

This is a little bit non-obvious. It came about for our team when the hackathon was first pitched. As with most startups in 2020 we've all been pulling long days attempting to make the impossible happen. Our team pointed out that if we were going to pause our normal work for a week, maybe it would be better to take time off.

This is a valid point. There is a very real risk that introducing a hackathon could trigger burnout on a stretched team. Keep in mind, most teams are stretched. This would of course have the opposite effect than was intended for the hackathon gathering.

Fortunately, there is an easy solution: schedule some days on, and some days off for each team. If you are worried your team is already approaching burnout, you might make 2 of the days mandatory days off. If not, you might let the team choose whether they want them to be off days or free workdays.

Along with the benefit of making it less stressful, this also ensures they will show up to the hackathon fresh and excited. Remember that this should be something the team is looking forward to.

Have a big incentive

Speaking of making it something everyone looks forward to, we recommend adding an extra little bonus. Something that the whole team gets if you accomplish the task. This could be large gift cards, a prize to upgrade their remote work setup, or (if you don't provide unlimited vacation time, which you should) mandatory extra days off.

One note, did you notice I said BIG? This is key. Don't give your team a $50 Chipotle gift card. That's not the kind of thing that motivates a whole team. Ideally, you give everyone something worth a thousand dollars. If you are bootstrapping, that's understandable, but try and shoot for a few hundred dollars at least. Keep in mind, you're replacing a physical gathering with this, so use some budget. Maybe your project will even create some revenue.

Get external help

If you've chosen a really good hackathon project, you'll be making something that you've never made before. That can be daunting. Rest assured, it's okay to ask for help. Finding help isn't actually that hard. Just think of who has built something related to your project successfully. Reach out, ask if you can pay them for some consulting hours.

If possible, it's great to meet with them both before and during the project. Before, you can have them involved with outlining the plan and giving some structure for the week. If they're up for it, it's nice to have them pop in quickly and check with each team to give advice.

How SafetyWing did our hackathon

A pic from our previous team gathering in the SafetyWing house, in SF!

How we structured it

We had around ~15 people from our core team take part. We attempted to make 3 groups of 5 people (although there was some variance here because of time zones). We divided into: 1. Systems/Product, 2. Design & Dev 3. Founding chapter

This structure meant that over the 3-day course of the hackathon, we would each have 1 solid day of hacking, and 2 free days. Monday and Friday were for more fun team activities. If you are interested in having this as a component of your gathering, reach out to Sam Laliberte who did ours.

The founders decided that if we completed the task successfully, we would each receive $1,000 to spend on upgrading our remote work setup. Could be new monitors, a new desk, special lighting, a nicer webcam... whatever. I can attest that this was a SUPER exciting incentive. It was never a matter of if we completed it or not. We were all determined to.

We've learned from our previous team gathering, took into account the natural dynamics of our team, and found a way for everyone to participate and have fun. The end product was probably one of the highlights of the year - we're excited to share it with the world soon.

About the author

Sam Claassen

Head of Growth

SafetyWing

Sam Claassen is the Head of Growth at SafetyWing and a serial advocate for remote work. A longtime nomad himself, he has been to 65 countries while doing growth and remote work consulting for startups and accelerators. Through his work at SafetyWing, he is working with a team to create BuildingRemotely.com – a podcast, online resource and soon to be book on building a thriving remote company.