While it’s a pretty mature job function in web2, DevRel in web3 is still incredibly nascent. So at ETHDenver this year, we brought together more than 20 developer relations leads from our portfolio to share what’s been working for them and learn from each other. It was the first in a series of Variant Network events for our portfolio founders that connect company leaders directly to counterparts who have faced similar challenges. 

Now we’re sharing a few of the action items with everyone, for the good of the ecosystem.

Below are seven actionable tips that you can implement if you’re new to developer relations:

1. Get your docs in a row.

Developer documentation is the gateway to your project. It serves as marketing collateral and can be spun out into educational content. Three tips from our teams:

• Don’t leave up outdated docs; inaccurate documentation is worse than no documentation. 
• The best developer docs incorporate live feedback, such as links to forums or user ratings of the content’s usefulness. 
• If you don’t have time for a full audit and update, at least update the “examples” section on your docs. This is often the most-visited section and it’s what developers will look at first.

2. Make Discord work for you.

Many teams have a love-hate relationship with Discord, but it’s a helpful tool for onboarding and managing new developers. Setting up a searchable FAQ in your Discord server can minimize the need for developers to come to you for every challenge or question. Like developer docs, Discord channels can serve as an evergreen and easily parsable resource. 

3. Build a global team to avoid backlogs. 

On small DevRel teams, it’s common for user questions to pile up overnight, forcing team members to spend the first part of the day responding to help tickets and FAQs. One of the projects in our portfolio has a DevRel team with members in North America, Europe, and Asia. While their North American teammates are sleeping, those in Asia and Europe can answer questions and help with bugs. With a DevRel team that’s dispersed across the globe, there is someone who can be “on” at any hour. As a result, the team has more coverage and can be more proactive rather than reactive throughout the day. 

4. Physically locate your target audience to maximize ROI. 

You don’t necessarily need to spend a lot of money to get high-quality engagement. When one of the projects in our portfolio realized it wasn’t getting many new users out of sponsoring hackathons, it went to hacker houses instead. “As it turned out, spending $500 on Chipotle at a hacker house was a better investment than doing a broad hackathon,” the DevRel lead said.

5. Form bridges and set boundaries with colleagues.

The best DevRel teams in our portfolio serve as internal “bridges” between engineering, product, and end users. Regular interactions allow DevRel leads to set boundaries and expectations. One project hosts a biweekly meeting between DevRel, product, engineering, and business development leads to aggregate user feedback, decide next steps, and delegate work to the appropriate team. Another project hosts monthly cross-company presentations to update the entire team and explain how it can support them. These little communication feedback loops help manage expectations all around.

6. Get creative to get honest user feedback. 

Sure, you can use NPS surveys to assess developer feedback — and many of our portfolio companies do. But don’t be afraid to get inventive. One project invites all the developers in their ecosystem to a big dinner and asks them to “roast” the company and the product. It’s tough love, but also a surefire way to identify the most critical features to change. Another company conducts live user interviews in which devs share their screen. The DevRel team watches them go from the landing page into the documentation or other relevant resources. This is an easy way to see where users get lost and identify what isn’t clear.

7. Track metrics that indicate a “closed loop” from your developer community. Developers in open-source communities regularly flag bugs or recommend features to core contributors. One company in our portfolio has converted this into a trackable metric: How many of the biggest community-surfaced bugs in the ecosystem did we solve? Another great one: “Time to ‘hello world,’” — how fast can a developer get up and running on your protocol? Codifying measurable metrics like these is a great way to see if individual DevRel initiatives are successful with your developer community.  

These are just a few tips that emerged from the DevRel workshop. We’d love to hear what’s working for you. Share with us @variantfund on Twitter. And stay tuned for more learnings from the Variant Network.

+++

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Variant. While taken from sources believed to be reliable, Variant has not independently verified such information. Variant makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post reflects the current opinions of the authors and is not made on behalf of Variant or its Clients and does not necessarily reflect the opinions of Variant, its General Partners, its affiliates, advisors or individuals associated with Variant. The opinions reflected herein are subject to change without being updated.