Understanding DevRel: A Beginner’s Guide
Diving into the nuances of Developer Relations
Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
Diving into the nuances of Developer Relations
No comments yet. Be the first to comment.
Beginning a few years ago, jobs in the field of “Developer Relations” started growing at a steady pace. Developer Relations (or DevRel, for short) has now transformed into a field with many nuances and roles. Shifting to a DevRel role after contributing to the engineering team at Stream gave me a whole new perspective on what it takes to maintain the relationship between an organisation and developers building products using technologies built by it. DevRel does not fit into standard marketing/sales, rather it focuses on the relationships with developers and developer communities.
I recently attended DevRelCon Prague 2022 where I met several professionals in the field and I was surprised by how many dimensions and approaches every different DevRel program had.
Going into it, DevRel seemed like a rather unfamiliar paradigm which turned out to be much more interesting than I imagined. I hope this guide helps you understand the purpose of Developer Relations, if it is a good fit for you, and how you can try it out yourself.
Now, to the main question: What exactly is DevRel?
As the name suggests, it has to do with the relationship between an organisation and the developers using the organisation’s products/technologies. But what does this mean? Imagine a bland marketing ad for a product — it lists the features, shows a few flashy graphics, has a cool voice-over, and hopes you are convinced. This is one (rather bad) way to sell a product to anyone, let alone a developer.
DevRel’s role isn’t to sell a product — rather, it tries to foster an ecosystem around the product which consists of various things such as:
Great documentation
Building a helpful community
Guides and tutorials to educate developers
Giving user feedback back to the organisation
…and much more
In a sense, if developers feel they have a sense of comfort when using a product — including a gradual learning curve, easy help when they need it, great resources to learn more about the product, etc. — they are more likely to adopt the product and stick to it.
TL;DR: DevRel isn’t marketing — but it does help marketing. It consists of fostering an ecosystem around a product that helps a developer adopt it as well as find help when needed — either through docs/guides or a community around the product.
This is a tricky question. Despite the aforementioned connection to marketing, DevRel helps in quite a few areas of the company. Often, Developer Relations is mentioned as being the intersection of engineering, marketing, product, and community. Ignoring the complicated Venn diagram, this makes sense as:
DevRel helps engineering by delivering and filtering feedback from developers.
It helps marketing by making the product easy to use as well as creating examples and guides that show the capability of a product.
To product, DevRel communicates clear sentiment and feedback which helps develop it further.
DevRel builds a community around the product which helps reduce the load on other branches.
TL;DR: DevRel lies at the intersection of engineering, marketing, product, and community — and helps all aspects of building a product.
The often-asked question is “What exactly is your role in the Developer Relations team?”. To this, the answer is that the DevRel team can be split into several groups by the responsibilities they hold in the organisation. Some of these can overlap and these are general definitions, not concrete ones. This section goes into several kinds of roles you may see on profiles of DevRel professionals.
Developer Advocates and Evangelists are likely the people you see most when it comes to DevRel roles. In terms of definition, these roles work on the same principle but in different directions. Developer Advocates deliver developer sentiment and feedback to the organisation while Evangelists do it the other way around — making sure the organisation’s side is well-understood. While Evangelists are people who focus a lot on outreach, Advocates also maintain a consistent feedback flow back to the company and make sure any problems are recognised.
Developer Experience folks deal with what developers see when using the product: documentation, the API surface, SDK design, etc. It is their main role to make sure all documentation is up-to-date and coherent, as well as to point out anything that might make users wary when using the product overall.
Having a community around a product is an invaluable asset since it can help in several areas. The community can give quicker feedback than larger organisations using a product can. Interconnected users using the product can also help retain users and explore new possibilities using it. Additionally, having a thriving community can help reduce the burden on the customer support team by having easier questions answered by other community members. If an organisation has any open-source projects, the community can help with contributions and quick feedback and iteration.
Community Managers are responsible for building this community and maintaining it — which includes incentivising users to build user groups around the product as well.
Developer Marketing focuses directly on making developers aware of the product and its capabilities. It also makes sure that the audience of the product increases over time. This can overlap with several other DevRel roles.
Developer Education deals with product directly and is focused on creating content to help understand the product and its functions better. This can be through guides/tutorials, videos, or other sources.
The traditional model of sales works relatively well for a consumer. However, with more companies selling directly to developers, this model needs to change to adapt to the new customer base. To deal with this, DevRel provides a framework to make the product better for developers to use and understand — thus reducing the boring ads of yore and bringing in better ways to market directly to developers. A developer-first company (B2D) in particular can benefit greatly from this approach. DevRel obviously doesn’t work well for companies with little developer focus so it isn’t a silver bullet — but it can do wonders for the right company.
TL;DR: DevRel works for certain kinds of companies (mostly developer-focused) but is much more effective for onboarding developers than traditional marketing.
As seen in an earlier section, there are several aspects to DevRel. However, personally, I see two main routes to DevRel. For the Developer Advocate/Evangelist type positions, serious coding experience is usually required along with a knack for sharing it with the world using articles, videos, etc. Additionally, there is also the community manager route which is slightly less technical but still requires serious interpersonal skills. These two paths generally do not overlap but either can be used for a DevRel entry.
TL;DR: The two main routes are either code + content or community-building. Both require their own skill sets but are definitely achievable.
Thanks for reading this guide to DevRel. DevRel is a rather vast field and it is difficult to summarise it in a single article. I hope you got something out of this post and let me know if you have any feedback or want to know anything more about the DevRel world.
