Devrel here, (by the way it’s typically called a Developer Advocate or a Developer Evangelist, don’t get me started on how many questions I’ve gotten about the relation to religion lol)
I think the article does a good job describing what devrel looks like at companies that are smart about selling to the new “tech business world” which is desperate for a way to measure the technical credibility of potential vendors.
But what’s more interesting from someone who knows devrel because I’ve worked in it for 7 years, is that at a more general level it’s just a communication layer that a business can have with an audience or a persona(in this case developers), that is growing ever more important. Whether you’re a platform (google Apple) and need more devs making stuff within your ecosystem, or you’re not selling to developers but you need technical integrations by third parties to enhance The value prop of your product, or you’re ACTUALLY selling directly to developers and trying to expand their mental model of what is possible with the low code tooling available today and why they can and should trust it.
It’s a wide and interesting world in which almost every company is becoming a software company, and almost none of these companies have any idea how to communicate with developers or what they care about.
You’re right that devrel is like a pre-sales role somewhat, but we all know developers are the hardest group to sell to in history, who else could more easily go find a free open source solution or just make it themselves?? You have to be able to communicate about the pros and cons of technology in an honest and coherent way, and that is what Devrel is all about to me.
>You’re right that devrel is like a pre-sales role somewhat
In my experience, at least in the open source world, developer relations folks are pretty different from pre-sales and are usually not in the sales organization. Even if they don't carry a quota, pre-sales tends to be pretty focused on supporting specific customer sales opportunities. Not saying a developer relations person would never do that, but they tend to work much earlier in the pipeline. (Obviously at small companies, roles can blur more. And at pretty much all companies, lots of people get brought in to support sales in various ways.)
> it’s typically called a Developer Advocate or a Developer Evangelist
And a lot of the dev advocates I see on social media (most seem to have a strong presence there) also have an image of an avocado, since apparently a lot of people confuse "developer advocate" with "developer avocado". Just noting that in case you notice a number of people with avocados in their about text and wonder what that's about.
A humorous analogy based on something funny that a co-worker did seems like a joke to me. I'm not claiming I invented it, just saying that it doesn't stem from confusion.
Developer Advocate here (who works in Developer Relations). I think "DevRel" is a big bucket, but what the author is calling "Developer Relations" is just the most visible subset of the bucket.
The impression is that a "DevRel" spends all their time writing talks, traveling to conferences, pitching products and speaking. This makes sense, because the "DevRels" you probably see the most are the ones that are doing these things, and you don't see them doing anything else. A lot of people are surprised to discover that traveling and speaking is actually a very small part of my job, given the number of talks I give, and how often they see me at events.
I think part of this perception comes from the conflation between an advocate and an evangelist. There is endless debate about what these terms mean in the context of developer relations, but for me, the difference is this:
* Evangelists want users to know that a product exists: They're speaking to developers, about the product. They probably report to & work with Sales/Marketing.
* Advocates want products to know that their users exist. They're speaking to product owners, about the developers. They probably report to & work with Engineering/Product.
Both roles are equally important (and sometimes done by the same person), and the "publicly-validated credibility" the author talks about is just as valuable to the product team as it is to the sales team.
I'd add that there's often a community management aspect to the role as well and sometimes that's the title. In general, I find a lot of different titles used which may or may not reflect what the person does day to day.
I even know people who are also product managers who do a fair bit of outward-facing DevRel/Evangelism type of work.
And skill sets vary quite a bit too. I know folks who do a ton of coding, creating demos, etc. And I know others who, while typically at least somewhat technical, are much more on the relationship and community-building side of things.
For those unfamiliar with the term, it's in the article about two-thirds of the way down.
> Commonly it’s just known as a ‘developer relations’ role (so ‘DevRel’ for short)
No, it's not a typo for Dev Reels, which would be an interesting alternative to open source repositories, but I guess you'd have to get good at video editing first!
I misread it as Dev Reels first also, and was imagining developers using drones to make hype videos of them on their laptops to submit to companies along with their resumes.
I try to find a balanced view. For sure, it's a pet peeve to see initialisms and abbreviations without explanation but at the same time, I'm probably just not the target audience if I don't recognize the term. Why am I even clicking the headline? But curiosity rules, so I do click such headlines, and if I don't see a quick explanation of a new term, I'll research it.
I have worked as a developer advocate at AWS for almost 4 years now. I think this article gets one half of the equation, the public facing part, but what they are missing is the second half, which is that developer advocates also serve as a bridge back from the end customers to the engineers inside your organization.
My job is to be a credible technical voice to customers, but it is also to be an accurate representation of customer needs and wants to the engineers who are building the products. I go out and do customer facing talks and live streams on Twitch, and use social media to talk about my company's products, but then I listen to these customers when they come up to talk to me after my conference talks, or when they send me messages on social media.
I take those learnings and go into product management meetings and tell the PM's about customer problems, and I write proposals for things to build to solve customer problems. I influence the customers to use my company's products and use them better, but then I also influence the product roadmap to have the right things being built for the customers, based on what they want.
So dev rel / dev advocates work in both directions. At its best it is a bidirectional channel that translates internal knowledge into external awareness, and external complaints and issues into internal awareness and solutions.
I think DevRel should sit in a separate org neither marketing or product but be a peer to both.
When DevRel sits in product it is easy to get carried away with whatever narrative the product managers are pushing. Part of being a good advocate for developers is being able to step back and look at something in the existing ecosystem. Does it actually solve problems that users have? Is it usable? Does it integrate well with existing workflows and tools?
When DevRel sits in marketing or sales it often feels like you are a prize hog being pulled into sales conversations to add credibility to something that probably shouldn't have credibility to begin with.
In my opinion, the primary role of DevRel is story telling and narrative. I use narratives to explain to product teams how users currently work and how their product fits into a larger ecosystem. I use stories to help them understand bugs and design issues in context. And I use story/narrative to help external developers see how a given product can solve problems or pain points they have.
Sometimes I tell that story with words but I'm just as likely to tell that story with code. It is much harder to dismiss a bug when you can see the horrible contortions it requires you to go through in the code.
I'd say that the most effective DevRel folks do a bit of all three: marketing, engineering, and product. The marketing aspect has already been discussed in great detail, so I'll address the other two areas.
If you aren't a practitioner of some sort you usually can't speak credibly on the topic of the product. If all I knew was the marketing lines about a product that doesn't build credibility. I maintain my engineering credibility by building at least one non trivial application using my company's products every year. This serves both a marketing purpose and community outreach purpose by serving as a real world open source example for developers to learn from. Often my example app is one of the first open source applications out there demonstrating how to use a new technology, and many people learn from it. This also serves a product purpose by giving me first hand experience with pain points that customers face. It also helps me find places where there are confusing things that need to be better documented, often leading directly to me contributing docs or blog posts about the product to fill those gaps.
Also on the engineering side when I write a public facing blogpost about a new product from AWS, it is always written based on my first hand, personal experience using the product in preview internally. Often in the early days of using a product that hasn't been released yet I find bugs and user experience issues that need to be fixed before it goes live. There is no way I'm going to write an article or do marketing for a broken product that doesn't work when I test it out. So there is a bit of engineering QA in the mix for a dev advocate as well.
On the product angle one of the best ways to get a deep, long lasting credibility with your audience is to listen to them and get their problems fixed. I love being able to go back to folks I've chatted with in the past and say "hey we just released a feature to solve that problem you told me about". Additionally some of my favorite products that I've done marketing for are things that I personally pushed for getting funded and built. The marketing message is so much more genuine and meaningful when its something that you were involved in designing. I don't get any satisfaction from marketing something I don't believe in, but when I get to tell customers about a product that I had a hand in designing and influencing the product direction of, then its a genuine recommendation and I think that comes through to the audience as well.
In the two DevReal roles I've had, there is some aspect of marketing and customer support, but not really "sales". For me, it's been a hybrid engineering and product role, where talking to the users helps surface bugs as well as ideas for new features.
So much less "technical sales" than "developer whose role includes public interaction"
I've been a dev advocate since 2008ish and before that worked in pre-sales (mostly crafting custom demos and prototypes for prospects and existing customers). In my early days as a dev advocate, I was hired into marketing and most of the work was public facing (blogs and conference talks). But then that role soon moved into an official Dev Rel org where we did mostly 5 things:
1. Build and maintain a plugin SDK and integration framework
2. Help write docs and guides (we had a dedicated tech writer in our dev rel org)
3. Do public facing stuff: blogs, conference talks, participate in hackathons, etc.
4. Plan and host events: company developer conference, hackathons, meetups, etc.
5. Write code... could be anything... sample code, tech blogs, integrations, bug fixes to product, new features in product, etc.
It was a hard job in the early days -- lots of context switching. Those who were well suited for it were devs who communicated well, knew how to tell a story, and loved the hustle.
In the past several years, I've seen this role evolve a bit more to be what the author of the article describes: basically dev advos with a social status who speak at conferences a lot. While I think that's an important aspect of a Dev Rel org, I think a Dev Rel org should have a healthy balance of people who are good at the public facing stuff and those who are highly technical and can get in the weeds with other developers. A Dev Rel org with that combo can deliver high-level and visionary stories to the public and also dive deep into the tech with any developer/architect in the industry.
With the pandemic, we're having to reinvent ourselves yet again and trying to figure out how to get the best signal-to-noise ratio with our audience. A lot of people are trying new things out. For us, we're diving into video a bit more as a medium. I'm not entirely sure how good virtual confs are going to fair in the next year, but from what I've seen recently, I'm not optimistic about the platform.
Other roles we've seen ourselves optimizing in lately... being a more useful resource internally especially for our sales organization -- helping them craft a better story, providing better demos that are reusable, writing long form guides on the stuff you probably wouldn't have thought to write about in the past.
i'll echo the other devrel people in this thread and note that this blogpost actually does not do a very good job of explaining what devrels do and therefore why companies have them.
there are very successful devrels with no twitter following. the blogpost also conveniently omits the importance of content marketing to draw inbound interest which works even without the devrel having a strong personal brand or rolodex.
So a sales like role, but with someone with a bit deeper technical knowledge who can speak to not just the nuts and bolts of features, but talk to the customer about what they do with tech, maybe how, and etc?
Seems like a role that I've seen done by sales, sales engineers, product managers, etc.
I've always described what I do as marketing for developers at the end of the day. Developers typically have the thickest bullshit shields and know immediately when they are interacting with someone that isn't technically credible - say at a conference expo booth.
I've personally had very little involvement with sales over the years and have mostly operated at the top of the funnel. Most (from my experience) DevRel teams actually sit under a marketing org.
Tech Sales is focused on closing accounts, whereas Dev Rels do things like teaching developers how to use a company's APIs at hackathons. It's like the difference between conversion marketing and brand advertising.
Like others, I wasn't familiar with the term, but once you'd explained, I know exactly the type you're talking about. Having worked in consultancy for several years, these people are fairly common. They attend meetings with new clients, hobknob at events, and form the bulk of the companies social output.
In my mind, they exist to win business, and provide confidence when clients need it.
"Hello fellow developers! I myself am a developer, just like you! I was just developing something the other day in fact, when I came across this amazing product..."
As long as they keep handing out the swag people will put up with them, but noone likes being evangelized at. They are the modern day snake oil salesmen, err, people.
In my (somewhat cynical) opinion, formed from my experience as a business owner who has been targeted by countless "developer relations" types, the greatest value that they provide to their organizations is getting free/cheap developer labor for testing and implementing various API's/SDK's
One thing that prevents people from working remotely in other countries is the differences between laws, regulations, and certification/licensing practices.
A doctor that can work in India might not carry a US medical license. A lawyer that practices in India might not have passed the California Bar.
These protectionist regulations cover a wide variety of jobs and industries, and remain a blocker even when robots could be on site, and controlled by remote workers.
DevRel here - my formal designation is Developer Relations Engineer. Much of my job comprises of what di's comment [1] speculates as an Evangelist and Advocate combined. I am a part of the hiring panel and describe the work opportunity as follows:
1. a third of the time, you'd be speaking to users (of course, typically developers) to help them understand and integrate with our technology, find solutions and debug issues for them, and make the most out of our stack - this could be thought of as a hybrid between a developer support and a customer success role, where to be able to manage customer success you need to understand a developers problems / persona / psyche.
2. another third of the time, you'll build internal as well as external tooling, and documentation etc around our core offerings - be it SDKs / packages for our APIs, sample / demo apps, quick hacks to use the API from a Google sheet plugin, or dirty dashboards to dig in a particular user metric that is in focus for the month from somewhere across 4 table joins.
3. and the last third would be dedicated to providing proper product and engineering feedback - I feel this to be the most important part of my work, which is to pass on, debate on and participate in well-structured feedback as a consequence of being in direct touch with the customers. This feedback is: a) highly relevant coming directly from the user's pain points but via the value add of a filter from someone who understands the product's proposition and ideology, and b) actionable, as it simply is not "could we provide feature X" or "there is something wrong in module Y" but more like "could we decouple this process from that API call so that users could use feature X in so and so way" and "module Y at step bla is looking for a non-existent entry in the db - most likely cos this certain flow might have triggered it, how quickly can we fix this".
(we also want to expand on community building, events & talks and such, but don't find the right time or motivation to do so, being an early stage startup, although this should not really be an excuse for maybe not putting in the right effort)
I have been in this role formally for only 4 months out of my 6+ working years, but have always felt this coming. Main reasons I attribute to this:
1. I have discovered a wide variety of fickle interests - this area of work covers understanding business(es), being up-to-date on technology (at least the internal frameworks and architecture), relationship building, regulatory knowledge (since I work in a heavily regulated domain), product thinking, and a lot of other things.
2. I suffer from short attention span - not ADHD but it is super simple to distract me, so I haven't been able to find my deep work vibe yet and this job allows for that.
3. I have worked as a developer and didn't feel I was "cut for it" - yes, I said it. Deep tech does not interest me, I've never worked with a front-end JS framework like React or Angular or anything of that sort, and no, I do not aspire to be a data scientist or principal architect someday. All of those are very valuable works and there are a lot more people out there other than me who love it more than I do and certainly do it better than me. So why not leave them to it and I do what I do best - which is to talk to people about - "why" should you use this offering, "what" to do to make it work with your system and not to figure out "how" exactly. Nonetheless, it excites me and I keep reading up on advancements and certain concepts of languages / technologies. Just like I do for a hobby - like board games for example - I play, can teach and sometimes think about them but I'm not a designer or researcher. (Boy, if only we had board-gamer relations as a job, which also paid as well as a tech job...)
Particular disadvantages I feel:
1. I am not a multi tasker - it is not easy at all for me to run parallel threads, which is very much required: partly as a "job hazard" and partly because I'm also not good at time management (refer point 2 above).
To add to this, I have very minimal and unrelated to job Twitter following. I generally write very less on the internet and not even at work (although I want to increase this particular output from myself). And I haven't had a speaking engagement either.
So these are not a part of or prerequisite to the job, but definitely make for a good addition.
If you have available time, start doing the job. Write, teach, talk, stream, etc. about technology that you like. Grow your communication skills and audiences. Then when a company you feel passionate opens up a DevRel role, you'll have your 'resume' ready to go.
You know how they took operations, re-christened it "DevOps", and made it the responsibility of the dev team without commensurate increase in hiring or pay or education?
account management seems different. the developer relations folks have more purple hair and technical skills.
account managers are suits who come in at the start to sign the contract, and again later when everyone involved has fucked up to try and salvage the business relationship.
Not OP, but I think it’s a general observation that a lot of the high visibility devrel folks tend to have fairly colorful personalities. This often extends to hair color. Charity Majors would be a good example of this kind of person (though she’s not in devrel).
So yes, alternative. Colorful hair, lots of visible tattoos, etc. A contrast to the sales folks, who are typically the opposite.
I think this article is incomplete without mentioning oppressive IP laws that enable copyright to basically support multi-generational legacies. Patents: I'm not sure how patents are extended past their 17 year limit but if they are, it's the same thing.
"Intangible assets" are more or less propped up by these laws. Would Microsoft be a $250bn company if copyright on Windows and Office only lasted 10 years?
You can't count on most physical assets outlasting the typical copyright term. So this is where all the value and power is moving to because it's literally protected by law and never decays.
I think the article does a good job describing what devrel looks like at companies that are smart about selling to the new “tech business world” which is desperate for a way to measure the technical credibility of potential vendors.
But what’s more interesting from someone who knows devrel because I’ve worked in it for 7 years, is that at a more general level it’s just a communication layer that a business can have with an audience or a persona(in this case developers), that is growing ever more important. Whether you’re a platform (google Apple) and need more devs making stuff within your ecosystem, or you’re not selling to developers but you need technical integrations by third parties to enhance The value prop of your product, or you’re ACTUALLY selling directly to developers and trying to expand their mental model of what is possible with the low code tooling available today and why they can and should trust it.
It’s a wide and interesting world in which almost every company is becoming a software company, and almost none of these companies have any idea how to communicate with developers or what they care about.
You’re right that devrel is like a pre-sales role somewhat, but we all know developers are the hardest group to sell to in history, who else could more easily go find a free open source solution or just make it themselves?? You have to be able to communicate about the pros and cons of technology in an honest and coherent way, and that is what Devrel is all about to me.