I don’t mean “finally” as in you’ve been waiting for these answers (chances are you haven’t) but rather that these are the final answers. There is no chance that someone else’s view on these topics are more correct than mine. They should be considered closed.
Of course, I’m kidding. These are just my opinions, but they are based on my personal experience with over 15 years in various DevRel(ish) roles. So, here goes…I will try to answer the questions I have heard repeatedly about DevRel over the course of those years as well as some about the current state of DevRel.
Caveats
First, some caveats. I am intentionally choosing to be opinionated rather than give you the typical “it depends.” The truth is it always depends, of course – every company does DevRel differently and that’s fine. As we’ll see, DevRel covers a broad spectrum, but “it depends” doesn’t help you get the answer you may need. Even the thought exercise of disagreeing with my opinion can help you solidify your own.
Should DevRel be in marketing or product?
The correct answer is neither. Put it in the Office of the CTO or some other independent org structure. This prevents DevRel from being an expensive team that doesn’t directly contribute to the top line organizational goal – leads in the case of marketing or direct product contributions in the case of product/engineering. When times are good, this disconnect is ignored, but when times are bad… (and, if you hadn’t noticed, times are bad.)
The realistic answer is that it doesn’t really matter. Ultimately, whichever department you land in requires alignment with leadership on the role and goals of DevRel. Ideally, the company leadership understands the importance of DevRel (sadly a lot don’t) and/or you have a champion for it amongst leadership. If you have those, I’ve seen DevRel thrive regardless of the team. If you don’t, it ultimately won’t matter where you report.
What activities should DevRel be involved in?
The span of things DevRel has contributed to in my years of experience is massive. Here’s just some:
- All sorts of written content (blogs, tutorials, case studies, books, whitepapers)
- All sorts of video content (webinars, YouTube videos, shorts, training videos, promotional videos)
- Speaking engagements (emceeing, conference talks, workshops, booth support)
- Running events (corporate conferences, community conferences, hackathons)
- Managing community (champions programs, Slack/Discord communities, Reddit/StackOverflow, open source user communities)
- Docs (owning entirely or contributing heavily)
- Sales enablement, customer meetings, customer support (usually as an occasional contributor)
- Partnerships (in some cases DevRel owns the relationship in others they are just contributors)
- Demos (booth demos, example applications)
- Developer experience (in some cases this is high level and in others DevRel outright builds the tools to improve devex)
Honestly, these are just the most common ones I’ve seen and I’ve heard plenty of others, including some where DevRel even serves rotations in engineering – so doing direct product work.
Which of these is the right thing? I think companies get the most “bang for their buck” out of content focused activities (written and video). They have the potential of reaching large audiences and a long tail (as in, they can get picked up by search engines and continue to drive traffic long after they are released). DevRel is also usually very good at managing communities, but those are often a very effort intensive activities and might be a luxury for many companies.
I think events are the riskiest investment. They are expensive (especially when sponsoring but even when just speaking) in terms of both money and time while the payoff is often unclear. I am not saying don’t do events, but many companies (especially right after a funding round) want DevRel to be at every event – often at the expense of other work. I suggest you approach it more cautiously and look at whether that event targets your ideal customer profile and fits into your broader strategy. Don’t just blanket submit CFPs and/or sponsorships.
Nonetheless, I think DevRel needs to be flexible and not “one size fits all,” so adjust to your own needs.
What’s the right way to measure DevRel?
Oof. This topic could be a post in and of itself. Let me share my thoughts as briefly as possible.
In my view, a lot of DevRel work is similar to an internal service organization. It’s activities are cross-functional. As illustrated by the list above, in many cases, DevRel doesn’t even own the top level outcome of the activity that it is a primary contributor to (especially at larger organizations). Let me give you some examples:
- DevRel staffs the booth, speaks at and prepares demos for events but typically marketing owns the primary lead generation goals around events.
- DevRel may assist in customer meetings or sales enablement, but doesn’t own either of those.
- DevRel contributes heavily to all types of content creation, but the high level metric, SEO or conversion goals are usually owned by other teams.
This isn’t always 100% true (there don’t seem to be two companies that do DevRel the same) and DevRel can often own more of these directly at startups that may, in some cases, not have the same degree of organizational structure. Even in cases where DevRel owns the whole activity (ex. community) measuring the impact of these activities is extremely difficult. This is what leads to this question coming up all the time.
Nonetheless, I believe these types of activities are best measured based on quantitative outputs and just as you might an internal service org (yes, there are other internal service org measures like satisfaction, which you can try to apply but might not be a perfect fit).
For example, I would set goals on the number of blog posts, videos or other content you want released per quarter rather than putting the emphasis on traffic, over which DevRel may not have much direct control. I definitely would not add any revenue or lead generation goals to content. Accurately measuring the direct impact of content on actual trials/sales/etc. has always failed in my experience because, while the kinds of content DevRel creates generally plays a role in the buying journey, it rarely leads directly to purchase.
Aiming to do things like increase overall blog traffic by 25% YoY is a fair goal, but I am hesitant to make it a direct measure of the team’s success. It’s best to be careful of the kinds of incentives you structure for DevRel. In the case of content, there are two levers to achieve this goal – increase the volume of content, which can lead to reduced quality, or change the type of content, which can lead to using things like clickbait. It also disincentivizes the team from working on tough but necessary content, like a post that may address a critical customer pain point, but isn’t likely to be a huge traffic driver.
I prefer to consider what would be a reasonable expectation of the quantity of this activity (ex. blog posts) within a given month/quarter when done with high quality. So, for instance, perhaps 2 blog posts/tutorials per Dev Advocate in a given month is reasonable given other activities and you have 3 advocates, that’s 6 per month and 18 per quarter. If this represents an increase in quantity over the prior year or you are giving more time for quality, you should see a corollary increase in traffic. If this is the same as the year prior, expecting a dramatic increase in traffic is, in my view, unreasonable.
I’d work similarly for events. Setting goals around the number of attendees is also unreasonable. Also, expecting more output around events from the same number of people without other adjustments to their responsibilities is also unreasonable.
So, this was less brief than I’d hoped but just to note that I think you need to come up with ways to monitor the impact of your work. Using content as an example again, traffic can help you identify which topics and types of content resonate with your audience, but it should be one of a number of data points that can help guide you rather than the end goal.
Is DevRel Marketing?
I love questions like this. Is “thing with fuzzy definition” also “thing with equally fuzzy definition?”
The correct answer is yes, more or less. The spectrum of activities that the term marketing refers to has substantial overlap with the spectrum of activities that DevRel refers to - enough that describing DevRel as marketing is reasonably accurate, as both terms are fairly fuzzy anyway.
To folks outside tech, I always describe DevRel as basically marketing to developers who pretend to hate marketing. Yes, I said pretend. The same developer who tells you that they hate marketing will do so wearing a T-shirt and socks emblazoned with logos for their favorite tech companies and holding a laptop covered in stickers for a variety of tech companies.
That being said, DevRel is not a subset of marketing. There are plenty of activities that are reasonable to ask of DevRel that would not be reasonable to ask of a marketing department absent DevRel. Building DevEx tools, contributing to the company’s core OSS project or even owning documentation are not expectations one would typically put on a marketing team but would be fair to ask of a DevRel team.
What’s the career path for a Developer Advocate?
Let’s be honest, there are very limited career paths that stay in DevRel. You can improve your title (Junior, Senior, Principal, Staff) at companies that have that promotion path (not all do). After that, you can lead DevRel. I’ve seen these leadership roles go anywhere from just a Manager title to a Director or even a VP title. The latter are rare and usually only exist within companies with very large DevRel organizations. That’s pretty much the top of the ladder in most cases.
However, DevRel is a great path into other roles within the organization. Developer Advocates often make easy transitions into Product Marketing Manager or Product Manager roles. Moving into engineering (or back into, depending on your background) is another option, and where the communication skills you’ve built as a DevRel can make you stand out. Another option is moving into Sales Engineering. This is another role where the combination of technical chops and communication skills can make you successful (and given the potential of variable compensation, this could be a profitable direction as well).
This is definitely not a definitive list. The point is, while there are not a lot of paths up in DevRel, there are many paths up (or out depending on how you look at it) from DevRel. Given the current job market (more on that in a moment), I wouldn’t limit myself to just DevRel roles if I were looking.
Is DevRel dead or dying?
No, but we are in the depths of the worst pullback that I’ve seen in my 15+ year career in DevRel. The scale of the pullback is larger for DevRel than, say, for engineering because it is so closely aligned with marketing, which has also been hit hard across the tech industry. This is why DevRel has been hit harder, in most cases, than product or engineering.
Cutting product and engineering can have immediate impact on the company’s ability to deliver the products/services it has promised. This can come at the short term loss of customers or prospective deals. It can mean our product cedes ground to competitors that are either already ahead or biting at their heels.
As much as I understand and value the importance and impact of both DevRel and marketing, cutting either or both generally doesn’t have as much immediate impact. That impact is generally felt many months in the future when the pipeline is drying up, consumer sentiment has turned on your product and ultimately sales suffer.
If past experience is any guide, this is when companies tend to rehire DevRel (and marketing). Unfortunately, they tend to over-hire in this phase, thus repeating the cycle.
When will DevRel hiring improve?
We’re more than a year into the current layoff surge and hiring slump. In the past, we’d already be seeing an upturn. I am not seeing that at the moment. Few companies are hiring DevRel and those that are hiring seem to be doing so for significantly lower pay while adding on hybrid or on-site requirements in many cases.
This is where I’m gonna get a little bit political on you. The current leadership in tech seems to be at war with their employees. As I’ve stated before, they are actively dreaming of replacing their current workforce with an artificial workforce built upon AI. This doesn’t just impact engineering, where AI has shown that it can potentially improve productivity (yes, there are debates about this…but let’s assume it’s true for the sake of argument) but also marketing and DevRel. In addition, they are investing in aligning their products in some manner with AI, a resource which, at the moment, is pricey and unprofitable. Meanwhile, interest rates are still elevated and VC money has largely dried up (and even when it is exists, it’s being excessively funneled into and consumed by AI). Add to all of this fears of a potential slowdown or even recession in the US that could cascade globally amidst escalating trade wars.
This is not a normal scenario. So, unfortunately, I don’t see normal rules applying. Usually I would be assuming the impacts of the layoffs in DevRel and marketing would be being felt now (and probably they are) so I’d be expecting things to turn positive in the DevRel job market. But, given all the above, I don’t expect that soon. Definitely not in 2025, as much as I wish it weren’t so.