Is DevRel over? Is it more needed than ever? Or, is it somewhere in between?
This week I interviewed "Danger" Keith Casey from Pangea. Previously at elite DevTools, Okta, ngrok and Twilio Keith wrote two spicy pieces on DevRel recently:
I'll quote from these articles extensively, as well as the Scaling DevTools interview below.
Let's go!
### Keith has seen DevRel work really well
Done well, DevRel is immensely valuable
Early DevRel at Twilio (2011-2013) was highly effective. 75% of inbound leads mentioned meeting a developer evangelist and 50% could name the specific evangelist they met.
DevRels at Twilio typically had 8-10 years of development experience plus presentation skills.
Their focus was on demonstrating how to build things and solve problems - which they could do well because of their deep experiences.
They were trusted sources and could relate to problems and advise on specifics.
DevRel has become less technical
Keith believes DevRel - generally - has become less focused on being developers and he believes this makes DevRel less effective and created misaligned incentives.
In ancient times, DevRel were “developer evangelists” and had years experience as a developer. They had (emotional) bruises from shipping code and making hard tradeoffs.
The best DevRel people had a following via a blog, youtube, books, or the like. Unfortunately, most current DevRel people don’t have any of the above. They may be strong marketers but they’ve never shipped code. They may have a computer science degree but they don’t have experience. Frankly, they haven’t put in the reps. They could address but it takes time and effort but few current devrel people are willing to do that.
### DevRel has misaligned incentives
DevRel's resistance to metrics which are directly aligned to business goals has created misaligned incentives.
He cites as an example the shift towards “soft skills” topics at conferences rather than technical content.
In Keith's mind, this has meant misaligned incentives. The old metric might have been number of conference talks given, and this might have worked well when the topic was something deeply technical and related to the DevTool.
Many DevRel people started making their name with non-technical and non-dayjob-related topics. Therefore, your technical deep dive into your problem space and your colleague’s talk on [imposter syndrome, mental health, finding your place in tech] counted exactly the same. When your company is paying the bills, your job is to build their brand, not yours. But more to the point: If Marketing can’t measure your contribution, you don’t fit into their budget.
As a side note: Keith also mentioned that he avoids all the intro 101 talks at conferences because they aren't usually steeped in real world experiences. I have related gripe with conferences. At a recent API conference I went to, most talks were very light on details and very product-y/marketing-y. I have a strong preference for hearing the experiences of core engineers instead.
So what.. to do...
If you're thinking about hiring DevRel, you can recreate a lot of its functions without hiring a full time person.
Or, you may want to double down on a more Twilio-like DevRel org
Or if you want to completely re-think how you do DevRel, Keith believes that Product Marketing is a natural fit to retain employees:
At its most fundamental level, Product Marketing is learning about your customers, being able to describe their problems, understanding how your product solves those problems, and how to get your product in front of those customers.
DevRel can shine by leveraging their skills:
building relationships with customers to talk about their challenges
telling stories with language that is descriptive for customers and their industry
talking technical details and sketching out ideas, solutions, and building compelling demos
writing guides, blog posts, competitive briefs, and thought leadership pieces about your product, the space, and how it comes together.
Of all the places where DevRel can go, Product Marketing is the cleanest match where you can leverage your existing skills and have metrics that are similar enough to feel natural.
Alternatively, Keith said on the Scaling DevTools podcast that sales engineering can sometimes be a good fit as it's very valuable to sales teams and difficult to hire for.
This is a complex topic, I recommend reading Keith's articles and listening to our interview for a lot more context.