How to hack the hackathon

The other week, I wrote about how hackathons can be a great strategy to achieve your developer goals, as long as you carefully consider why you are hosting one. You’ve  and are ready to get started. The next step is typically logistics and planning.  If this is your first hackathon, you may want to engage with the team at The Dev Rel Collective to help, or utilize one of the many online platforms to host your events. More than likely, it will be a combination of the both, with some internal team support.

Thankfully, there is a lot of online resources on . Instead of rehashing these here, I wanted to share a few tips I have learned after planning and running dozens of hackathons.  You can think of these tips as a way to hack your hackathon for success far beyond the typical measures you might think of. Let’s jump in:

Secure an executive sponsor

If you are running an internal hackathon, it is very important to have an executive sponsor, ideally the CTO. The goal of this sponsor is to provide the resources, post hackathon, to see that the winning solution can be moved into production. Too often, a great idea that arises from a hackathon, whether it is internal or external,  is shelved post event. The best hackathon winners offer a great solution but limited implementation due to the time constraints of the event. You should think of hackathon solutions as a prototype or proof of concept, rather than a fully polished offering. The most success hackathons have a plan to turn that rough concept into something usable.  If your executive sponsor can provide engineering resources to make the solution production ready the benefits of the hackathon will continue to pay dividends long after the event.

Prizes shouldn’t just be monetary

Similar to the executive sponsorship item above, try and ensure that any prizes are be more than just monetary items such cash or goods. Because innovation is one of the major benefits of a hackathon, monetary based prizes limit the likelihood that a great idea will one day make it into production. Why not offer services such as marketing, UX design, legal, compute credits, work space, prioritized access to product teams or beta features etc. that teams would need to take their idea from concept to reality.  A simple way to think of this is that monetary prizes are hand outs, and anything that makes it more likely to launch a product is a hand up. Whenever your hackathon goals are broad enough, always try to prioritize hand ups. I’ve used this strategy very successfully in both internal and external hackathons.

Measure the impact

It’s too easy to fall into the trap of looking at hackathon success as the number of participants, or perhaps the marketing coverage around it. Long term impact of hackathons can be much more meaningful. Start by  directly measuring short term indicators: Did it increase signups, or API calls? Did product get valuable feedback around a new feature etc?  But don’t stop there. The best hackathons are ones that use analytics to measure the impact of these indicators. Recently, I’ve been looking at  as a great tool and methodology to not only track quantitative results such as api calls, but also qualitative ones such as time to first call, time to live, new feature ideas generated and more. The notion that you can track an idea from a hackathon all the way into production, and subsequent revenue, is an incredibly powerful way of measuring the true impact of a hackathon. I’ve recently been experimenting with Doubleloop to track the long term effectiveness of hackathons. So far the results are quite promising.

Emphasis the creation of mixed teams

Especially important in internal hackathons, hackathons provide an opportunity for participants to work across traditional departmental boundaries. Create rules that teams should be as inclusive as possible:  a mix of engineers, age, marketers, sales people, HR, men, women etc. It’s too easy to fall into our comfort zone of just working with the people we know. By pulling different perspectives into a team, not only will the solution be more well thought out, the execution of the team will benefit greatly. There is significant research to support the fact that diverse teams are more effective, yet too often I have seen a great idea never make it to the finish line because a team of developers didn’t manage time efficiently. Or, a potentially winning idea failed to even take off because no-one on the team had the appropriate skills to pull off a compelling pitch presentation. External hackathons are often plagued with the same issues. The more varied the backgrounds and skillsets of the team, the more likely the solution will make it across the finish line.

Show some developer love

Developers love recognition for their work, especially if it comes from a company they admire. If a bug is uncovered ,or fixed,  as a result of hackathon participant, why not have the CTO send them email and some swag to say thanks. Or maybe the CEO tweets the individual to mention they were the inspiration for a new product feature, give all participants early access to the next release, or a thousand other small gestures that show hackathon participants that the company recognizes their hard work. A little recognition goes a very long way in building developer love.

Use product teams to support the hackathon

I cannot tell you how many times I have participated in hackathons where my team, or other teams, get stuck on an API call not working as documented. We search around for someone from the product team to help us, but are met with blank stares. Don’t let this happen to you! Make sure that the developers and product owners who worked on the features being used are signed up as support staff, especially late night and early morning. This is the time that the real coding gets done and patience is wearing thin. Not only does having the right support staff onsite dramatically reduce the stress and frustration for participants who are working under exceedingly tight timelines, but it also create an direct feedback loop into what needs to be fixed, changed, or enhanced by the product team. Even if the engineer can’t fix a problem on the spot, simply knowing that they opened a Jira ticket, and the participant should continue in another direction is a massive relief.

Don’t underestimate the importance of food

I am not joking when I say I saved the most important one for last, but make sure you have lots of food, drink, and snacks available at all hours. This is the fuel that keeps teams powering through an all night coding session and is a huge motivator. In addition to  ready-to-go snacks like chips, nuts, and drinks, try and order hot food throughout the event as well. I have often arranged a late night delivery of pizza to get folks through the midnight slump. It’s amazing the shift in people’s demeanor when a pile of hot pizza arrives. It gives them a brief respite from work and an opportunity to chat with other participants before getting heads-down to make it over the finish line. If you really want to make an impact, have the CEO drop by with the food in the middle of the night. The gesture means a lot to participants who are giving up their personal time to be at the events. Just remember, when you do order, try and cater for different dietary restrictions. Order more vegetarian meals that you first think,  and don’t forget to include some gluten free, and healthy options too.

Summary

There you have it. Seven quick hacks to help you hack your next hackathon. Following some, or all of these tips, will help you not only run a successful hackathon but ensure that the benefits continue long after the prize is awarded, the last pizza is eaten, and the final bleary-eyed participants stumble outside squinting their eyes to protect them from the bright daylight waiting outside.

Previous
Previous

Does Developer Relations Belong Under Marketing or Engineering?

Next
Next

So you want to run a hackathon?