The time has come. It's going to be another one of those "What is DevRel" articles.
You can find many other similar articles from DevRel colleagues. I recommend reading all of them because even though they are talking about the same topic, everybody has a slightly different perspective depending on the type of companies that they worked with and the type of activities they had the most success doing.
If you work in DevRel, sooner or later you'll find yourself writing an article about your job. This is just part of it I guess... There's nothing you can do against it. Once you get the urge, you just have to get it over with and organize your thoughts into an article. Let's start!
I’ve been working in developer relations for more than 5 years now, more specifically as a developer advocate. Not counting the initial period when what I did was basically DevRel but I didn’t know people called it DevRel. Over the years, I tested a lot of different tactics, made mistakes, learned a ton, and formulated opinions about what DevRel is (should be) really about. I try to put my thoughts into this article in a way that is easy to understand for those who have never heard about DevRel.
I'm also interested in writing this article because from time to time I meet developers online or in person who don't know DevRel but have assumptions about it.
"Oh, you're in DevRel? So you're like a sales engineer?"
"You educate developers? You mean your colleagues who work on the product?"
"What does 'relations' mean anyway? Sounds like marketing to me…"
"Yeah I know what DevRel is. They are glorified sales people, basically."
These are actual opinions I've heard about DevRel from developers (who don't know DevRel, obviously).
So many questions and assumptions… But do not worry, I’m bringing the answers!
What is DevRel?
DevRel stands for developer relations. It’s the idea that there are companies that sell to developers and they benefit from activities that build relationships with developers. DevRel can mean a lot of things depending on which company you look at, but generally, it’s focused on content creation, writing documentation, attending and speaking at tech conferences among other things. On a holistic view, DevRel attempts to optimize the developer journey.
You can consider DevRel as an umbrella term. Under the umbrella, you have three other functions:
- Developer Marketing
- Developer Advocacy
- Community Management
They all intersect with each other. Similarly, DevRel as a whole also works closely with Product, Marketing and Sales teams. Knowledge sharing among these groups is crucial. While Product is focused on creating great software, marketing and sales are generating leads and clients, DevRel is about building relationships with the developers.
Your company's relationship with developers is extremely important if you sell to developers.
How to build relationships with developers?
TLDR:
Find your people.
Help them in a meaningful way.
Repeat.
Find your people
Even though we often talk about developers as if they were a single group with the same problems and needs, in reality it’s much more nuanced. There are backend devs, full-stack devs, mobile devs, data engineers, automation testers, etc… and these are just my own titles I had during my not-super-long developer career.
You need to find which developers benefit the most from using your product and those people will be your people. Those are the people you want to find and help them.
Help them in a meaningful way
Developers have problems and they want solutions. But there's a gotcha that makes it harder to engage them: developers dislike marketing. And this is where DevRel can provide the most value if you are trying to reach developers.
They dislike marketing because marketing tends to overinflate the positive features of a product and be silent on the negatives. Marketing also likes to use big words like fastest, best, easiest etc...
But unfortunately, often these big words are not grounded in reality. And that's causing developers to shift away from anything that is related to marketing because they think (know?) they cannot trust it.
DevRel fixes this problem by combining technical expertise and empathy.
Technical expertise ensures that you can educate developers (and "show them something cool") and be technically accurate in all of your communications (extremely important if you're dealing with developers.).
Empathy ensures that you meet your people where they are in their journey. You are not in "sales" mode if you're in DevRel. You are in "helping" mode.
At the end of the day, you just want to make sure they remember you, your brand, your company and what problem you solve. And when the time comes, they will look up the company website, read the documentation, and get their hands dirty. Developers are good at (and prefer) figuring things out on their own.
I think helping without expectation is the best tactic in DevRel. That’s how they will remember you. Most people have an end goal. And developers are extremely aware of this. It’s very hard to build relationships with developers if you have an end goal.
Repeat
At this point, you found your people and you helped them in a meaningful way. Great. Job done, we can go home I guess? In reality, it’s not that simple. DevRel, just like any other function, needs iterations to improve. DevRel never stops. You can always fine-tune your audience definition (“your people”) and find new places, events, forums, etc where they hang out. You can always find new content ideas that could engage them. You can always come up with new ways to get your core messaging across in a meaningful way. Iteration and search for improvements should never stop.
When does it make sense for a company to consider doing DevRel?
TLDR: if developers are involved in the buying decision or using your product then DevRel should be considered.
It makes sense to start DevRel initiatives, or even build out a DevRel team if the company has an interest in forming good relationships with developers. (To be clear, ‘developers’ in this context means developers outside your organization - there’s also a thing called internal developer advocacy, but that is outside the scope of this article.) So in practice, DevRel can make sense in the following scenarios:
- You are building a product that is mainly used by developers. For example.: cloud database, API, framework/toolkit, etc… \ This is where DevRel is very much needed.
- You are building a product that is mainly used by non-technical people but developers also have to use it in a limited capacity. For example to implement an integration or export data out of your system into theirs. \ This is where DevRel can be useful.
If your company doesn’t create a product for developers nor do your customers have to write code to get the full value of your product then DevRel is unlikely to be beneficial for your organization.
A couple of years ago there was an influx of newer, small developer-focused startups with a strong DevRel culture from the get-go - influenced by the founders. They do DevRel activities by default even though they don’t employ developer advocates (who are 100% focused on DevRel). Over time though, the focus usually shifts towards short-term goals (increasing sales) in which case DevRel initiatives can suffer and the “DevRel by default” culture gets challenged. If they want to be “dev-first” they need to hire a DevRel team at this point otherwise sales initiatives will be prioritized over DevRel.
Isn’t DevRel the same as marketing?
TLDR: It is not. DevRel is more technical. There’s a close relationship between them but the goals are different.
Even though it often makes sense to use marketing terminology in a DevRel context (e.g. talking about leadgen, CRM, top of funnel etc), there is still a distinction between how DevRel and marketing operates.
The first big distinction is what you focus on. In marketing, people often spend a majority of their time on short-term results, e.g. monthly leads generated (MQL, or whatever else you call it) and bottom-of-the-funnel activities.
On the other hand, DevRel usually does more top-of-funnel, long-term work, community management and engagement. It’s true that there seems to be an overlap between marketing and DevRel, but ideally, it’s more of a close cooperation and not an overlap. DevRel is good at creating something interesting that developers care about (a sample application, fun tutorial, a talk, etc) and Marketing is good (or should be good) at “getting the word out there”. Basically, DevRel makes fuel that powers the marketing engine.
In reality, that’s not always the case. Sometimes marketing is doing its thing, and DevRel is playing catch-up to satisfy all needs generated by marketing. In my view, this is not a productive engagement between the two functions. I’ve had more success with approaches where DevRel is given control to define its own direction and marketing amplifies everything that DevRel works on.
At the end of the day DevRel knows more about the target audience and has a better idea of what will work in terms of engagement. On the flip side, it’s also important to be in sync with marketing because they know what “works” from their perspective (be it generated leads, new signups, or some other sales-related metric).
Wrap up
There’s a second part to this article I’m thinking of writing that would focus more on the developer advocate perspective and how to do the job well in practice. Let me know if you are interested, that would motivate me to write it sooner:)
Top comments (0)