Why Developer Relations Is Crucial to the Success of Web3

Previously, we looked at how early-stage startups can build developer communities and track product-market fit. These initiatives are unlikely to succeed without an effective developer relations team. 

Developer relations professionals often serve as information hubs, frequently collaborating with other operational teams such as product, sales, and marketing and keeping everyone informed.  Since many Web3 startups are developer-focused, it’s worth understanding this role better. Specifically, how an effective developer relations operation can add value even at the early stages and why it is crucial to the health of the Web3 ecosystem as a whole.

In this post, we’ll cover the following points:

  • What developer relations is and how it evolved.
  • How developer relations can support a startup’s evolution through the funding cycle.
  • The aspects of developer relations that are important for early-stage Web3 startups.
  • What to look for when hiring for developer relations roles.
  • How developer relations can contribute to the evolution of Web3 as an industry.

What Is Developer Relations?

Developer relations, or “DevRel” for short, describes a cluster of activities that share a common end goal: To encourage third-party developers to build software and applications for a specific technical ecosystem. 

A Brief History of DevRel

To understand the role of DevRel, it helps to know more about the context in which it emerged. As the open-source movement gained momentum, many individuals served roles that could be put into the category of developer relations, providing advocacy and educational content. However, it did not evolve as a distinct profession until companies began to more actively sell to developers.

The Birth of the Software Evangelist

Apple is said to have pioneered this approach in the 1980s by introducing the role of the “software evangelist,” whose job it was to encourage developers to build applications for macOS and later iOS. 

Apple recognized that a platform is only as valuable as the apps that run on it. For example, the iPhone was so successful in part because it gave consumers access to an alluring range of buzzworthy apps. Although many of these apps were initially produced by Apple itself, the ecosystem has grown to the extent that third-party apps make up 99.99% of the apps available on the App Store.

The Rise of Product-Led Growth and the Developer-First Approach

In 2016, OpenView Venture Partners’ Blake Bartlett coined the term “product-led growth” (PLG) after investing in companies like Optimizely and DataDog. The hypothesis behind PLG was that product adoption could grow organically without heavy investment in top-down sales or marketing. This model was typically applied to SaaS companies where growth was stimulated by allowing individuals to sign up themselves and try the product for free. The goal was to have individual users promote the product within their own departments and professional networks. 

PLG worked especially well for companies that targeted developers directly, such as Stripe, Twilio, and MongoDB. These companies used DevRel tactics as means to foster this growth. DevRel is necessary because developers don’t have the luxury of a well-designed user interface to provide them with an optimal onboarding experience. They need more support—there is no seamless frontend experience to help someone find their way around a new API or SDK.  

Thus, DevRel serves a crucial function in helping to give developers a good first impression, specifically by focusing on all aspects of the developer experience (sometimes called “DX” as a companion to UX). 

DevRel Is an Umbrella Term for Several Functional Disciplines

Large developer-focused companies such as Twilio or Atlassian have entire DevRel departments, where job roles are split into different DevRel functions such as developer marketing or community management. In smaller startups, these functions are often handled by one all-rounder who might not even have “DevRel” in their job title.

The following diagram highlights how DevRel functions are usually split up and contrasts their underlying objectives.

An infographic depicting the four focus areas of developer relations
Adapted from “The four pillars of developer relations”—developerrelations.com

While awareness is clear, the notion of “activation” in a developer-focused product is not always easy to pin down. For API-based products, it is usually the point at which the developer creates an access token and makes their first API call. For SDKs or libraries, it could be when they first import and use a function within their code. The developer’s journey toward activation will look different depending on the product. For a good example of a developer journey map, see Todd Moy’s developer journey at SendGrid.

Developer Relations in Web3

The role and aims of DelRel in Web3 are very similar to those in Web2. In both cases, DevRel professionals have to deal with disparate open-source communities, each with its own distinct culture. The challenge for Web3 DevRel practitioners is the lack of tooling to track the right metrics and simplify low-level engineering tasks. For example, Web2 frontend developers have the luxury of mature, purpose-built frameworks such as React or Vue.js which vastly reduce the time it takes to create fully functional web apps. Equivalent frameworks in Web3 have yet to mature, so Web3 educators have more work to do in getting new developers up to speed.

Web3 DevRel Is Still in Its Early Stages

While some Web3 organizations have entire DevRel departments, such as Consensys, Alchemy, and Chainlink Labs, these are still in the minority. Most Web3 startups have only one DevRel representative, or none at all. DevRel-related functions are instead distributed ad-hoc among different team members.

