Getting the Most From a Hackathon

Building a relationship with your third-party developers is key to marketing.

Hackathons are often used as a way to engage developers in new products, promote internal collaboration, launch a new product, or help attract new talent. They’ve been attached to user conferences and have even spawned multiple vendors that help tech companies run them.

While I was editing the Developer Marketing: The Essential Guide, I got to spend some time reading about the subject and wanted to highlight some of the findings on this great tactic.

I’ve taken a screengrab of the definition of a hackathon from Google’s knowledge graph, as I think it’s a good, straightforward description for anyone unfamiliar with the term.

A description of a hackathon from Wikipedia

‘Hackathon’ is a portmanteau of the words ‘hack’ and ‘marathon,’ but unlike a marathon, those participating are usually organized into teams. The duration varies, but often a hackathon runs for a period longer than 24 hours, frequently over a weekend, and is characterized by an informal atmosphere, the hackers subsisting on coffee and pizza and sleeping at the venue for just a few hours wherever they can find a space. Washing is (probably) optional.

Why Run a Hackathon?

Frequently, software organizations in their early stages of development consider a hackathon a way of seeding interest from developers. As Luke Kilpatrick and Neil Mansilla, of Atlassian, write in their chapter:

Many companies have the idea of “let’s just add a hackathon to our user conference and see what happens!”. Without clear goals and a strategy, what usually happens is a train wreck that lasts 12 to 48 hours, with developers solely focused on putting together a fancy or funny demo to take home a glittery prize. Most hackathon projects die shortly after the event, or worse, never make it beyond the presentation deck.

Atlassian has a different approach and sets very specific goals. Their Codegeist event runs once a year with the aim of bringing new apps into the Atlassian Marketplace. Rather than a single weekend spent eating junk food and sleeping on bean bags, participants have between two and three months to come up with an app. For it to be considered for a prize, it must pass through the Marketplace app review process and be live on it. As Luke and Neil explain:

Compared to traditional hackathons, where the results often range from demoware to falling short of a minimum viable product, Codegeist is aimed at delivering fully baked apps, ready to serve customers. Even if an app doesn’t win the contest, the real prize for the developer is having an app on the Marketplace with an opportunity to reach Atlassian customers.

Codegeist has a proven track record of driving success in the ecosystem and marketplace. For example, the first-place winner of Codegiest in 2007 was an app called Checklists for Confluence. The app was built by a single-developer startup called Comalatech. Today, Comalatech is a multi-million dollar business, with over 40 employees around the world, and over a dozen apps on the Marketplace that have been installed by more than 10,000 customers. Many other top-grossing Marketplace vendors got their start by participating in Codegiest, including Easy Agile and Code Barrel.

This approach works brilliantly for a large company like Atlassian, but for many smaller organizations, a modest, time-limited hackathon is all they can support at their stage of maturity. Many participants will deliver nothing beyond a basic demo, but that’s not necessarily an anticlimax for them if they’ve had fun, made some industry connections and learned some new skills. They can take their prototypes away to be developed, and back at base, they can build on the knowledge they’ve gained. They should also have been able to get direct contact with the development team for the platform they’ve been working with, and so have had the opportunity to put forward their case for a particular feature, defect fix or roadmap. As Neil and Luke from Atlassian put it:

Physically meeting someone establishes a personal connection that goes beyond the code, and beyond the business aspects. It engenders empathy—the ability to understand and share feelings of another. If this feels all too personal and squishy—good, you’re on the right track. Understanding the motivations, challenges, and tribulations of the developers in your ecosystem can help your company make better informed decisions, and vice versa.

For the hackathon organizers, then, it’s not always about what is developed at the event so much as the feedback received about the product and its supporting resources. Hackathons can be a great way of fueling developer awareness and interest in a new technology, and a valuable testing ground for product ideas. For that reason, it’s important that the product management and product development teams attend to talk to the participating developers.

To reinforce this view, we have a candid section from the chapter by Ana Schafer and Christine Jorgensen, of Qualcomm Technologies, Inc. They explained the following observations on taking their DragonBoardTM 410c to a hackathon:

With developers working under such tight time constraints, we could immediately see what was easy to follow and where things were lacking or totally missing. Early on, we had turned to our company’s internal resources and to our vendor ecosystem for documentation. In most cases, it had been written by savvy engineers for savvy engineers and assumed too much foundational knowledge for the broad audience we were approaching. Over time, when we thought we had addressed much of the feedback and that our resources were really solid, we turned from doing hackathons that targeted mostly professional developers to Major League Hacking, which put us in front of thousands of university students and gave our content its biggest trial by fire. We got a rude awakening about how many leaps in knowledge our content took, and it was only after we started providing level-appropriate resources and sample code that we began to see a strong number of completed projects from the hackathons. The takeaway points to share from that experience are that you should always be open to feedback from the community, as there will be different insights from each new audience you reach out to. It is easy to become complacent when there are so many glaring needs vying for your attention.

Makerologist and DIY Robocars (Excerpt)

Let’s turn to a specific hackathon cited in the book by Pablo Fraile, who works at Arm. In this case, the hackathon lasted just a few hours and was aimed at introducing possibilities and having fun, rather than building anything to last:

In the new field of deep learning, one of the challenges we face at Arm is how to explain to our market that many deep learning and AI tasks can be performed on low-cost Arm hardware without needing to spend huge amounts of money in backend compute power. Because Arm CPUs, Microcontrollers, GPU and other IP are so prolific, if we could educate more developers on the fact that Arm processors can be used for AI, we would be able to create a major impact on the market.

Many developers feel intimidated to prototype and test AI functionality in a way that doesn’t require reading white papers or spending huge amounts of time adopting heavy deep learning frameworks. This is where Makerologist and DIY Robocars came in.

When we look to market our products to pools of developers, it is very beneficial to locate communities that have already coalesced around a single niche product or application. With 10,000+ members and 40 global meetups, the DIY Robocars movement to create low-cost autonomous vehicles using Arm technology seemed like a strong fit for our objectives of efficient one-to-many developer marketing efforts. We engaged with Makerologist’s Clarissa San Diego and DIY Robocars co-founders Will Roscoe and Adam Conway to launch the very first Seattle DIY Robocars event.

After much planning, we convened 77 developers to build and race 10 DIY Robocars and were able to attract key AI technical talent from throughout the Seattle region to spend three hours building and racing Robocars and learning about AI on Arm. By embracing fun, community events with Arm Innovators, we were able to achieve high-quality in-person connections within the demographics of developers we targeted.

The key lesson from this use case was that the hackathon was short and sweet. It took a fun approach in order to encourage developers who already had the necessary skills to look differently at Arm’s hardware, and it built connections between the company and those engineers.

There are clearly many good reasons for hosting a hackathon, and plenty of things to learn when you start out. I’ve recorded a podcast with Shaharris Beh, CEO of Hackernest, who walked me through some of the lessons he has learned the hard way. Check it out if you want to avoid some pitfalls; it’s an entertaining listen!