It's a role for a techie with good communication skills. Some are more marketing and some are more technical (I lean towards the latter, and think the former are pretty ineffective). A good dev advocate/tech evangelist/dev relations person helps external developers learn about a company's platform (APIs, SDKs, etc.), and also helps internal developers and product managers learn what sort of issues or ideas devs have.
The job itself usually entails speaking at conferences or meetups, videos online, blog posts/tweets, sample projects, sales support/white glove assistance to big customers and general enthusiasm. When asked questions, a dev advocate should either have the answer (because they know the platform inside and out) or know where to find it. They also should have access to the internal decision makers to help them plan new features and opportunities. In large organizations, you might even speak at internal events, helping the left hand understand what the right is doing.
Because it's not a dev position or pure marketing, it's an easy position to dismiss or misunderstand ("I deal with the goddamn customers so engineers don't have to. I'm a people person, dammit!!" [1]), though as time goes by this is becoming less the case as tech companies realize how important they can be.
I've worked with Developer Advocates and have been one myself!
Developer Advocates usually work in organizations where reaching developers, data scientists, etc is crucial. Some high level categories with examples include:
- developer tooling: Hashicorp (Terraform, Vagrant, etc), Docker (Docker), CI tools at large
- business ops, but you may need a developer to incorporate: Stripe, Cal.com, FiveTran, Segment
- open source software: Apache Superset, Apache Airflow, PyTorch, Bytewax.io, Apache Kafka, and hundreds others that have 1 or more commercial entities supporting adoption & success of those open source projects
The day to day:
Depending on the role and company, Developer Advocates (or Developer / Tech Evangelists) can help write blog posts that explain technical concepts (https://www.bytewax.io/blog/streaming-vs-batch-with-github) or illustrate cool use cases of the tool (https://docs.databricks.com/getting-started/tutorials/index....), support the relevant communities for the tool or open source project (often these are in Slack, Discord, or Discourse), organize meetups and meetup talks, and / or give external conference talks (think AWS Summit, Snowflake Summit, etc).
Some Developer Advocates also help with documentation, writing SDK / partner integrations, or specific drivers to enable partnerships (e.g. a database driver).
Reporting:
DevRel usually reports into either Engineering, Product, Marketing, or sometimes a dedicated DevRel / Community team (JetBrains has a VP of DevRel for example). They can report to Sales or Operations too, but this is rarer.
Accountability:
Usually some type of growth or success metric. Swyx wrote about 'monthly active developers' as one possible metric (https://www.swyx.io/measuring-devrel)
I've hired, worked with, and managed Dev Advocates at different open source software companies (working with Apache CouchDB, Apache Flink, and projects). They are really valuable and are an important part of awareness raising, user adoption, user retention, and technical recruiting.
A few thoughts:
1 - I think it's good to focus some of them on developer (user) acquisition and some on developer retention. The former are more evangelical - social, talks, demos, content that attracts new users. The latter focus on the user experience (UX feedback, docs, issue resolution, community support, how-to vids, etc.) to make sure new users become and remain active with the software. Both are critical to adoption and growing word of mouth.
2 - Dev Advocates can own the open source contributor experience! Recruiting, welcoming, recognizing new contributors is a great thing to see happen. It's an easy thing to overlook with companies placing so much emphasis on user acquisition. It's important for community goodwill building and expanding the network of external advocates.
3 - Make sure the executive team understands the breadth of Dev Advocate responsibilities. It can get tense if they only expect talks and blog posts.
The name for this role should be <product> advocate. They are generally not a developer that takes part in the SDLC.
If you argue that they are.. then what happens when a bug comes in and the <product> advocate has conference talk they need to do. Who works on the bug? A developer.
It’s a product marketing role to attract technical users.
Imagine a company that makes software that’s not sexy like tooling or core infrastructure.
The Developer Advocate goal is to raise awareness about the product by being a community presence. They might be involved in github issues and pull requests. They will be a liaison between the core dev team and consumers. They will go to conferences and show off some new v4 of an sdk and its new features. They might write articles or make videos.
Never worked with one but knew someone who went on to do this.
Being a devil's advocate means that you just oppose something for the sake of argument. You will find many such people here on HN. Keep reading comments on HN and you will get all the first hand information you need.
It's a role for a techie with good communication skills. Some are more marketing and some are more technical (I lean towards the latter, and think the former are pretty ineffective). A good dev advocate/tech evangelist/dev relations person helps external developers learn about a company's platform (APIs, SDKs, etc.), and also helps internal developers and product managers learn what sort of issues or ideas devs have.
The job itself usually entails speaking at conferences or meetups, videos online, blog posts/tweets, sample projects, sales support/white glove assistance to big customers and general enthusiasm. When asked questions, a dev advocate should either have the answer (because they know the platform inside and out) or know where to find it. They also should have access to the internal decision makers to help them plan new features and opportunities. In large organizations, you might even speak at internal events, helping the left hand understand what the right is doing.
Because it's not a dev position or pure marketing, it's an easy position to dismiss or misunderstand ("I deal with the goddamn customers so engineers don't have to. I'm a people person, dammit!!" [1]), though as time goes by this is becoming less the case as tech companies realize how important they can be.
1. https://youtu.be/fcIMIyQnOso