Even when a Web3 team does have multiple people in DevRel Roles, these people have typically not been in Web3 for long. Many have crossed over from equivalent roles at Web2 giants such as Google, Facebook, and Amazon within the last 12 months. This has not gone unnoticed by the Web2 DevRel community. Indeed, in January 2022, DevRelCon founder Matthew Revell predicted that “high-profile developer relations people taking roles at blockchain firms” would continue to be a big theme in the coming year.

Thus, most DevRel professionals are still finding their feet and focusing on building a set of best practices that support the unique goals of their specific projects rather than pooling knowledge as a professional community

DevRel Is Important for Many Types of Web3 Organizations

When discussing Web3 developer communities, we briefly touched on the types of projects that need to build them. Since developer community building falls into the functional remit of DevRel, any company looking to build a developer community needs to understand how DevRel works.

To recap, companies that rely on developer communities fall into three broad categories that have similar business goals.

Web3 Infrastructure

This category covers a broad set of tools and technologies that foster interoperability within the Web3 ecosystem rather than being tied to one specific protocol.

  • Data Oracles
  • Layer-2 scaling solutions
  • APIs for interacting with blockchains
  • KYC management platforms
  • Distributed file systems
  •  SDKs and middleware for building blockchain applications

Business Goal of DevRel: Increase the number of integrations using the company’s technology, which in turn increases revenue earned through fees charged for API calls and smart contract interactions.

L1 Blockchain and DeFi Protocols

The maintenance of blockchain technologies is typically managed by decentralized teams, but developer education is often handled by open-source foundations such as the Ethereum Foundation or the Cardano Foundation.

Business Goal of DevRel: Increase the number of projects that use a protocol, thereby increasing income earned through transaction fees, which is then used to incentivize miners and node operators to secure the network.

Exchanges and Marketplaces

These are usually centralized platforms for buying and selling digital assets. Although they primarily target end users, they also provide APIs and SDKs for developers looking to automate some aspects of the trading experience.  

Business Goal of DevRel: Increase the number of integrations, which increases the trading activity on a platform and thus the revenue generated from trading fees. Many protocols also provide free and paid access to aggregated trading data which developers can use in their dApps.

Any Web3 startup that aims to build market share in one of these categories needs to invest in DevRel soon rather than later. Naturally, in the pre-seed stage, startups are focused on getting the product done, but once funded, DevRel becomes essential and helps to build investor confidence in the project. 

How DevRel Can Support Startup Fundraising

Startups that learn to master DevRel early are more likely to move faster through the startup funding stages. In a talk titled “The defensibility and value in developer community,” Dana Oshiro, a general partner at Heavybit (a VC firm that focuses on developer-first startups) illustrates how DevRel professionals can help incentivize investors to continue funding a startup. They do so by contributing to metrics that investors are interested in. 

Here’s how Oshiro breaks down the funding stages and the role of DevRel:

Raising Seed Funding

In the pre-seed or bootstrapping stage, DevRel functions are usually distributed among the founding team in an ad-hoc, haphazard manner. Demos might be run by whichever developer is the best at public speaking, a co-founder might write documentation, and another co-founder might handle developer marketing. 

  • Goal: At this stage, potential investors want to see that founders have validated product-market fit and have enough early adopters to keep going.
  • Objectives and Metrics: Investors are mostly interested in metrics that indicate early engagement and interest such as website traffic, social media activity, community signups, number of demos given, volume of developer feedback collected.
  • Takeaway: Even if DevRel functions are distributed across multiple team members, it’s important for startups to centrally coordinate, track, and quantify their early DevRel efforts in the core functional areas. This helps to build credibility when pitching to investors and will aid in moving to the next funding stages.

Raising Series-A Funding

A dedicated DevRel expert is crucial here because of the pressure to deploy seed funding wisely. There is more scrutiny on the operations of your startup as investors need to be reassured that you can meet the next milestone before you run out of funds. Implementing DevRel initiatives and tracking them becomes a full-time job that can no longer be the side-project of a founder or lead developer.

  • Goal: Here, investors want to see that you are acquiring and retaining developers and are starting to identify successful projects that you can use as references and case studies.
  • Objectives and Metrics: Investors want to see that you can meet the following types of objectives:
    (These objectives are tracked with metrics such as developer interactions, reference customers, and retained community members)
  • Building awareness around your product and community
  • Acquiring developers who are motivated to make their first API or smart contract call 
  • Triaging and channeling product feedback.Takeaway: A DevRel specialist is crucial to standardize processes, collect the metrics that investors want to see, and help to troubleshoot friction in the developer onboarding process.

Beyond Series A 

