What is dev rel? (my perspective)

“What does dev rel do?” I see this question get asked surprisingly often.

Recently, I was given the opportunity to build a developer relations program from scratch and reflect on my 3 years of experience in this role to create a strategy.

I decided to write these thoughts to document what I’ve learned from reading countless dev rel articles, several books on dev rel, and personal experiences on dev rel and how I’ve seen it done effectively.

A lot of the ideas in the post I have learned and expanded on from swyx’s posts. They’re of course not necessarily correct, just my current opinions on things.

What does dev rel do?

Help developers be successful using your developer tool - this is dev rel.

You will often hear developer relations separated into different categories; developer relations, developer advocacy, developer education, developer experience, etc.

• Some companies will place these different teams on a spectrum from public-facing to internal-facing.

• Some companies will move you around from engineering, marketing, and product (and back).

• Some companies will just lay you off because they don’t know what you do.

They’re basically the same thing with different areas of expertise/specialization.

All of these teams fit into the umbrella of developer relations, and a developer relations team has the goal of helping developers be successful using your developer tool.

This can be simplified into working on the developer experience; the level of ease a developer can successfully use your product to achieve their goal.

The developer experience is the most important aspect a developer tools company can have in the long term. I’ve written about why DX is so important in depth in the Tweet below:

This goal might sound straightforward, but it’s multifaceted and that is the reason people are confused about what dev rel actually does.

Breaking down the dev rel goal

So why does every dev rel you speak to give you a different answer when asked what dev rel does? It’s because the goal (help developers be successful using your tool) is vague, broad, and difficult to measure.

This goal can be attacked in plenty of different ways, and depending on the stage of the company, the skillset of the person(s) you hired, and the goals & culture of your company; the best strategy to do dev rel well is different.

Let’s interpret the goal (Help developers be successful using your tool) in different ways as an example of how things quickly get complicated:

• Help developers

  • We don’t have any developers to help → Create awareness by creating content, attending developer conferences, and creating and sharing demos.

  • Developers aren’t opting to use our tool → Listen to the developer community and provide actionable feedback to the team internally.

  • Developers hate the experience of using our tool → Create better resources for developers; build documentation, starter kits, tutorials, etc.

• Be successful using your developer tool

  • What does success mean for your customers and your business? Do you have thousands of individual developers or a handful of teams? The support you provide will be different.

  • How do you retain these successful developers and create a flywheel effect to bring onboard more developers to your tool?

These, among many other jobs I haven’t listed above, all fall under developer relations, and usually no one person is going to do all of it well; they have different skills, preferences, and ideas on how dev rel should be done.

The founders/managers will also have a big impact on what areas they want to see prioritized from the dev rel team (for better or worse).

So, with so much to cover for one role, what is a framework to approach developer relations with? What things should you prioritize, what things should you drop, and what things do I have no clue about?

A framework to do dev rel

After reading countless blog posts and several books, attending and participating in panels, discussing strategies with dev rel veterans, and trying these things myself… the best framework I have seen and try to apply myself is radiating circles by Swyx.

My interpretation of his framework is below.

Radiating circles of DX (by Swyx)

In a nutshell, the framework follows this core idea:

• If your product was intuitive, you wouldn’t need docs.

• If your docs covered everything clearly, you wouldn’t need supporting content.

• If your content covered the hard parts or told a story hard to convey in the docs, you wouldn’t need 1-1 support in your community.

• If all of the above was covered, you wouldn’t need to spend time helping developers in 1-1 chats like Discord, Slack, Telegram, etc.

Realistically, each of these areas is impossible to make perfect, and you should be doing all of it - but it provides a good guide of what the foundation should be when trying to improve your DX and priorities of what to work on.

• You can have a super intuitive product, but a strong getting started section and clear documentation helps a lot. This part is non-negotiable.

• Your docs might be great, but content can help tie things together or make developers aware of what’s possible with your tool. They might check out your tool when they otherwise wouldn’t have done so thanks to your content.

• Your resources might be great, but your customer support, community, events, and general vibes bring a love of using your tool and encourage developers to actively advocate for your tool to their peers.

What does this framework mean?

You should prioritize improving the circles closer to the centre if you want the effort you put into those further from the centre to be effective.

• You could have amazing content, docs, and community but if your product sucks to use or doesn’t solve their problem, then developers aren’t going to use it. You will still see some success, but the efforts you put into everything else suffer.

  • Put simply: “You can't polish a turd”.

  • A good example is viem. Developers love it, a tonne of thought has been put into the product and the experience of using it. Nothing flashy - just a performant, typesafe library that developers love and recommend.

