DevRel feels so in the spirit of Cluetrain Manifesto. Which should make it such a fulcrum for company success, for showing the versatility & flexibility of your offerings & helping forging bridges.
OMG -- this is the story of my life. I tried and, well, failed to be a DevRel guy, and I think this was a large part of it. Well, the parts that weren't actually my shortcomings I guess.
I definitely felt the bottom fall out of the DevRel job market. My last company eliminated the position (though maybe I wasn't any good, I don't know... )
I'm really concerned by this as someone who has recently broken into DevRel. I understand that there will always be jobs for someone like me, but all of the weird skills I have kinda add up into DevRel. It's kind of a dream job for me because I'm able to just create things for the joy of creation and use that to help explain why things are the way they are.
I don't think that's specific to industry though. A prolonged period of ultra-low interest rate environment followed by a rapid rate climb hurts all industries with financing needs.
With respect to those laid off, because losing your job sucks, I never understood the point of DevRel. Why would I watch weird YouTube Shorts when I could read docs?
Making the docs great is often part of what DevRel is meant to do.
ZIRP or no ZIRP, technical people are more respected now and are more often decision makers. I think irrespective of market dynamics, it's more common now for a CTO to be an ex-developer and not just someone who knows how to manage budgets.
This means that any technical product still needs to work on presentation in a non-superficial way. You can't just have copywriters writing "X is the best platform. It's so good. It will solve all your problems", and make sales based on that. You also need great getting started docs, migration docs, explanations and guides. Even before people are actively using those things, they are looking at them and evaluating them to decide whether to buy into your product/platform or your competitor's.
[Disclaimer, I own Ritza a company that offers this as a service, so probably I am biased, but we are seeing pretty strong demand still. So I agree with the article that a lot of the 'do it because everyone else is doing it' parts of DevRel are probably dead, but the need for people who operate at the intersection of tech/sales/marketing is well established now and will exist in some form as long as there are technical companies selling technical products).
I totally agree. If anyone has tried to hire a technical product marketer who "gets it," they will understand there is a really small group of people who have the technical understanding and ability to communicate beyond "X is the best platform." Sometimes early stage companies think their engineers will be able to do it, but often it is not true. They need someone who both sees the internal AND external view of things.
I actually started at DevRel and quickly understood that if you swap writing blog posts for writing whitepapers and website copy, you can easily make significantly more money.
Also, better and more understood KPIs - if I made this really good solution diagram and slapped it on a one-pager that I templated, and then the AE sent it to a customer and it made a sale move 1.2x faster, that's tangible results.
And the numbers don't even have to be insane; I remember building a dashboard as a head of DevRel that was made entirely out of vanity metrics. Today, I don't even make dashboards anymore - the results of my sales collateral are simply evident by the pipeline moving forward.
Also, I'm sorry to say, but so many DevRels are primadonnas - they won't go on sales calls, but they'll go to conferences. If they don't go to a conference every month, then they're not "getting what they came here for". Demand generation is beneath them, since "I don't look at leads, I'm building a community". Bleh.
Much better to work with people - as cutthroat as they may be - who push me to create better content that drives results.
Also led me to creating my first productized service - https://syntaxcinema.dev - and that's been going very well for me recently.
The purpose of DevRel, as I understand it, is to bolster the engineering credibility of your product while fomenting community around it.
This helps in two ways: it makes the product stickier with its most vocal users, and, as a result of this, adds qualified prospective customers to the top of the pipeline funnel.
This is partly why you'll see the more social media savvy DevRel folks do things like post YT Shorts and TikToks: it drives engagement from actual future users.
At some places, DevRel is also a customer success function. They are the thought leaders that companies send out to the most strategic accounts to give talks and drive workshops. Martin Fowler and Kelsey Hightower (before he left Google and/or retired, I think?) come to mind here.
Unfortunately, DevRel is often a marketing function, and those budgets get decimated during down markets.
DevRel were often the ones writing and updating those docs, especially docs that are specifically tailored to integrating with specific frameworks or workflows.
Different developers have different styles. I'm personally inclined to seek out raw API docs, attempt to understand the mental model intended by the developer, then and figure out how to integrate that into my workflow myself. But I've learned from shipping a devtool that a lot of developers really appreciate tutorials that meet them at the libraries/frameworks they already use.
I always assumed docs were either written by the devs writing the software, or technical writers. My mental model of good documentation has two types: old-school, heavily technical (e.g. Postgres [0]), and friendlier-but-still-detailed (e.g. Django [1]).
The former definitely does not attempt to hold your hand in the slightest, whereas the latter has a Quick Start, Tutorials, and detailed information about specific components.
A video is often an introduction to a concept before you get to the docs. the docs ARE better for getting deep into the technology but someone has to tell you about it first.
Yeah, the best videos follow the pattern of "What is this thing?" "Why does it need to exist?", How does it fit into the bigger picture?", and then finally "How do you actually use it?" This kind of stuff is essential for helping people skill up to the point that they can understand why they'd want to use a thing. If you are the one that makes them understand why they want to use a cache like Redis, then it's a lot easier for them to branch into the docs.
* Technical reading is a skill. There's a large contingent who might not be conditioned to read more than a StackOverflow answer enough to copy&paste it. I'm not saying this to yell at the clouds, but because it seems to be true, and we'll have to confront it (but hopefully not via videos with 1% nutritional content).
* Lots of developer docs are generally awful nowadays, for various reasons (e.g., written by people who don't know what they're talking about, written by people who do know what they're talking about but write as if they have no model or even awareness of an other, very low priority and not the authoritative information, or organizational problems for docs produced by companies). Even from some of the most major brands, and from hugely popular language ecosystems. So it's matter of trust: if I read these docs, are they competent, and the answer, in many "job skills keyword" topics, is probably no.
> Technical reading is a skill. There's a large contingent who might not be conditioned to read more than a StackOverflow answer enough to copy&paste it. I'm not saying this to yell at the clouds...
Oh, I definitely yell at the clouds about this. IMO, if you can't be bothered to read docs, don't take up other people's time with questions that could have been answered by yourself.
> ...but because it seems to be true, and we'll have to confront it (but hopefully not via videos with 1% nutritional content).
If by confront you mean "explain to people that they will have to put in the work," then yes, I agree. I'm very tired of people coming up with abstractions to paper over a lack of fundamental knowledge. Abstractions by themselves aren't a a bad thing, but they often leak, and you need to know what you're actually doing.
Alas, in these days we & our companies are having more of a burnt out Gluetrain Manifesto moment/age (through probably only a little bit of fault of DevRels). https://doc.searls.com/2008/08/10/remembering-gluetrain/