Why Chainlink Developer Relations Is Crucial to the Success of Web3?

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.

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.

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.

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.

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.

Join us on Telegram

Follow us on Twitter

Follow us on Facebook

You might also like