You might have heard of developer relations (often abbreviated to dev rel) or developer evangelism before. Maybe you've met developer advocates at conferences, either tending to sponsor booths, speaking on stage, or running workshops. You may only think of them as glorified t-shirt and sticker dispensers. Maybe you think of them as “tech celebs” — that makes me cringe a little, but it's a fair observation on the surface.
There's a lot happening behind the scenes before, during, and after those conferences for developer advocates. Even though speaking at and sponsoring events are a big part of what we do (both online and in person), there's a whole lot more.
Developer Relations Definitions
We're going to cover the day to day job of a developer advocate in the next article, so first let's lay some groundwork with some definitions. Some of these definitions overlap, some are the way I see the field, and some are based on industry trends. Developer relations is still an evolving field!
So, what is developer relations? Who are these developers and to whom are we relating? Most of the time, the developers are the users or potential users of a software product or tool. This might be a SaaS (software as a service), an application, a plugin, a collection of APIs, an SDK, or some combination of those. I'm going to keep it simple and refer to "the product" from here on out to mean any of these things. I’m also going to use the abbreviation dev rel interchangeably with developer relations.
The main task of developer relations is to build relationships with users and potential users, mediate between them and the company, and advocate for their best interest.
Key Areas of Developer Relations
Developer relations is the bridge between developer users and the company building the product. What does that look like, though? I break it down into four broad areas:
- Awareness. You'll sometimes hear this called evangelism. It's also roughly a synonym for marketing, but marketing to developers is somewhat of a different angle than traditional marketing since developers by and large hate to be sold to. Awareness means letting people know about the product, including features, broad use cases, updates, a product roadmap, and anything else relevant to using it. A big focus here is on problems that the product solves. You might have the best product in the world, but if no one knows about it, it can't help anyone!
- Education. Closely related to awareness is education (and sometimes evangelism can mean the combination of the two). Users and potential users need to know how to use the product, how to solve problems with it, and where to go for help. They may also need help with the surrounding technological areas. For example, developer relations for a CSS framework may produce educational content about the framework itself but also CSS fundamentals, design principles, or using that framework as part of a larger project.
- Feedback, also known as product advocacy or developer advocacy. One of the most critical goals of developer relations is to gather feedback from users and potential users. This could be feedback on the experience of using the product, the documentation, bugs that come up, features that would be helpful, or other technologies that are working particularly well or poorly with the product. This feedback can be taken back to whatever engineering, documentation, and marketing teams would most benefit from it. The community might also give feedback relevant to the reputation of the company or its representatives, which is also extremely important.
- Community. Community is the chameleon of the bunch, as it can be part of developer relations, branched into its own department, or mixed in with customer support. Regardless of whether a specific department is “responsible” for community, community is the backbone of all of dev rel. Community is about building relationships with users: helping them solve problems, celebrating their successes (with and aside from the product), and empowering them to improve in their careers. Lip service or inauthentic community pitches can be spotted a mile away, so it's important to work on this with generosity! Community can mean dedicated forums, Discord servers, Slack servers, or even entire recognition and education programs meant to be more of an "inside group" for feedback or features.
The Relationship Between Developer Relations and Sales
You might notice that there's a glaring omission on this list: sales. Developer relations is not meant to be a sales generator. This is an ongoing debate in the field, but even though dev rel can lead to sales, it is not the primary directive. Dev rel is meant to foster community, support and educate users, and most importantly, advocate to the company on behalf of the developer.
The neutrality of dev rel is critical here: it has to remain unmotivated by sales numbers to keep clear judgment and explore feedback with an open mind. Too much of a profit motive in developer relations can dilute trustworthiness. Think about it. If two people recommend their favorite restaurant to you, but one of them gets a big commission on every table that comes in, who are you more likely to trust? That’s not to say that commissions are bad, or sales is bad (I spent three years in my early twenties doing commission financial sales and it was tough!), but that it’s critical for sales not to mix in too much with dev rel. Dev rel has to at least be an impartial line of communication between developers and a company, but may even be skewed in the developer’s favor.
Because of how wide the scope of dev rel is, the developer relations team might be located under Marketing, Engineering, or Product, or have its own organization in the company. This is an ongoing debate in dev rel which is outside of the scope of this article, but just know that you may find it in a variety of different departments.
This article was adapted from a chapter in my book Getting Started in Developer Relations. If you're looking to break into Dev Rel, give it a look! It's helped lots of people make the leap.