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.
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.)
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.
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 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.
> 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!
In my bubble DevRels are more of a thing than most people's.
I have never heard of 'Dev Reels' either!
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.
Where do you think DevRel should sit ?
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.
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.
So much less "technical sales" than "developer whose role includes public interaction"
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.
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.
Seems like a role that I've seen done by sales, sales engineers, product managers, etc.
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.
In my mind, they exist to win business, and provide confidence when clients need it.
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.
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.
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.
BUT. After almost 10 years without social media or putting out content, I do feel a very relevant impostor syndrome.
Clickbait and Medium ruined blogging for me (as a reader).
But I should start my own personal blog anyways i guess..
That, but for account management.
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.
I've never heard the term "purple hair" before. Is that literally meaning like... more alternative?
"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.
