“What actually is Developer Relations?” is a question that I see almost every week as I’m compiling tweets and articles for DevRel Weekly. The confusion doesn’t stem from the fact that it’s never been defined (narrator: “It has!”), but rather from the fact that if you ask 10 different people in the tech industry for a definition of Developer Relations, you’re likely to get 12 different answers.
I frequently go back to the parable of the blind men and the elephant. As the story goes, there was a group of blind men who came upon an elephant, each one encountering a different (but singular) part of the elephant’s body, such as the tail, a leg, or a tusk. As they begin to describe the beast they have encountered, their answers are so drastically different from each other that they nearly come to blows, accusing each other of lying.
This refusal to accept each other’s specific, but limited, experiences as a part of the whole, causes infighting among Developer Relations professionals in addition to complete and utter confusion among the technical communities we aim to serve.
Many experienced folks have expressed concern and frustration about the fact that we seem to still be focused on defining terms rather than digging into the more difficult issues like establishing business value and developing career paths.
However, without standardized terminology, the “elephant” remains a mystery. Is it a rope? Is it a tree trunk? Or is it a sword? Before we can dive into the truly important conversations, we all need to be on the same page with the basic terminology.
So let’s dig in…
What is “Community?”
Let’s start with the foundational concept of Community.
Community is a group of people who not only share common principles, but also develop and share practices that help individuals in the group thrive.
How we define who falls into the realm of community at a particular company depends on the company’s goals and intentions, but in general, the community will include your company’s technical employees and your current customers, as well as prospects and anyone who could in the future be interested in using the product.
Note: As you can imagine, this covers a wide swath of people! For some companies, this means anyone who has ever (or will ever) touch an API is potentially within their community. Segmenting that community in a way that allows you to find your core audience is another topic entirely, but I’d encourage you to draw those lines early on. Otherwise, your team will quickly be overwhelmed, trying to build relationships with hundreds or even thousands of technical community members.
You may be wondering why I find it necessary to define “Community” before I define “Developer Relations.” After all, “Community Manager” is often put in a completely different category than “Developer Relations,” relegated to social media and online platforms, not focused on a technical audience.
However, Open Source Community Management has been around for decades, since Open Source gained popularity in the 1950s and 60s. More broadly, “community management” in the sense of community organization and forming groups of like-minded people has been around for centuries.
While many people say “Developer Relations,” “Developer Advocacy,” and “Developer Evangelism” are brand new terms, even these phrases have been around for longer than most folks realize. The earliest references to Developer Relations are in 2012, but Developer Evangelists first popped up at Apple in the 80s thanks to Mike Murray, Guy Kawasaki, consultant Terri Lonier, and others on the Macintosh team.
In other words, it’s nothing new — it’s just new terminology. Language is fluid, and just like data scientist is the new trendy name for statisticians, Developer Relations is the new trendy term for Technical Community Management.
So… What is “Developer Relations?”
Developer Relations is, at its core, community management for a technical audience. The purpose of Developer Relations, similar to community management, is to build relationships with and enable our communities, who happen to be technical individuals. Developer Relations professionals act as a liaison between their company and these communities, communicating feedback, advocating for the community’s needs, and making their experience with our product as smooth as possible.
You’ll notice I said Developer Relations professionals -- not Developer Advocates. That’s because Developer Relations is the umbrella term for the team whose primary responsibility is building a community, both online and offline. This, of course, includes Developer Advocates, as well as Community Managers, and Technical Ambassadors (also known as Developer Evangelists). Some larger companies also include folks responsible for documentation, events, and social media, in addition to other roles, on the Developer Relations team.
All of these roles together form a healthy layer of connective tissue between the company and community as well as between our coworkers -- connecting product and marketing, sales and engineering, customer support and product, and more, all for the sole purpose of further enabling our technical audience.
But what are all of these roles and how do we keep them straight? To be honest, there isn’t a standardized way to refer to all of these roles these days, which makes things difficult, both for those outside of the DevRel industry who are trying to understand our roles as well as for DevRel Professionals who are looking for a new role. For the most part, Developer Advocate can be synonymous with Developer Evangelist or Community Engineer. However, some companies are starting to co-opt the term “Developer Advocate” to refer to Sales Engineers or Solutions Architects, recognizing that the title carries a fair amount of power when trying to connect to a technical audience.
By creating an industry standard for each of these roles, we can start to turn the tide, helping others understand the value we contribute to our technical audiences as well as the companies we work for.
Here are my working definitions for the core Developer Relations roles:
A Developer Advocate is someone who likely has some sort of coding experience, whether that’s an official CS degree, code school experience, or has held a developer role. They’re often building sample apps, live coding, or giving demos, engaging with the community on a technical level.
A Technical Community Manager, on the other hand, may not have this coding background — though they could! — but they will absolutely be tech-savvy. They need to be able to carry on conversations that take a fairly deep dive into where your product fits within the broader technology market as well as answer questions about the technical aspects of your product.
Next are Technical Ambassadors, also known as Developer Evangelists. While this used to be one of the more popular titles in the industry, folks have moved away from the “Evangelist” title due to religious overtones. Others have taken the time to distinguish between Evangelist and Advocate, but in short, Technical Ambassadors are the folks who excel at promoting the importance of this particular product within the larger technology industry.
The person leading this team is ideally a Director level or above -- Director of Developer Relations, VP of Developer Relations, and Chief Community Advocate are a few of the titles I’ve seen. These individuals are capable of engaging with stakeholders so that the community can be represented in the decision process. They’re usually able to have technical conversations but are also able to see the bigger picture, and are responsible to build out an overarching community strategy that relates back to the company goals.
Let’s not ignore the elephant in the room -- what about the Developer Avocado trend that’s been going around lately? Why are there personified avocados on the cover of my book and why has the phrase “Developer 🥑” taken over Twitter?
You can read more about all of the reasons why Developer Relations is like avocados on my blog, but it’s become an analogy that resonates with companies and individuals around the globe. Developer Relations can easily be referred to as the “fatty” part of the business given that we usually ask for a fairly large budget for our community endeavours, speaking engagements, and conference and open source sponsorships, among other things.
But I believe that used in the right ways, at the right times, with the right combination of items, Developer Relations can contribute to the health of the company as well as the overall community of tech professionals. With additional research, data, and standardized terms for Developer Relations, more people are realizing that strong communities are not only good for your business, but in many cases, essential to maintaining a healthy product. And no one can deny that a happy community and a healthy product are good for the heart of every company, just like avocados.