Developer Relations: what it is, and how to measure it

I've been interviewing a lot of DevRels recently (I'm still hiring!) and part of the interview process is, naturally, telling them what the job actually entails. In DevRel that's a bit more important than other positions, because DevRel is such a flexible and multi-faceted role that it means very different things depending what company you're at.

So on the principle that "if you talk about something 3 times you should probably blog about it", here is my "philosophy of DevRel", what I think the role should be and why.

Five pillars

The role of DevRel has 5 primary facets, but they are not all equally important. They are:

• Tier one:
  • Documentation
  • Engineering
• Tier two:
  • Content & Events
  • Product feedback
• Tier three:
  • Community management

I want to talk about all five, what they mean in practice, and why they sit where they do in the stack-ranking, because there's a lot of nuance in there.

Documentation is the bedrock of DevRel

Everything in DevRel begins and ends with good documentation. The core of the job is, in a very real sense, to get developers to consume the documentation. Documentation (via SEO) is how developers often discover your product in the first place, it's how they learn what it really does and how it does it, it is what convinces them to actually pick up your product and use it for real (or not).

It is also by far the highest-leverage thing you can work on. Every 28 days more than 130,000 people hit the Arize AI documentation sites. Every change you make there affects hundreds of thousands of people eventually, far more than read the average blog post, YouTube video or conference talk. And documentation readers are usually pretty engaged, so these are high-quality interactions. Investment in documentation pays for itself over and over, and very quickly.

I draw a distinction between two types of documentation, both important:

Feature documentation

This is table stakes. Everything your software does, every API, every button, every feature must be documented somewhere so people can find it and figure out how to use it. You may think your product is self-explanatory but you are wrong. Feature documentation has to be comprehensive, readable, and up to date. Machine-generated API docs from your OpenAPI.json are not sufficient, they are the "fuck you" of documentation.

Narrative documentation

If you've ever heard me talk about DevRel then you've heard me talk about the importance of narrative docs. Narrative documentation takes a point of view: it says "I think I know who you are as a user, I think I know what you are trying to accomplish" and it works to get the user there, step by step, as fast as possible. The speed is crucial: users who haven't yet committed to your product are only going to give you a certain amount of their time and attention, and you need to get them from zero to real value as fast as possible.

If you can show users real value quickly, they may be convinced to spend more of their time going deeper. Good narrative documentation encourages this by splitting into phases. Earlier phases get to some basic value, and then later phases build on the work already done to get the user further into the product.

Narrative documentation is a risk: if you pick the wrong user persona, you will spend energy explaining how to do things to people who don't exist and your real users will wander off. So it's important to ground your narrative documentation in data if you have it, basing it off of real numbers of users who have what use case and use other associated tools. And be prepared to explain really basic things: meet users where they are, not where you wish they would be.

You have to do actual engineering

I describe the people I hire as Developer Relations Engineers, and that is a very intentional choice of words: I expect actual engineering to happen, and I expect them to be capable of it. The advent of LLMs has thankfully made knowledge of any particular framework or programming language much less crucial -- a good engineer can vibe-code their way through most stacks with Claude Code's help -- but that requires that they are a good engineer. They need to be able to think about complex problems, break them down, think at a system level, and work within constraints of time and resources. You have to have built a lot of stuff to pick up those skills, so I look for people who have done actual engineering in their past.

What they build is open source software. DevRel is about up-leveling developers into your product as fast as possible and a great way to do that is to throw them a piece of open-source software that builds 50% of what they were going to build anyway, which they can pick up and customize. Again, you need data to make this work: you need to know who your users are and what use-cases they are likely to have (and they're going to have lots, so you're going to need to build lots of different open-source repos, not just one).

Building real software also has other benefits. It's usually a really great way to dog-food a developer product. You're not building a toy, you're building real software that interacts with your product in realistic ways. This is also a great source of product feedback (see below).

And thirdly, open-sourcing real software is a great source of content, which brings us to our third pillar.

Content generation is key, events are mandatory

Documentation is how you make the very best use of a developer's attention. But a big, big part of the job is generating that attention in the first place. This is where your content skills come in.

Content these days is relentlessly multi-channel. We pay attention to five different social networks (Twitter, LinkedIn, BlueSky, Thread and Mastodon) in addition to having a blog, a YouTube channel, and programmatic advertising on TikTok, Instagram and elsewhere.

The good news is that if you have good documentation and are doing real engineering, the first two pillars, then the content writes itself. A good piece of narrative documentation turns very easily into a video walkthrough, a blog post discussion, a Twitter thread or a LinkedIn article, and open-source software likewise gains a lot of attention from the right kind of users. So a lot of the work of generating content is frankly pretty mechanical these days, especially with LLM assistance. But good judgement and human legibility still require human oversight.

Stupid Web Tricks

One type of content that doesn't come directly from docs and engineering is what I refer to as "Stupid Web Tricks": you look at social media, you find what the buzzword of the day is, and you write some content or build a demo that relates to that and garners some attention. If the demo is in some way related to your product, that's even better, but it's not mandatory. If you've built a good content funnel in your documentation, then sometimes it's worth trying to go viral: throw a couple hundred thousand views into your funnel and some percentage of them will convert.

