Defining paths to business value in Developer Relations

After over six years as a front end developer and tech lead in agencies, startups and e-commerce, I side-stepped to Developer Relations (DevRel) in 2021. At the time of writing, I have been employed as an Individual Contributor (IC) in DevRel for four years; I’ve worked at Contentful (2021), Netlify (2022-2023), and Sentry (2023 - present).

DevRel is often a tricky sub-industry to define within the technology industry itself because its function looks different (and should be different) depending on the business in which it operates. To further complicate the definition, DevRel is the umbrella under which three further distinct functions can be defined: Developer Marketing, Developer Education, and Developer Experience. Due to my own experience, this article leans more heavily to discussing Developer Education and Developer Experience.

The activities and output of a member of a DevRel team (in any of the three categories) can include, but is not limited to:

• technical writing (e.g. documentation)

• one-off technical tutorials (written or recorded videos)

• multi-part technical courses (written or recorded videos)

• technical workshops

• example code and projects

• contributing to Open Source projects

• QA/testing for (new) product features

• hosting, speaking at, or attending tech conferences and meet-ups

• hosting hackathons

• social, advertising, event copy, and other forms of short-form content geared toward marketing a product

• community support and troubleshooting

• supporting paying customers with technical solutions

• supporting a sales team

A DevRel audience consumes only the output of what a DevRel team creates, often without the context of the how or the why. As a result, DevRel activities are often reduced to “content creation” within a marketing context, which positions DevRel as a task-based function — both internally and externally to a business — without holistically considering the impact and value of said tasks.

Throughout my DevRel career, the focus of a DevRel team has rarely centred on “content creation” for the sake of itself. In my lived experience, core DevRel activities have always emerged from a desire to help developers solve problems and build better software — regardless of whether or not they are actually using a particular product or piece of tech. The output of these core activities are often content (written, recorded, code samples, live video), but that content is nearly always a side-effect of building real apps with real users. To summarise, at the core of DevRel is:

• helping developers solve problems and build better software

• building real apps with real users

However, it is incredibly difficult to quantitatively measure how much you have helped a developer solve problems and build better software. Sure, you could collect qualitative testimonials and excited replies on social media; trust in you will grow over time and people will choose to actively seek out your resources, opinions and expertise. Your earned reputation as a technical representative of a company will contribute to how much developers trust said company, and its products. This is great for the ✨vibes✨, but this doesn’t translate clearly and effectively to quantitative value.

And what is quantitative value to a business? Money. Sign ups. Paying customers. Line graphs go up. Return on investment for shareholders. Stonks. 📈

Providing business value in a DevRel team does not mean you must dedicate your activities and output to gaining sign ups and paying customers only. But what it does mean, is that:

Most DevRel activities must define a path by which they contribute towards generating monetary value for a business.

We cannot reduce this to simply adding a “sign up” link to every piece of content or activity and hoping for the best. And it also doesn’t mean that you can’t be creative and have fun; because what we can group all activities under is building real apps with real users.

Given DevRel teams are often small in size, building real projects is an activity often sacrificed for churning out content that provides an immediate quantitative measure of “success”, i.e. we shipped 5 blog posts this month. But building real projects that have real users is really the only way you can experience a product just as the customer does, so you can find the same pain-points they do. And because you work for a software company, you have a direct line to the teams and engineers who build the product, and you can advocate for making it better for users, so they don’t stop paying for the product (churn). When I worked with Phil Hawksworth at Netlify, he referred to a DevRel team as “the bridge between the customers and the engineers”; and I agree.

We can split a DevRel audience into three broad categories of developers or customers: paying users, non-paying users, and non-users. These three categories define three broad business outcomes:

1. Reduce customer churn (lost customers and revenue),

2. Increase customer conversion to paid features, and

3. Increase new customer sign ups.

DevRel activities and deliverables should target multiple categories and serve multiple purposes to demonstrate maximum impact. Let’s take a look at a few examples at how activities can create paths to the broad outcomes defined above. I will use examples that I have experienced personally through being intentional about making an impact in those areas, through helping developers solve problems and build better software by building real apps with real users.

