What is DevRel?
Created on .
Read in 3 minutes.
There was a short discussion about DevRel that got me thinking about my role and what I do as DevRel. I removed the link to Birdsite. It was a meme stating:
DevRel is marketing
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 is 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.
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.
Next
Automatically Approving and Merging Dependabot Pull Requests
Previous
Drop Bag Plan for Cocodona 250
Related
- WMS Layer on Google Maps
- Drop Bag Plan for Cocodona 250
- Automatically Archiving Dependabot and Semantic Release Emails
- Google Maps React Wrapper
- GitHub Workflow to Sync Branches