But going viral is not the goal of the team. You can't do it if you don't have good docs and solid engineering to welcome curious people once they've been lured in by your viral content. It's strictly secondary, and it's important to remember that because going viral is fun, gets lots of attention from management, and can therefore be addictive. Be judicious and intentional about it.

Events are mandatory

Some companies think of events as the primary thing DevRel does, but they are firmly in the second tier. This isn't because events don't work: they absolutely do. You get high-bandwidth, real-world conversations with actual users. You get really focused, sustained attention if you give a talk. Events generate leads (more on that later). You have to do them, and they are worth doing.

But events are also expensive. Both in terms of money -- sponsorships cost tens of thousands of dollars before you pile on the cost of flights and hotels -- but also in terms of time. Every day spent at an event talking to 100 people is a day spent ignoring the hundreds of thousands of people who read your documentation. They are a real distraction from the core work. So you have to pick events that work. Those are:

• Big: if there are going to be less than a hundred people, do not go unless it's some kind of dinner event where you get half an hour of their undivided attention, and even then it's a risk.
• Focused: all audiences are not created equal. Are these people likely to want to use your product?
• Value for money: my rule at LlamaIndex was that I was willing to spend about $10 per audience member present. This excluded us from a lot of fancier conferences! Your number might be higher, but you should be thinking about events in terms of dollars-per-head versus, say, programmatic advertising (which is a lot cheaper but also much lower quality attention, so you should use a multiple and not compare them directly).
• Real sources of attention: a booth at a conference is your means, not your end goal. A booth is not going to get much traffic unless you are also speaking at the event. Always try to be a speaker, even if you have to pay to play.

One thing you'll always get at events is great product feedback.

Product feedback

At my last three jobs, Developer Relations has sat in the Product organization, and having looked at how other orgs arrange things it's my firm conviction that that's the second-best place they can be short of being a separate co-equal top-level organization.

Developer Relations folks are second only to sales in getting a firehose of real, actionable product feedback from real users, and are often better equipped to think strategically about that feedback (versus sales who often have short-term pressures to think about). It's important that you put processes in place for that feedback to reach back to the actual Product team. Good Developer Relations people will deliver not just feedback, but product direction and priority: what's wrong, what would fix it, and how important that is relative to other things the Product team could focus on.

Antipatterns for organizational structure of DevRel will put them in Marketing or Engineering. In both those cases they will get measured too narrowly in a way that's detrimental to the team and the company as a whole (see Metrics, below).

Your team should know that their job is not polishing the turd. They should be empowered to imagine how the product can be better, and with processes in place that real change actually happens as a result of their feedback. In today's vibe-coded world they can even build product feature prototypes or commit PRs directly to the product for smaller fixes.

Community management

Community management is undeniably part of DevRel's job but I put it in the third tier by itself, and I do that very deliberately. An organizational antipattern is to treat your DevRel team as a sort of customer support team. That's not what they are. Customer support is an important job of its own that needs different people, different goals and above all different metrics (see below).

Helping users directly is something DevRel should do sparingly. Not because it's not helpful, but because it doesn't scale. Helping one person at a time is right at the other end of the spectrum of documentation, where you can help hundreds of thousands of people at a time.

Instead, DevRel's role in community should be the "management" part. It's about putting systems in place so that users can find each other and help each other without involving you directly. This is way higher leverage and way more effective. Your DevRel team should absolutely be making sure your Discord or Slack community is a safe and productive place, but not usually by helping out people directly.

Metrics

If you've followed all this advice and put all these systems in place the next most obvious question is: how do I know if this is working? And that my friends is the hardest, and from my perspective unsolved, problem in Developer Relations.

There are lots of bad ways to measure DevRel.

If you sit DevRel in the marketing organization they will get measured (inaccurately) by number of dollars of pipeline generated. This is often horribly under-estimated -- somebody reading your documentation might take months to eventually convert, and no cookie lasts that long -- but also driving direct conversions is only one part of the job.

Another bad way emerges if you sit DevRel in the engineering org. Then they'll get measured on features committed, PRs opened, or -- god help you -- lines of code. Don't get me wrong, engineering is part of the job, and those metrics are one thing that can go into measuring developer relations, but they are not and should not be the only way.

The best way I know of is to combine multiple measures. Dollars generated for sure. Features committed (or contributed to the Product team) as well. Attention generated is a third way, measured in views to blog posts, YouTube users, and social media likes.

But a fourth important thing to measure is the vibe. Part of the goal of Developer Relations is, well, relating to developers. They have to like you. You can't measure that with views, or money, or lines of code. Vibes are intangible and immeasurable but keeping the vibes good is part of the job, and a responsible org will know that.

Go forth and relate

I thought this would be a very short post and I was wrong. Turns out I had a lot of thoughts about what this job is and how to measure it, and I hope it's been some use. Now I'll go turn it into a YouTube video, a conference talk, maybe a LinkedIn post...