A Developer Relations Success Story

A Developer Relations Success Story — 9 minute read

Enabling Developer Success is not just a priority for tech platforms - it is the difference between adoption and irrelevance. Yet, this is notoriously difficult. Achieving this requires more than great technology. It demands a well-executed strategy.

This is the story of how we turned a disappointing hackathon into a major victory, by precisely targeting a specific developer persona.

While this focuses on two specific hackathons, the lessons learnt apply beyond. They demonstrate the critical elements of enabling Developer Success, a fundamental function of any effective DevRel program.

The Nadir: EthDenver 2023

EthDenver 2023 was Hedera’s first venture into a major Ethereum hackathon. Despite offering bounties worth tens of thousands of dollars, we walked away with a crushing result: Zero submissions.

For the DevRel team, this was a sobering moment - a stark reminder of how far we still had to go to win over EVM developers.

When I joined just a month after, my mission was clear: Overcome this rejection, and reverse this outcome. This would not come easy, but it was clear that change was necessary.

Here is what we did.

The Trenches: Preparation

In retrospect, the misalignment was clear: Our tech platform was not resonating with the EVM developer audience. Thus began my first “special project”.

We began by honing in on a key segment, “EVM developers”. Defining a persona allowed us to conduct a developer friction audit. This is a targeted analysis on the pain points developers faced when developing on Hedera. From this, we identified the main friction points that they encountered when building on Hedera.

Collaboration with product and engineering teams was crucial, but not without its challenges. We had to push for changes, some of which were not even on their roadmap yet. We explained that without these changes, we would continue to struggle to win over EVM developers. These were non-negotiable if we were to be competitive. We even made the bold move to embargo sponsorship of EVM hackathons until we had completed these changes. We knew that without meaningful improvements, additional investments would be futile.

In parallel, we developed a new series of “Hello World” tasks, documented workarounds for the final 1% of EVM incompatibilities, and created cheats sheets to streamline the hackathon experience.

The Zenith: EthDenver 2024

After 10 months of tremendous effort and close collaboration across teams, Quantifying the is subjective, but some of the key outcomes were quantifiable:

  • (1) Time to Hello World - 5-10 minutes (this was previously 45+ minutes)
  • (2) Total number of friction points identified + and resolved: 29
  • (3) Number of “deal-breaker” friction points identified + resolved: 4

We had the needed improvements in place, and were finally ready to step back into the ring.

We lifted the internal embargo, and signed sponsorship agreements. The moment of truth had arrived: EthDenver 2024. We re-entered the fray with cautious optimism, knowing that nearly a year of effort would soon be put to the test. The results exceeded even our highest expectations. This time, we secured 18 qualified submissions for Hedera bounties.

From zero to 18! Our hard work had paid off, as we had completely transformed our standing. The EVM developer segment, which had once been hesitant, now chose to build on Hedera.

Mission accomplished!

The Takeaways

The success of your platform at a hackathon is not decided on the event day. This battle is won or lost during the preparation phase.

Turning around developer engagement is less daunting when you learn from the past. Experience matters. Having navigated similar challenges at Rootstock before, I knew that adapting a proven playbook would be key. This would lead to more predictable results, allowing us to skip the trial-and-error phase. This not only saved time, but also gave us confidence in the outcome.

For example, my understanding of the “EVM developer” persona, applied in this context, allowed us to leverage the Pareto principle. We were able to immediately zero in on the most impactful actions, instead of having to start from scratch. This allowed for a much faster pace - akin to laying tracks for a train already in motion.

That being said, it was still very challenging. These were the key problems, and how we solved them.

Problem #1 - Competition for developers

Hackathons fall into two broad categories:

  • White-labelled: Where all the bounties are exclusive to your platform.
  • Shared: Where a wider pool of bounties from multiple sponsors are available.

While white-labelled hackathons guarantee a captive audience, shared hackathons offer the potential for far greater impact. They aim to expand the pie rather than carving out a larger slice. A broader swathe of developers allows you to demonstrate your platform’s strength in a competitive environment. (Note that a good hackathon strategy should involve a mix of both categories. For example, Hedera also runs a Hello Future Hackathon series.)

