So you want to run a hackathon?
So you want to run a hackathon? That’s great. I have had some of my best experiences at hackathons, either as a participant powering through an all night coding session fueled by adrenaline, caffeine and creativity, or as a host to help and support teams get across the finish line. Hackathons bring developers together like nothing else. But, as a marketing activity is it a good idea?
Types of hackathons
In general, there are three types of hackathons to consider. Choose the one which best suit your participation goal
Online public hackathons where participants from anywhere can join. Sites like devpost.com to a fantastic job of handling all the logistics and infrastructure required to host public (or internal) hackathons.
In-person public hackathons where anyone can join but they have to be in a physical location during the event
Internal hackathons where a company or organization hosts an event. In my experience, these are often conducted in a hybrid model: teams can be in-person or remote and rely on video conferencing tools to work as a team.
But why run a hackathon?
That’s the real question, isn’t it? Over the years I’ve run dozens of hackathons with most of them positioned as a recruitment tool for companies to attract developers. I’d like to challenge this goal straight off. If you are looking to build awareness around your product, there are many better approaches that take significantly less work and will return better results. Keyword resource, demandgen, tutorials, events etc all offer much more targeted results than a hackathon which is focused, requires significant time commitment from participants and organizers, and you still need to drive awareness of your event. I may get flamed for this position, but I have seen too many hackathon goals tied to recruitment fail to succeed. In my opinion, you should run hackathons for innovation as the primary goal.
Benefits of a hackathon
Along with innovation, running a hackathon can offer numerous benefits, both for participants and organizers. Here are some of the key advantages:
Innovation and Creativity: Hackathons foster an environment where participants are encouraged to think outside the box and come up with innovative solutions to challenges. This can lead to the development of new ideas, products, or services that might not have been explored otherwise. This is especially valuable for early stage companies who are still experimenting with product fit and feature roadmaps. It is also extremely valuable for internal hackathons who have a specific problem to solve.
Skill Development: Hackathons often require participants to work under tight deadlines. They often have to learn new skills quickly. Teaching developers how to use your product is an incredibly important aspect of growing adoption. Traditional PLG approaches such as nurture emails can be ignored, or deprioritized. In a hackathon however, you have a very compressed timeframe to learn and build with the additional motivator of prize money at the end.
Community Building: Hackathons can help build a sense of community within the tech industry or specific interest groups. They provide a platform for like-minded individuals to come together, exchange knowledge, and support each other in pursuing common goals. I have frequently used hackathons and small coding challenges very successfully to encourage networking and a sense of community. Hackathons have the added benefit of throwing people with different skills and backgrounds together and having them work as a team divided across coding, project management, and presentation tasks.
Product Development: Hackathons can serve as a rapid prototyping platform for companies or startups looking to develop new products or features. They offer a low-risk environment to test out ideas and gather feedback from real users. At Twilio, we used to run first-look hackathons with the community. We would make alpha versions of products or APIs available to a select set of developers to gain early feedback for the product team to iterate on.
Recruitment: For companies, hackathons can be a valuable recruitment tool. They provide an opportunity to identify top talent, assess candidates' skills in action, and showcase the company's culture and values to potential hires. Personally, I wouldn’t use this as a motivator to run a hackathon. Researching top contributors on sites such as GitHub, Kaggle, Stackoverflow etc are a better way of identifying skilled and passionate developers.
Promotion and Marketing: I already touched on this one, but hackathons can generate buzz and publicity for organizations, especially if they are well-publicized and attract a large number of participants. They can help raise awareness about a company's brand, products, or services. I would run a hackathon in conjunction with another event and ideally a related persona in an effort to draft other marketing activities. For example, at Salesforce, we would often run a hackathon for developers at the same time there was a bigger sales-driven event for business buyers. This way we could leverage the large sales team activities to add a call-to-action for developers to attend. “Hey , we are excited to see you at . Don’t forget to bring your developers along and get them to join the hackathon…..”
Solving Real-World Problems: Many hackathons focus on addressing specific challenges or problems faced by industries, communities, or organizations. By bringing together diverse teams of experts, hackathons can generate creative solutions to these real-world problems. I have seen this approach be very successful for internal hackathons where the CIO sponsors the event and commits to putting the hackathon winners product into production. In addition to solving a real-world problem, this sort of internal hackathon with executive commitment is a fantastic way to break down hierarchies and organizational boundaries, promote collaboration across departments, and come up with some incredibly creative solutions. What’s more, the software company sponsoring the event, can then use a lot of the ideas in future marketing efforts - with permission of course.
Downsides of a hackathon
Everything sounds great, right? Let’s run a hackathon right now! Your sales and business teams have been bugging your Developer Relations team for months to do to. Let’s go. Right now. Sound familiar? Yep, I’ve been there too. Don’t get me wrong, I’m a fan of hackathons, but as I said at the start of this article, make sure you run them for the right reasons (ergo: not as a recruitment tool).
Here are some of the downsides I have seen with hackathons:
Quality vs. Quantity: Pay attention to what you want to get out of the hackathon. Hackathons are for ideation, not production. The focus on rapid prototyping and quick solutions may sometimes prioritize quantity over quality. Participants may rush to produce a product or solution within the given timeframe, sacrificing thoroughness and attention to detail. This is especially prevalent in public hackathons where the outcome doesn’t have to live beyond the event. For internal hackathons, ensure you have a process, and executive sponsorship, to finish the work required to turn the hackathon prototype into production quality code.
Lack of Diversity or Exclusion: be very careful to create an environment that embraces diversity of skills, backgrounds, genders etc. It’s very easy to fall into the trap of inadvertently targeting a segment of your developer population due to physical location, awareness activities and more. I have seen teams create the most amazing ideas when the team is a mix of technical people, business users, and geographically dispersed individuals who each approach the problem set with a different perspective and skillset. Further, be careful of timezones and physical disabilities which may prevent people from attending. I’ve been to my share of in person hackathons where there is no wheelchair access, or the women’s bathroom is way on the other side of the building, for example. (speaking of diversity, please excuse this small rant, but I use gen AI tools to create the banner image for posts. Every time I write “developer …” to generate an image, it only generates a white male in the picture. Come on now! Let’s not train AI models on existing biases. Surely we can do better!)
Burnout: Hackathons typically involve intense periods of work, often with little to no sleep. This can lead to physical and mental exhaustion, as well as burnout, especially for participants who push themselves too hard. Pay extra attention here for internal hackathons. You are asking employees to work excessive hours, but then expect them to show up the next day for their ‘normal day job’. Work with your executive sponsor to build in a PTO day after the hackathon, or a meal delivery service etc to show that you appreciate the extra work.
Intellectual Property Issues: This is a big one! Hackathons often involve the creation of new ideas, products, or prototypes. Without clear guidelines or agreements in place, there may be ambiguity regarding ownership of intellectual property, leading to potential disputes or legal issues. Get your legal department involved early and keep them abreast of activities. The more money you offer as prize money, the more careful you have to be.
Resource Intensive: Organizing a hackathon requires significant resources, including time, money, and manpower. Without adequate planning and support, organizers may struggle to execute a successful event. Really consider whether the effort is worth the desired outcome. As mentioned at the beginning of this article, if your goal is recruitment and awareness, I honestly do not think hackathons are the best strategy. Not only are the resource intensive, you are really limited the pool of people who will sign up to participate.
Online community building is hard: If your goal is to promote community growth and networking, I caution you in using an online hackathon as the tool to do this. Hackathons participants generally form teams via people they already know (especially true for developers) or work with. Once formed, these teams will work in isolation in an online hackathon. This may be ok if this is an internal hackathon where everyone works for the same company and your goal is to promote cross department collaboration, but not for online public events. Unlike an in-person event where you are constantly checking out what other teams are doing, having a quick conversation with a stranger over pizza or coffee, or commenting on milestone checkin or presentation, online events really do not offer much opportunity for authentic networking.
Conclusion
Hackathons can be great tools for innovation. They can really accelerate learning, and provide invaluable early feedback for product teams. And, they can be a lot of fun! I’ve met so many amazing people and been endlessly inspired by people’s skills and creativity. But, hackathons are not the solution to everything. If you are looking at running a successful hackathon, take the time to really identify the goals and motivations. Make sure the hackathon is the right strategy. If it is, fantastic! You will have a blast. If it is not, help the rest of the organization understand why, and give them alternative options that better suit your goals.