Getting the Most from a Hackathon
Getting the Most from a Hackathon
Building a relationship with your third-party developers is key to marketing. Running events is a great way to meet them, but hackathons can fall flat unless you follow some best practices.
Join the DZone community and get the full member experience.Join For Free
Millions of developers are on DZone - your product should be here too! Advertise on Dzone.com
As I described in a recent blog post, I was fortunate enough to spend my summer editing Developer Marketing: The Essential Guide, which aims to be the must-read textbook for developer marketing practitioners. The book is composed of 12 chapters by authors experienced in a field which is coming of age, and who work at companies ranging from Arm to VMware. The contributors were generous enough to share their practical experience and critical insights, and this combination is what creates the book’s value. By admitting their mistakes and using them to develop best practice, the book offers a toolbox to those aspiring to a career working with one of the most marketing-averse segments out there.
I wanted to pick out a particular subject, touched upon in a few chapters of the book, to illustrate some of the insights of our developer marketing experts. I’ve selected hackathons, although I could equally well have chosen the best way to run developer events, building community through advocacy, or countless other topics associated with building trust with a technical—some would say cynical—audience.
I’ve taken a screen grab 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.
‘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 which 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 2 and 3 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 fuelling 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.
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:
Makerologist and DIY Robocars (Excerpt)
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.
Hackathon Best Practice
In the Qualcomm chapter, Christine and Ana list some of the best practice they have learned when running hackathons. They advise the following:
Make sure developers have access to lots of sample code and example projects.
Provide on-site expertise round the clock by ensuring your development team, or developer relations staff, are available.
Run a series of pre-hackathon webinars a couple of weeks before the event. The developers will have little time to comb through documentation at the event, so it’s a good idea to make it easy for them to find information ahead of time. Load them up with easy-to-follow code, shortcuts, sample projects and video tutorials aligned with the main themes of the hackathon.
Encourage the hackathon attendees to come prepared with an idea of what they want to build, and provide some generic suggestions in advance.
Hosting your own hackathon costs time and money. Maybe you can work alongside other companies in your sector, or sponsor other well-attended hackathons that align with your business goals. Experience as an attendee at a few hackathons is essential, of course, as they are a unique kind of event. Get along to a few before you dive in to running your own, perhaps find a way to attend as a sponsor, so you can be involved with the experience without taking full responsibility for the event. Even if you ultimately decide not to run your own hackathon, knowing how to survive one will surely stand you in good stead next time you go camping!
To close, I’d like to highlight a quotation from the chapter written by Jacob Lehrbaum, who works at Salesforce but used to be with Engine Yard. It reinforces the suggestion that sometimes co-hosting or sponsorship works better than sole ownership of a hackathon or other developer event. Jacob makes the point that you can build a relationship with developers by supporting an open source community they identify with:
During my time at Engine Yard, we instead chose to support existing open source communities such as Ruby on Rails and PHP. Given the open-source nature of Engine Yard’s platform-as-a-service, their users identified more as members of these existing open source communities. We used Engine Yard’s offices in San Francisco, Portland, and Dublin to host meetup groups for those communities and others free of charge, and even paid for pizza and beer! By supporting adjacent communities, Engine Yard was seen as a sponsor and leader.
As you consider how to approach your developer group strategy, think about how your users identify and where they spend their time. If your product is part of their identity, you can go about creating your own groups. If your users identify as part of multiple communities, perhaps start by supporting those existing community groups and defer the decision on whether to create your own.
This is a fine insight. If you are a new software company looking to build a following, and you take the time to determine the identity of your target developers and support their choices, you don’t need to make huge investments in hackathons or other meetups.
Hackathons are just one kind of developer event you may be considering as part of your developer marketing strategy. Our book contains several chapters that are specific to organizing events, ranging from meetups and small groups, to larger sessions that introduce a specific technology to developers, all the way up to marquee events like WWDC, Google I/O or Dreamforce.
Developer Marketing: The Essential Guide is available from mid-September 2018 from Amazon in paperback or eBook. All profits from the book are to be donated to worthy causes that support software development in vulnerable or minority groups. Let me know in the comments what you think of it!
Opinions expressed by DZone contributors are their own.