• You could have the worst docs, content, and community in the world but if your product is incredible with an amazing DX, some developers are probably still going to use it if it solves a problem for them. They just won’t like it, and move to something better when it exists.

  • Put simply: “Good wine needs no bush”, but it certainly helps.

  • I’m not going to provide a specific example here - think of any product/company you have heard of N number of times but still have no idea what they even do or any reason to try it.

The two-way relationship of radiating circles

Swyx’s point here (at least as I interpreted it) was your product needs to be good first, your docs need to be good next, and so on.

• If your product is good and solves a problem, some people will use it.

• If your docs are good, they’ll have a good experience using it, be able to achieve complex things more easily, be more likely to continue using your product and recommend using it to other people.

• If your docs are not good enough, they’ll try to find out things in other ways, like YouTube videos, blog posts, or external sites like GitHub issues. This isn’t ideal.

• If your tools are open source, they’ll dive into the code itself to see what’s going wrong or see how things work under the hood. It’s getting painful for them now.

• As a last resort, they’ll join your support channels. Slack, Discord, Telegram. They don’t want to be in there. This is very annoying for most devs, especially if your support is no help at all.

These circles also provide a useful framework for understanding how to get developers to become aware of your product, which follows the reverse pattern.

• Developers are most likely to trust other developers in your community who are advocating for your product. It makes them aware of your product.

• Developers can encounter your product being used to solve a problem in your content or at least become aware that your product exists from it.

• Developers might check out your docs when they finally need to solve a problem and have a “what does this thing actually do?” moment.

Once a developer is aware and willing to try your product, all of these efforts you put in so far lead into your product. This is where the reverse process (described above) begins - they will make their own assessment based on your product, and then read your docs, and go further out as they struggle with your DX.

This is why it’s important to get your fundamentals (things closer to the centre) right.

If you are pouring effort into your community and content, developers will come in to try your product. If you let them down when they arrive with a bad DX, you have wasted your efforts in the wider circles.

The wider circles provide more inflow of developers into your smaller circles, where it’s important for them to be successful. You can also think of this direction as a conversion funnel from awareness to success.

So, what do these circles actually involve? What tangible things can dev rel teams do to improve the developer experience in each of these aspects?

Product

Your goal here is to make the product as intuitive as possible, by continually providing feedback (or directly contributing yourself) to the product itself and also external tools that developers are likely to integrate your tool with.

An exercise I like to try is - raw dog using your product and using only knowledge you can find publicly available from your existing resources (e.g. docs).

Mentally drop all prior knowledge of your tool and try to build something. Is it intuitive? Do things behave as you expect? Is it difficult to figure out how to do things? Are your AI tools able to provide helpful suggestions?

Provide any valuable feedback to your team to incrementally improve the product.

Everything else you make is a step away from your product. Your docs are an interpretation of your product, your content is piecing together parts of your docs to achieve something, etc.

Docs

I am struggling to write advice on writing good docs, but here is what I have:

• Your getting started flow is the most important.

  • All developers will likely go through this and then disperse into the other parts of your docs when they get stuck on what to do next.

• Make them easily searchable and create good information architecture.

  • Things should start simple and get progressively more complex (called “stair-stepping knowledge”) - this applies both on the sidebar and to the content of each page.

• Don’t repeat yourself. You don’t need to write the whole history of Ethereum to explain a concept. Assume some prior knowledge, or have a page that defines something clearly in the stair-stepping structure and then use links to that page wherever that pre-requisite knowledge is required.

  • For example, assume your developers know the programming language; it is not your responsibility to teach them this in your documentation.

Content

Sometimes it’s easier to explain something if you just hand developers the solution or a step-by-step guide on how to achieve something specific. This includes:

• GitHub Example repos - repositories that show best practices of using your tool to accomplish a given goal.

• Step-by-step written & video tutorials - same purpose as above.

• Explainer content (Twitter threads, blog posts, short/long videos) - this helps bring awareness to your tool and its capabilities.

• Build the brand of the individual dev rels in your company - people respect other people’s opinions more than they respect brands, and people associate your employees with your company.

Community

Community is more than just answering questions, but this part is where I lack the most knowledge. I don’t have good answers on how to build a community right now.

• Have a space where your team answers questions from developers like Discord.

• Answer questions about your product on forums like GitHub issues.

• Have less noisy dedicated chats for top-priority teams.

What should I do?

Identify what areas closer to the centre suck and start there. You can identify this yourself or speak to existing developers and learn from them.

If your product sucks, provide feedback or work on the product. If your docs suck, write better docs. If your content sucks, start creating good content; move outwards in the radiating circles as you feel things improving.

This doesn’t mean just doing that thing only; it is about balancing each of these areas among the members of your team and identifying what you should be prioritizing given your unique circumstances.

Enjoyed this?

Follow me on Twitter: @jarrodwattsdev