Four Keys to Running a Hackathon During a Pandemic

The T-shirt is in the mail

Hackathons are too important to ignore during these crazy times. They are a proven mechanism to improve engineer morale and plant the seed for the occasional product launch or ops tool you later realize you can’t live without.

Completely remote Hackathons can be hugely successful. I have organized them at Big Tech (Amazon) and product companies, and I’ve seen them work in both settings. Engineers still need a break from the daily routine once in a while. The burst of creativity from events like this spill over into the day-to-day routine as well.

Aside from the inability to provide participants with food and beverage, the key elements for success can be readily constructed. Let’s take a look at the key factors.

Key #1: Collaboration now more than ever

These days, it is critical that engineers collaborate. I encourage participants to collaborate on teams rather than working on projects individually. Hackathons provide theperfect opportunity to bounce ideas off of other engineers and learn from them.

Given the short time frames typically involved, the likelihood of creating high-quality outputs grows significantly when you add a second or third person to a team. Because Hackathon projects are often think outside-the-box projects, hearing initial feedback on ideas can be invaluable. On the flipside, you may get resistance from some team members also. Ideally you do some coordination the week prior so that teams can form around common interests and visions.

Three people is a great team size. Once you reach five or more people, coordination can become somewhat of a hindrance and outweigh potential productivity benefits.

Moderate the team size during registration and at the beginning of the event. Be clear in your communications that all individuals are welcome and will be placed on teams if they don’t already have one. This makes for an easy entree for the engineer who works up to the last second on other tasks and hasn’t spent an ounce of thought on the Hackathon. Yet.

The prevalence and ubiquity of video conferencing technologies such as Zoom make collaboration fairly easy. In the last event I organized in December, we used a primary Zoom call at the beginning, middle, and end of the event. Each team then used a breakout room to work together.

The feedback from participants indicated they liked the collaborative nature of the event. One thing to note is that broadcast messages may not go to all breakout rooms unless you’ve set it up correctly. This is why I like to have a schedule with planned times when all teams check back into the primary meeting call.

Key #2: Favor prescription over open-ended events

Intuitively, you may think that open-ended Hackathons give developers the freedom they desire to work on anything they choose. However wild or crazy there idea is, this is their chance to code away, right? True, to a degree.

However, there is a large segment of the engineering population that prefers to be given a direction to go in. Why is this?

Junior engineers may not have enough experience to come up with their own ideas. They may not know what to create or they may be apprehensive that their idea is not “good enough.” You risk losing some participation due to this concern.

Instead, keep the barrier to entry low. Just show up, that’s it. We’ll give you something to work on. It will be fun. Promise.

This also makes judging easier, as entries are aligned on a common theme. It becomes more of an apples-to-apples comparison. Consider that the Golden Globes has four different best motion picture categories. It’s tough to decide which is better: the funniest movie you saw last year or the most compelling drama. It probably depends on what mood you are in that particular day. Likewise for software projects.

Themes don’t have to be micro-managed. They can be infrastructure or process-oriented. For example, a recent theme we used was VSCode extensions to improve your team’s productivity. Each developer works within the confines of their team’s process every day. I bet each of them has ideas on how things can be done better.

A lot of ideas under this umbrella, so it casts a wide net but at the same time provides a framework for participants to work within. Narrow down the infinite potential project space to a more manageable subset. Event time is limited. As valuable as it is, you don’t want ideation to take half the time. Guide participants and help enable them to be successful.

If you do have an open-ended event, consider different categories for awards. Typical categories may include product-related enhancements, operational improvements or tooling, and innovation (i.e. new ideas).

Key #3: Awards and Rewards

Not much changes in the virtual space here. There are two aspects here: recognition and financial incentives. Do not underestimate the power of recognition. Just look at the open source movement. Developers want to be recognized for the cool stuff they build. It’s that simple.

Hackathons in general and awards in particular are a very powerful way to do this. The first Hackathon award I received as an engineer at Amazon was an aluminum sports water bottle with the event logo on it.

No money, just the water bottle. I never drank out of it. It sat on my desk for a while. I was really proud of that award, and the water bottle was a visual recognition of it. This sounds silly as I write it and a bit embarrassing, but its so true. Recognition is a powerful motivator.

If you can tie your theme to measurable results, even better. For example, if the code extension my team writes improves the development process by 30%, you could calculate the theoretical dollar savings to the organization. Which leads me to the financial aspect.

Monetary rewards are still great motivators as well, and they help draw in participants. They don’t have to be large amounts either, just enough to be noticeable. Who doesn’t want a $100 Amazon gift card?

Key #4: Teams submit demo videos

You may have teams working across the globe in different time zones. It may be difficult to schedule everyone at the same time, even if you are in the same time zone. Video submissions come to the rescue here.

Keep the videos short however. I use a strict 5-minute time limit. Okay, I let one go that was 5:02. But your judges will have a lot of them to review, and you don’t want to make their life miserable. For a short duration Hackathon, 5 minutes is plenty of time to demonstrate the value (current and future) of a team’s project.

There are some added benefits here. Engineers improve their communication skills through the process of constructing a video. Many will combine a few slides with a screen cast demo. This is great, its what you want. In today’s work-from-home climate, this is an increasingly valuable skill.

Some folks just don’t like public speaking, and here the video format can be helpful as well. Encourage all team members to take a role in video production, whether it is recording audio or writing the script. Being able to effectively summarize the value of their work will yield benefits down the road for engineers.

Bonus Item #1: Theme Music

Something on which I received a lot of positive feedback but threw in at the last minute was theme music. While teams were working, I played some music on the primary Zoom call and got a ton of compliments on it. You can go to Audio Jungle or other similar sites to find music you like.

I used a few tracks that were bundled together called Future Bass Uplifting Electronic Pack. Highly recommend it.

Bonus Item #2: Try a Speed Hackathon for a change of pace

I organized and led a speed Hackathon for our last event. It was a lot of fun. Using the concept of prescribed themes, we created GitHub projects with specific challenges that could be one-click launched in GitPod development environments. Participants could start developing against the goal in minutes.

There was no constraint on the choice of development language, but I setup the project in Ruby and also provided basic scaffolding in Java. I received positive feedback from participants who were Java developers even though I provided most setup in Ruby. They would normally have used Java, but they said it was so easy to get started with Ruby given the predefined development space, they went ahead and did that. They could literally start being productive a minute into the event.

We gave each team an hour and a half for this event, which is fairly short. For any substantive output, you probably want to consider a 4-hour or 8-hour event. But mixing up the format typically yields interesting results, and we learned a lot about our development tool set and each other in the process.

If your organization hasn’t had a Hackathon since before the pandemic started, consider having one now. It can really help energize your staff and bring people together virtually in a fun and productive environment. And don’t forget the T-shirts.