Justin PoehneltThere was a short discussion about DevRel on Twitter that got me thinking about my role and what I do as DevRel.
Let’s do this! pic.twitter.com/0cTDWDgKCZ
— Corey Quinn (@QuinnyPig) May 11, 2022
Some aspects of developer relations can certainly be considered marketing, but I think it can and should be far more.
To me, DevRel is a lot things: marketing, engineering, product management, and support.
Background
I have a background as a SWE, but joined Google as a Developer Programs Engineer in 2019. At that time there were two different roles in the DevRel ladder at Google: Developer Programs Engineer and Developer Advocate. The former was more engineering focused, and the latter was more marketing focused. These were eventually merged into a single role, Developer Relations Engineer, but there is still a spectrum of work and responsibilities determined by individual interests and team needs.
What is DevRel?
I’m going to define developer relations by what I do in my work.
Daily work
- Write and maintain open source (client libraries, extensions, etc) -> DevRel is Engineering
- Fix and expose interfaces in the product (TypeScript Typings, exporting Errors, etc) -> DevRel is Engineering
- Interact with developers on Discord, StackOverflow, GitHub, etc -> DevRel is Support
- Provide feedback on API design, use cases, etc -> DevRel is Product Management
Weekly work
- Produce content (blogs, videos, tweets, etc) -> DevRel is Marketing
- Capture friction logs and other proposals based upon a deep understanding of the dev ecosystem -> DevRel is Product
- Write tutorials, samples, documentation -> DevRel is Tech Writing
Sometimes it's about bringing knowledge of the general developer ecosystem back to pm/eng. For example, identifying challenges in using modern web frameworks for a 10+ year old JS product. This requires experience beyond what pm has and what eng is often familiar with.
— Justin Poehnelt (@jpoehnelt) May 11, 2022
Staying technical
Basically, I’m a generalist that biases to the engineering side of DevRel and I mostly act in a software engineering role.
- Adding support for TypeScript to Google Maps Platform
- Taking a design for adding JavaScript Promises to the public interface from PRD to Design Doc to Implementation to Marketing
- Interacting with the open source community to build extensions, component libraries, etc.
- Writing open source that bridges the gap between the product and developer ecosystem (@googlemaps/js-api-loader, @googlemaps/react-wrapper).
- Writing a plugin using WebGL to extends the functionality of Google Maps Platform.
My favorite role
DevRel is my favorite role to date because it is a little bit of everything and is always exciting; allowing me to push the boundaries of current technologies and explore the developer experience. The hardest part is turning that into an outcome that has an impact; it will vary by in the moment, it may be marketing or it could be engineering or both!
The most frustrating part is being perpetually under-resourced and seeing the empathy I have for the developer experience not shared across the organization. In these cases, I turn to open source to find my footing and motivation, by independently making the developer experience better and finding my own creativity and fulfillment.
For me, I still express my creativity through engineering and in my mind, DevRel, is much more than marketing.
