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.

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.

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 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.

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.

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

Check out DevRelCon online conference taking place right now: 2020.devrel.net

I think it legitimizes a company and shows that they have a great developer team that can communicate with the outside world

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.

[1]: https://news.ycombinator.com/item?id=23908042

if I want to be a DevRel, what should I do?

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?

That, but for account management.

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.

This sounds like you sit closer to product. But what about those who sit in Marketing or Engineering

Where do you think DevRel should sit ?