Other platforms vie for developer attention, usually with increasingly higher bounties. Rather than compete solely on bounty size, focus on providing tailored resources. Ensure that developers have all they need to build quickly and efficiently.

Hackathons are a microcosm for developer adoption. An event with a healthy amount of submissions signals that your tech platform has staying power with developers in the broader context. So use them as a testing ground: As long as you are both observant and helpful, developer experience research intrinsically just happens. To gain the most, capture the insights. Use those insights to determine future priorities for the DevRel team

Problem #2 - Sheer volume of the bounty pool

When every major platform offers bounties, the sheer volume of rewards available can be enormous. This dilutes the impact of the bounties that your platform offers. Participants can be overwhelmed by the options.

This means that you need to be strategic about your spend. Trying to outspend competitors is rarely feasible, as there are always platforms with deep pockets and no immediate concern for return on investment. The goal is to make your bounties attractive through other means.

The most important thing to do at a shared hackathon: Analyse the competition.

  • Which platforms gained the most submissions?
  • Which platforms gained the most submissions per dollar of bounties available?
  • What did these platforms do differently?

Identify their successful tactics (and unsuccessful ones too), and adapt them to your own. Effectively, brainstorm how to improve engagement without overspending for upcoming hackathons.

Problem #3 - Misconceptions

Developers often come into hackathons with preconceived ideas about each platform. Their sources of information are often second-hand, and sometimes further skewed by maximalist philosophies.

If those ideas are actually misconceptions, a developer may choose not to build on your platform at a hackathon for invalid reasons. Developers’ time is precious, doubly so at hackathons.

This is, of course, something that you will want to minimise.

For example, a common one is that blockchains which are not Ethereum itself, or Ethereum layer 2 networks, are not EVM compatible. (I have seen this specific one span both Rootstock and Hedera.)

Misconceptions cost you valuable submissions. It is therefore crucial to proactively deliver clear and concise messaging across multiple developer touch points. Anticipate what these may be in order to tackle them head-on. Specific to in-person events, develop a set of convincing “sound bites”. Have the team rehearse them like stump speeches.

Problem #4 - Developer friction points

I have saved the best for last. Unlike the other 3 problems, this is the only non-optional one. There is little point in sponsoring a hackathon, without first adequately addressing developer friction points.

When building on any new technology, developers inevitably experience moments of frustration. Some examples of these developer friction points are: Something did not work as expected, or there was an error, or could not figure out how to complete a task, et cetera.

Minimising developer friction is essential. The more friction points you have, the less submissions you will receive. It is as simple as that. Even the most enticing bounties can fall flat.

The key is to put yourself in the shoes of the target developer personas. The ones most representative of your hackathon participants. Then figure out what their friction points are, and how to address them. Sometimes DevRel can address them directly, usually through tailor made materials and workarounds. At other times, different teams (likely Engineering) need to be involved, usually in implementing new features or fixing bugs such that the platform works better for the needs of these particular developers.

Wrap

This story illustrates how a well-crafted playbook can turn around even the most difficult DevRel challenges.

Whether you are planning your next hackathon, or crafting a broader DevRel strategy, the lessons here should serve as a blueprint.

Our journey from zero submissions to 18 at EthDenver proves that success is not just about having the best technology. It is also about continuously refining the developer experience: Research, adapt, improve at every step.

When developers believe that they can build on your platform, they choose to, and they complete their projects … that is Developer Success.

Tweet 🧵 #1, Tweet 🧵 #2

Thanks to Matt Woodward for his mentorship, and many (sometimes multi-hour) strategy planning sessions, as these were integral to achieving the outcome.

Thanks to Dana Fujikawa for his top quality work on the developer friction audit, from which I learnt much about how to do one.

Thanks to Nana Essilfie-Conduah, Simi Hunjan, and their teams for enabling such a tight collaboration between Engineering, Product, and DevRel - It is not easy to squeeze additional items into full roadmap, so I really appreciate how they accommodated that on such a tight timeline.

Thanks to Abi Castro for creating developer segments and personas, as well as role-playing them when preparing for developer experience research.

Thanks to Spencer Yang, Owanate Amachree, and Michiel Mulders for their feedback and suggestions on this article.