What is Developer Relations (and why should you care?)
This blogpost was originally presented as a closing keynote at Glue Conference 2019. You can find the slides and video from the talk on my speaking page.
Have you ever known without a shadow of a doubt that you belong — truly belong! — in a community. That these are your people! And yet you don’t feel accepted by them because they don’t truly understand what it is that you actually do?
Welcome to Developer Relations.
You may be familiar with this term because of the debates about Developer Relations and Developer Advocates that have been happening on Twitter and around the web over the last six months.
For those of you who aren’t familiar with these debates... congrats on staying out of the drama! But let me show you a bit of what’s been going on and what folks have been saying about this industry. These are real quotes from Twitter and Reddit, but I’ve removed the names and changed a word or two to protect the innocent.
Developer Relations involves being a social media influencer on behalf of big corporations -- without being honest about that fact. Unfollowing DevRel folks here has been a good move.
There should be no full-time DevRels. They should all rotate, working on real code and real products half of the time, especially those in dire need of what they are preaching.
And lastly… my favorite:
Am I the only one to whom "developer advocate" sounds like a career path that's a bit like "dermatologist"? ...in the sense that it's people who went to medical school but didn't quite cut it as REAL doctors?
These quotes, and so many others, area prime example of people not understanding what Developer Relations is and the value that we provide to our company, sure, but more importantly... the value we bring to YOU — our technical community that we so desperately want to connect with, not so that we can sell you on our product, but so that we can empower you to do your jobs better.
Because what most people don’t understand is that Developer Relations isn’t just coding. It’s not just folks like me standing on stages giving talks. It’s not sales. It’s not our traditional understanding of marketing these, tho it has some similarities at times. It’s not really even quite engineering or even product.
As Roach says…
Greg Bulmash puts it this way:
And therein lies the purpose of this blogpost... to help you understand the essence of Developer Relations.
The who, what, where, when, why, and how of this largely misunderstood industry.
My goal is to not only answer your questions about Developer Relations but to help you understand why Developer Relations professionals are so passionate about you and how we apply that passion toward empowering you.
What
The first question I want to answer is “what?” I’m starting here because I firmly believe in making sure everyone’s on the same page with definitions. But before we even get to Developer Relations, let’s define 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 for the purposes of this blogpost, “community” includes a company’s employees (at the very least, the relevant product division), current customers, as well as prospects, and anyone who could in the future be interested in using the product… which is a fairly broad group of people.
So how does this fit into Developer Relations? First of all, Developer Relations isn’t just another name for Developer Advocates. Developer Relations is the umbrella term for the team whose primary responsibility is building a community both online and offline. This includes Developer Advocacy, Developer Experience, Events, Community Management, Content, etc. It can even go so far as to include roles like documentation and training at some bigger companies like Twilio. In other words, it’s a really big umbrella, like one of those huge golf umbrellas that your parents used to have when you were a kid.
You might feel like some of these things are reflected in your own roles as well, and you’re not wrong! The tasks that the DevRel team is responsible for aren’t limited to their team. They can often reach into a variety of teams around the company, which is part of the reason why DevRel teams can fall into so many different departments.
Where
I’m going to take a quick detour into “Where” for a moment… because for those of you who have been in tech for a while, particularly open source tech, this might all be sounding very familiar.
So where did this term come from? You’ll hear some folks say it’s brand new. Others say that it’s been around for decades. And in some ways, they’re both right. The term “Developer Relations” is relatively new — the earliest searches for it that I can find are from 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.
However, Open Source or Technical Community Management has been around for decades, since Open Source began in the 1950s and 60s, and broader “community management” in the sense of community organization and forming groups of like-minded people has been around for centuries. I believe that Developer Relations is, at its core, community management for a technical audience, which of course has some nuance to it and a few more technical roles, but at the end of the day, we're not reinventing the wheel... we're at best trying to improve it.
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.
(Back to) What
Which leads us back to the “what” — what IS Developer Relations? At its foundation, the purpose of Developer Relations is to build relationships with and enable our technical communities. DevRel professionals act as a liaison between their company and the technical audience—typically the end users of the product.
While most professionals have the best interests of the business at their front of their minds, driving their day-to-day decisions, DevRel professionals have the best interests of the community as their driving factor. They of course care about the success of the business as well—it is, after all, what pays their bills—but they understand that if the community is happy and successful as a result of using the product, the business is far more likely to succeed as well.
I like this mantra to explain that symbiotic relationship:
To the community, I represent the company.
To the company, I represent the community.
I must have both of their interests in mind at all times.
We’re the connective tissue between the company and community as well as the connective tissue at our companies, connecting product & marketing, sales & engineering, customer support & product, and more, all for the sole purpose of serving you — our technical communities.
So if Developer Relations is the name for the industry or the team of people at a company… who makes up this team?
We’ve got Developer Advocates… we’ve got Community Managers… we’ve got Technical Evangelists or as I prefer to call them, Technical Ambassadors… you might also find a Developer Experience Manager within this group, as well as an Events Manager, Project Manager, and even a full-time engineer or two. So what are all of these roles?
Here’s your TL;DR:
A Developer Advocate is someone who likely has some sort of coding experience… whether that’s an official CS degree, code school experience or been a developer in a past life. They’re often building sample apps, live coding, or giving demos, and engaging with the community on a technical level.
A Technical Community Manager may not have this coding background — tho 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 technical market as well as answer questions about the technical aspects of your product.
Next up: Technical Ambassadors, aka Developer Evangelists… renamed due to religious arguments within the developer community. These are the folks who excel at promoting the importance of this particular product within the larger technology industry.
All of these roles play a part in accomplishing a singular goal: Enabling our technical audience — the developers and ops folk — who use our product to be the best that they can be at their jobs.
When led by an experienced manager who believes in the business value of Developer Relations and has the ability to create a strategy that will set both the team and the company up for success in the eyes of the community, there’s no end to the value that this team can provide!
So that’s most of the popular titles that you’ve likely heard throughout the industry. But there’s one more thing I want to clear up… because I know if I don’t, I’ll get questions about it later.
The “Developer Avocados” on the front of my book. Artwork created by Erick Zelaya.
WTF is a Developer Avocado? Why are there personified avocados on the screen and on the cover of my book, what does this little emoji mean, and why has it taken over Twitter (besides the fact that avocados, have in general, taken over the millennial generation of tech professionals).
This all started over 3 years ago when I was working with the DevRel team at SparkPost. One of our Project Managers had a hard time saying “Developer Advocate” when she got to talking quickly. Instead, it often came out as “Developer Avocado.”
Given how much we all loved avocados, we took on the mantle without much prompting, and soon came up with an analogy for it that helped our coworkers understand our jobs:
You see… DevRel is often referred to as the “fatty” part of the business given that we usually ask for a fairly large budget for our community endeavors, speaking engagements, and conference and open source sponsorships among other things. But we believe that used in the right ways, at the right times, with the right combination of items, we can contribute to the health of the company as well as the overall community of tech professionals.
Therefore, DevRel is, officially, “the good kind of fat.”
Now some of you may be wondering… Can’t engineering and product collect their own feedback? Why do I have to talk to this intermediary group that I don’t really understand in order to get information back to the engineers? When is DevRel actually necessary?
So let me play Devil’s Advocate for a second, because there’s a somewhat valid question here if you aren’t familiar with the value that Developer Relations brings to the table:
Why do we need a DevRel team to get this feedback and improve the Developer Experience? Couldn’t this be done with a combination of Product or Marketing surveys, engineering support, and a technical writer hired to write a good blogpost or two or improve the documentation? It’s just a mindset, right?
Which leads us back to this mantra I mentioned earlier:
To the community, I represent the company.
To the company, I represent the community.
I must have both of their interests in mind at all times.
What sets DevRel apart… what makes us uniquely able to fulfill the relationship-building and listening and understanding that goes hand in hand with building a community of loyal customers, is that our primary focus and our goals are first and foremost based around the community. It’s not just a mindset for us — it’s not just a set of skills — it’s the continuum of skills and approaches that are impactful, maybe even moreso than the term itself.
This focus and attention gives us the opportunity to build up trust among the community. When you know that we’re asking you for feedback so that we can advocate for your needs internally, you’re far more likely to be honest with us. Authenticity breeds authenticity, and while it’s entirely possible for Product & Marketing Professionals to have this viewpoint as well, their priorities are split between feature releases and lead generation, respectively. Which means the Developer Relations team is the only one that has your best interests at heart 100% of the time.
Who
So now that you have a basic handle on “what” DevRel is and some of the terms it includes, as well as “when” it’s necessary for tech companies, let’s move on to “who.”
First of all… we are among you. There are many of us at technical conferences around the world at this very moment. We take part in discussions in your community chat rooms. We watch the conversations happening on Stack Overflow, Reddit, The Practical Dev, and other public forums.
On a serious note though, we hang out in these places not to be creepy or to ferry company secrets back to our coworkers, but because the better we understand your pain and the problems that you’re facing, the more equipped we are to help.
But why do we care about this? What’s our motivation?
Let me share a few things that I heard from the DevRel community…
We live for the moments when someone tells us that our work has helped them. I’ve had a “wins” folder for years that has traveled with me from computer to computer that has screenshots of emails, tweets, DMs, and more from community members who have sent me thank yous for the work that I or my team has accomplished.
We also want to make your jobs easier which means hearing all of your feedback… not just the happy bits. As you can see from Ken & Greg in their tweets, we want to make your lives easier because we genuinely care about people and as I mentioned in the previous slide, we live for your “a-ha” moments.
Even having to take hard feedback to the team is worth it because we feel your pain. We’re just as frustrated (if not moreso!) when things don’t work right because we want to do better by you.
Why
All of this background information leads me to the core question that I’ve heard from so many technical folks: Why should I care? After all… DevRel professionals are simply folks that travel to a whole bunch of conferences, give talks, host parties, and complain (or humble brag) about how hard it is to be on the road all the time… right?
This meme went around Twitter a few years ago and it’s right in some cases… I’ve lost track of the number of flights that I’ve fallen asleep on (or tried to). But it also shows a very, very narrow view of DevRel, which is a problem that I think we’re somewhat to blame for ourselves… and one that I’m working to fix.
This tweet from John Cavnar-Johnson sums it up perfectly:
And while I recognize there’s some irony in my referencing this tweet from a blogpost where I’m largely “talking” at you, I’m hoping all of this context will help you better understand the value that Developer Relations has, not for their company, but for YOU, the technical audience we’re trying to serve.
I also think it’s worth noting that out of the several dozen responses that I got from Developer Relations professionals when I asked this question — what do you wish developers knew about your job? — the only ones that mentioned anything about conferences and travel were statements like these:
Dev Advocates have technical skills; we don’t just give talks.
We are not talking heads.
Traveling and shows can actually be grueling and brutal - not fun.
Daniel Appelquist put it well in this tweet:
So if our jobs aren’t made solidly up of travel, conferences, and speaking, despite what it looks like on our Twitter feeds, what is it that we do? And again… why should you care?
Here’s a small glimpse into what we do that directly impacts you:
We advocate on your behalf for product issues, features, and improvements.
We take good, bad, and ugly feedback to the product, engineering, marketing, and sales teams to help them understand what you’re actually looking for and the pain points you’re facing, as well as where we’ve screwed up along the way.
We write content, make tools, and create sample applications to help you better understand what our product is and how you can use it to make your work-life easier.
We research and write about good practices in our particular niche of the tech industry… again, in hopes of helping and empowering you.
We amplify your work — your code, your blogposts, your conference talks, you name it — the content that you’re producing, both internally to our coworkers and externally to other community members.
So, why do we do all of these things?
Because we value people first and technology second. This may seem backward… after all, we work for tech companies, the success of whose products pay our bills.
But here’s the thing… we all know that the best sales people, the best marketing folks, the best… well… PEOPLE! — the people we most enjoy being around! — prioritize people over product. This is just another reason how Developer Relations is related to product, marketing, even sales, but isn’t quite the same.
And this takes me back to the mantra I’ve referenced twice already…
To the community, I represent the company;
To the company, I represent the community,
I must have both of their interests in mind at all times.
Again, this is the core of Developer Relations, because when we have both of these goals in mind, we are able to not only help the community by providing relevant content, but we’re able to provide valuable feedback to the company, which, in turn, should help you as well.
This is a difficult balance to maintain, but it’s crucial for a successful DevRel team. Why? Because we recognize that if we put the community first, above our company, and above the technology that we’re working with, we help the community to succeed. But we also know that when the company makes a decision that sets the community up for failure, there’s often no coming back from that mistake, which of course impacts the company, but also impacts the community, because you all now have to find a new solution for whatever problem we were solving.
How
So we’ve covered What, Where, When, Who, and Why. All that’s left is How… and this is where I’m going to ask something of you. You now (hopefully) understand the value of Developer Relations as it relates to you, our technical communities. But how can you get involved as a developer or ops person? How can you help us help you? There are a few key ways.
How Can You Help? (the passive version)
Be patient with us. We’re advocating for you internally at our companies and those conversations sometimes take longer than we’d like them to, but trust me when I say that you’re always on our minds.
Understand that we don’t know everything (especially if we work for a big corporation). There may be times when we say “I don’t know!” but that doesn’t mean we aren’t technical, tech-savvy, or capable of helping you get to the bottom of your question. It simply means that we want to build an authentic relationship with you, and in order to do that, we can’t lead you astray by guessing at answers or giving you incorrect information, so instead, we’re choosing to be upfront and honest about our limitations, and committing to work with you to find the answer.
Know that we’re advocating our hineys off for you each and every day. You are absolutely our top priority and we will continue to fight for you, even when it makes our jobs difficult.
How Can You Help? (the active version)
Give us honest, authentic, genuine feedback — all of it, even if it’s not the best news about the product or company we work for. We can only do better with your help.
Tell us what you need — what would help you thrive in your professional life? — even if it isn’t directly related to our product or company. Chances are we know of a tool that could be beneficial or we might be able to introduce you to someone else who can help you more directly.
Lastly, involve us in interesting conversations you’re having in your communities. We love to hear about new tools and concepts just as much as new pain points and issues, and all of this information helps us understand you better and allows us to be more effective at our job — helping and empowering you.
In Summary…
What is Developer Relations? It’s a group of Developer Advocates, Technical Community Managers, Technical Ambassadors, Documentation Writers, Trainers, and more who all exist to empower you to do your best work.
Why do we do this? Because we care about our communities and we put people first, knowing that when we do so, the community, as well as the company, will succeed.
And how can you help? Keep talking to us! Provide us with feedback about our own products, loop us into conversations, and let us know what you need.
Want to know more about Developer Relations? Whether you have additional questions, see a need for a technical community at your company, or want to know how to become a Developer Relations professional, please don’t hesitate to reach out!
My DMs are open, I love talking about DevRel, and I’m always happy to help in whatever way I can.
I’d be remiss if I didn’t thank all of the wonderful people who contributed to the conversations I’ve been having on Twitter and The Practical Dev as well as in the DevRel communities I’m a part of. This is an illustration of one reason why I love this community… everyone’s invested in helping each other and doesn’t think twice about offering advice, answering questions, or simply amplifying someone else’s work.
Particular thanks to Dr. Erik Riedel and Emily Freeman who looked over this keynote before I gave it at Gluecon 2019.
View the full slide deck and video from the talk on my speaking page.
View tweets from my talk on this Twitter moment.