[NathanKP]

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.

[viejoqueso]

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 ?

[the_thagomizer]

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.

[NathanKP]

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.