Why Do We Have Dev Rels Now?

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.

I already have 30k followers from a prior project, but can't rename the handle without losing verified lol

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.

Again this is not a joke. More information written by other Developer Advocates.

https://blog.usejournal.com/the-birth-of-developer-avocados-...

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