Skip to main content
whitep4nth3r logo

Defining paths to business value in Developer Relations

This post is not about measuring success in DevRel, but about making an impact in a way only DevRel can do, and should be doing.

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).

What is DevRel, exactly?

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.

DevRel is not content creation

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. 📈

How can DevRel provide business value?

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.

Defining paths to monetary value by 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.

1. Reduce customer churn

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.

2. Increase customer conversion to paid features

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.

3. Increase new customer sign ups

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.

Activities, paths, and overlap

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.

ActivityPrimary Goal(s)Path
Test out and help improve the latest versions of the product and SDKsReduce churn • Increase conversion • Increase sign ups Testing and providing feedback on the product and SDKs based on real-world usage identifies opportunities to improve the end-user experience for all, particularly around new and experimental features.
Identify areas for improvement on documentation, and contribute where appropriateReduce churn • Increase conversion • Increase sign upsImproving documentation improves the end-user experience, reducing frustration and pain points. Great documentation is also a huge selling point for new customers.
Create written content based on authentic experiences of building a real app with real users that helps developers solve problems and build better softwareReduce churn • Increase conversion • Increase sign upsAuthentic "engineer-to-engineer" content around real-world problems and experiences builds trust with existing and prospective customers.
Speak at conferences as a company representativeReduce churn • Increase sign upsConferences are a good opportunity to meet with existing customers. I have met with existing and prospective customers at conferences. Through IRL demos or hallway track conversations, you can help customers understand how your company’s software can solve their problems in ways they didn’t think of before.
Live streaming and building in publicIncrease sign ups • Demonstrating how to use a product in real-time when building software is a proven way to engage a community in the capabilities of a product, especially in the context of building real apps with real users.
Deliver a workshopReduce churn • Increase conversionShowcasing the product and/or new paid features to an already captive audience increases the likelihood of conversion to those features.
Create social, advertising, event copy, and other forms of short-form contentIncrease sign upsBy giving traditional advertising an authentic developer voice, you create opportunities to build excitement around new features and showcase new capabilities.
Support paying customers with technical solutionsReduce churn • Increase conversionDuring workshops, you can create opportunities to provide 1:1 support to help solve customer problems where appropriate.
Write case studies/blog posts/creating videos to highlight particular new features and capabilitiesIncrease sign upsWhere existing customers don’t attend workshops, authentic content based on real world apps with real users can help shine a light on why it’s worth upgrading to a paid feature.
Create content on solving generic technical problems that stem from real apps with real users (i.e. don’t just create content about your product)Increase sign upsA developer searches for a solution to a generic problem; they find your content. If it’s helpful, they are likely to put trust in the company you work for and more likely to choose the product when they need it.
Repurpose existing content intentionally in different media formats to reach a wider audienceIncrease sign upsIntentional content in different formats (written, audio, video, long content, short content) is more likely to reach a wider net of developers who may not have previously considered or discovered your product.
Collaborate with colleagues in more traditional marketing roles (e.g. demand generation) to help more traditional advertising content speak to developersIncrease sign upsDevelopers trust, listen to, and buy from developers. If your company’s intentional advertising speaks to developers when you lend it your voice, you are more likely to increase new customer sign ups.

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.

Closing thoughts

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.

Like weird newsletters?

Join 338+ subscribers in the Weird Wide Web Hole to find no answers to questions you didn't know you had.

Subscribe

Salma is looking at you, with a rather large smile. She's pointing across herself up to her left, with a very tatooed arm. She's wearing a black shirt and black rimmed glasses.

Salma Alam-Naylor

I'm a live streamer, software engineer, and developer educator. I help developers build cool stuff with blog posts, videos, live coding and open source projects.

Related posts

22 Jul 2024

I conducted a community survey and here’s what I learned

Oh sweet, delicious, data. Get in my mouth.

Off-Topic 6 min read →

4 Mar 2022

Why you should ship your silly side projects

Let's take a look at what we learned building a very silly site for the Netlify Dusty Domains project in December 2021.

Web Dev 5 min read →