At this point, it probably isn’t enough to rely on a sole DevRel hire as this person will become overwhelmed. Companies need to start splitting off DevRel functions into separate roles such as developer community manager, developer marketing lead, or segmented by region such as developer advocates for Asia as well as English-speaking markets.

  • Goal: Defensibility. Here, investors want to see that you are acquiring and retaining developers and have enough successful developers that you can use as references and case studies.
  • Objectives and Metrics: When seeking funding rounds in the tens of millions, investors want to see more fine-grained data that gives insight into the momentum of a startup, endowing it with the ability to:
    • Continue maintaining awareness, acquisition, and acting on product feedback.
    • Retain loyal developers who stick with the technology beyond simply “kicking the tires”
    • Motivate developers to make referrals and advocate for the technology on their own
    • Important metrics will be Github forks, integrations, number of integrations, and third-party apps in the ecosystem, number of partnerships
    • Takeaway: Startups need to build DevRel teams that consist of specialists who can focus on the different functional areas and deliver metrics in each of the core categories, such as ecosystem growth and product engagement.

Of course revenue is also crucial to track at each of these stages, but this is not the primary responsibility of DevRel. However, it’s vital for DevRel practitioners to understand the direct relationship between their initiatives and the financial health of the startup. This is sometimes difficult because some initiatives are hard to link to revenue and take a long time to bear fruit—especially in the early stages.

Which Aspects of DevRel Should Early-Stage Startups Focus On?

Many developer-first startups focus on developer enablement and community first. This doesn’t mean that marketing or advocacy functions are neglected, rather they are still distributed throughout the team as they were before. The enablement and community functions on the other hand become the full-time responsibility of a single specialist. 

The following diagram illustrates the DevRel profile of a startup that is focused on enablement and community. 

A radar chart depicting the DevRel focus areas for an early-stage startup
DevRel focus areas for an early-stage Web3 startup.

Why Is the Focus More on Activation Rather Than Awareness?

Firstly, remember that this is a snapshot of a specific stage rather than a permanent state—the distribution will shift back to awareness as a startup builds its team. But in the early bootstrapping stages, startups are often better at building early awareness than they are at retaining users.

This is especially true with Web3 projects because founders are under intense pressure to build network effects in order to attract funding. The focus is on getting people excited about their overall product vision and roadmap.

Yet there are countless projects competing for developers’ time and attention. A compelling vision is not enough. A bad developer experience and unresponsive community will quickly erode goodwill and developers will eventually move on to projects with less friction. Building awareness without the ability to retain developers is a wasted effort.

Since we’ve already covered tactics for building developer communities in a companion article, the focus here will be on enablement.

Tactics That Contribute to Developer Enablement

There are many common enablement tactics that are well known to most developer-focused companies. However, many startups still overlook them or execute them poorly. These tactics include:

  • Producing quality technical documentation, tutorials, and getting started guides
  • Conducting product-oriented webinars, live coding sessions, and video walkthroughs
  • Designing informative error messages that capture problems at all layers of the product architecture

These tactics are often executed poorly because startups forget to take a step back and build a holistic view of the end-to-end developer experience. This tactic is sometimes referred to as developer experience design.

The Importance of Developer Experience Design

The following diagram is an example of how to approach developer experience design. It was created for SendGrid, a platform for transactional and marketing email automation, and attempts to map the journey that a developer takes to becoming an activated and recurring user.

A flow diagram depicting a developer journey at SendGrid
Flow diagram by Todd Moy—source.

This example comes from a case study called “Understanding a path” published by product designer Tod Moy. It’s a compelling example because it covers all aspects of the developer journey including content as well as product touch points. Moy looks at the journey of a developer persona he calls “Dewey” and attempts to document his motivations, pain points, and positive moments. 

These kinds of journeys are usually mapped out by product teams, but they’re harder to create when the product is not centered around a user interface. Developer-first companies that rely heavily on DevRel help build these maps and flesh out accurate developer personas. Since product managers rarely exist in early-stage Web3 startups, Web3 DevRel specialists are even more important—they become the de-facto person responsible for user research and product improvement.

How Do Web3 Startups Hire the Right DevRel Talent?

In Web3, the competition for DevRel expertise is fierce. The 2022 TrueUp Crypto Job Report found that community and developer relations roles are four times more in demand in Web3 compared with the rest of the tech industry. That means startups need to be flexible with their hiring requirements.

Compromise on Non-Essential Requirements