To reduce the risk of losing customer accounts, and therefore revenue, DevRel has a role in helping make a product as good as it can possibly be to use. This might often be referred to as the practice of Developer Experience. And in order to understand how the product can be better, you have to experience using it.

For a company like Sentry (an application error and performance monitoring SaaS tool), it is particularly important to build real apps that have real users. Unless you want to spend time automating fake user visits and fake user journeys to your app, you need real users to generate real data in a Sentry account. If you don’t collect a broad range of data from how users use your apps on different devices, in different browsers, and in different locations for example, you might not find an edge-case bug that, when fixed, saves a large customer account from churning.

This is one of the reasons I’ve been building Pantherworld at work. Pantherworld is a text-based game, and has been played by hundreds of people, 24 hours a day, 7 days a week via my Twitch chat interface since April 2024. It’s a distributed app (separate back end and front end) built with Express, MongoDB and Nuxt. At first, this project may appear out of scope of the working hours of a Senior Developer Relations Advocate, but the key thing here is that Pantherworld uses Sentry. I am constantly dogfooding the product whilst building a real app with real users.

This path is definitely more about marketing to existing customers, but it can still be done through building real apps with real users. In building Pantherworld, I have given many live demonstrations of Sentry in a real-world debugging context, which can encourage viewers who are existing customers to upgrade to more paying features. The same can be said for workshops, which are usually delivered by one or more DevRel team members as part of a more formal existing customer outreach programme. When creating and delivering the workshops, you will likely also be building a real app with real users to demonstrate the product effectively, and undertaking another variety of activities detailed below. It's all about giving a relevant, polished, yet authentic product demo.

Increasing new customer sign ups is about widening the net of your influence; and this is where you can get really creative in helping developers solve problems and build better software through making the apps you want to make with the tech you want to use. Granted, this path will usually involve a series of broad approaches and experiments, but here are some generic tips that help you widen your net:

• Learn how to optimise for SEO: if developers can’t find your content, they can’t read it;

• Learn how to tailor your content for different platforms (e.g. social platforms and their purpose);

• Experiment with different media formats and approaches, gather data, iterate, repeat;

• Aim to inspire developers with innovative solutions and attention-grabbing concepts (make it fun); and

• Build trust with developers through building real apps with real users, just like they are.

Here is a non-exhaustive list of some of the DevRel activities I regularly undertake as part of building real apps with real users, the goals each activity have contributed toward, and the defined path to those goals.

Each activity is intentionally designed to help developers solve problems and build better software through building real apps with real users. In doing this you are able to:

• Engage with developers (potential paying customers) authentically and effectively by speaking their language and sharing experiences,

• Use your technical expertise and experience gained through building real apps to help developers solve problems and build better software with innovative solutions in new contexts, and

• Build trust in the community as a credible technologist who builds real apps with real users.

DevRel is not content creation. DevRel is not about views, engagement, or followers; although if those metrics are higher, you may increase your probability of reaching more developers. But that has little to no business value if your offering doesn’t define a path to reducing customer churn, increasing conversion to paid features, or increasing new customer sign ups, at the same time as building trust with the developer community. When all is said and done, developers want to use and pay for good tech that helps them solve problems and build better software. DevRel has an important part to play in ensuring that what a company is selling is good, and that product features are communicated effectively and authentically, borne of real-world technical experiences.

I believe that if you maintain a primary focus on helping developers solve problems and build better software through building real apps for real users, you will create paths to monetary value. And crucially, if you can attribute those paths to monetary value to something you did or made or said, you’ll be able to demonstrate quantitatively how DevRel is adding value to a business. However, attribution is company-specific: specific to how the company measures success, and specific to how the DevRel team at the company measures success. Attribution is also specific to the tools available to the team or company in being able to measure success. This post isn’t about measuring success, it’s about making an impact in a way only DevRel can do, and should be doing.

The approach to “doing DevRel” in this article works to create paths to business value; I know it does — it has worked for me and my excellent colleagues, past and present. And in 2025, I’ll be working on a framework with Sarah Guthals in which DevRel can define specific attributable paths to real quantitative business value.

Stay tuned.