Given the intense competition for DevRel roles, startups should be willing to be flexible on requirements such as prior Web3 experience and location.

  • Location: Given that most Web3 organizations are already highly decentralized, most startups find it easy to make concessions here—just remember that there can be bureaucratic hurdles in hiring candidates in certain jurisdictions and time zones must have enough overlap to coordinate effectively.
  • Prior Web3 Experience: Many Web3 job descriptions insist on prior experience with Web3, but the technical aspects can be learned on the job as long as the candidate has prior technical experience in Web2. Also, if a candidate is interested in a Web3 role, the chances are that they are already familiar with basic Web3 concepts such as smart contracts, NFTs, and decentralization.

Many startups still struggle to find DevRel talent even after compromising on the above points. In this case, startups can widen the net further by looking for candidates who are willing to cross over from other related disciplines.

Look for Candidates With Aligned Skills

It’s not always crucial to hire someone that has previously held a DevRel role. Since the profession is still so young, it is full of people who have crossed over from adjacent fields. For example, startups might consider hiring a versatile technical writer who can also respond to technical questions in Discord, a community manager who has technical knowledge and knows how to write docs, or a developer who wants to get into DevRel and has a knack for technical communication. 

In most startups, it’s common for early DevRel hires to be all-rounders who do a bit of everything. Just remember that it’s rare for someone to be equally strong in the functional categories (marketing, enablement, advocacy, and community). Therefore it’s crucial to look at where the candidate’s strengths overlap with your priorities.

Prioritize Empathy

Regardless of a candidate’s professional background, an indispensable skill in DevRel is the ability for someone to put themselves in another person’s shoes. This requires a person to be conscious of their own internal biases and assumed knowledge. They also need to understand the motivations and knowledge gaps of their target audience. This ability to empathize with different types of developers then enables startups to tailor their communication and product strategy to the needs of their target developer.

A Note on Assessing Empathy

Empathy is harder to assess than technical aptitude, which is why it’s sometimes neglected in job interviews. There are general questions that companies ask to test a candidate’s social skills, but for DevRel the task is to empathize with developers specifically.

One technique is to ask the candidate how they would explain a certain Web3 technical concept to different audiences in the style of “5-levels”—Wired’s popular web series. For example, in an article on “Why We Web3”, Patrick Collins, a Chainlink developer advocate explains the concept of “trust-minimized agreements” in terms of an “unbreakable promise” similar to the pinky swear. He empathizes that general audiences are still unfamiliar with the concept of trust-minimization and breaks it down to a concept that everyone can understand. This ability to break down complex, unfamiliar topics into simpler, more familiar concepts is an essential skill for any DevRel professional.

Another technique is to engage in some role playing—you could give a candidate a scenario where a developer is struggling with a technical challenge and asking questions in the community. The candidate plays the role of a DevRel advocate. The goal is to see how quickly the candidate can get to the root of what the developer is ultimately trying to achieve. Again, the skill is to see beyond the minutiae of the specific technical problem and understand the wider context in which it occurs. 

Why Web3 Needs More DevRel

Empathetic DevRel teams can act as guides to help newcomers navigate a complex technical ecosystem. For many new developers entering the space, Web3 can feel like a patchwork of city states filled with competing guilds rather than a cohesive, interconnected industry. This has changed as interoperability has become a priority, yet it often seems difficult to find a common language and terminology. This applies in a literal sense, with the proliferation of smart contract languages, and in a conceptual sense, with competing consensus mechanisms, protocols, bridges, layers, and so on. Thus, DevRel specialists act as interpreters, translating foreign technical concepts into terminology that is more familiar—which is vital to bringing developers over from Web2, where engineering practices are very different.

The DevRel profession is also highly unique—it has dual loyalties. On one hand, the immediate responsibility of a Devrel practitioner is to ensure the success of the project that they represent. On the other hand, their loyalty is to the wider developer community within their industry. They want to see developers succeed regardless of whether those developers are direct customers. That’s why they’re motivated to put out more general educational content and to answer questions in broader developer forums such as Stack Overflow. This has the reciprocal effect of increasing the brand reputation of the companies they represent, but it’s not their core motivation.

Most crucially, Web3 infrastructure startups will increasingly depend on DevRel to succeed. The Web3 infrastructure space is on the rise as entrepreneurs recognize the growing need for decentralized infrastructure solutions. This means that competition is heating up. Startups with similar projects will increasingly need DevRel experts to distinguish themselves from the competition and increase their market share among developers. Regardless of who eventually wins the race, the Web3 space as a whole can only benefit if more Web3 startups embrace DevRel as a discipline that is integral to their success.

Need Integration Support?
Talk to an expert
Get testnet tokens
Read the Docs
Technical documentation