As a software engineer, my comfort zone is a dark terminal, a green test suite, and a predictable compiler. Compilers are great. They don't have feelings, and they tell you exactly why they are mad at you.
So, naturally, I decided to look into Developer Relations (DevRel).
If you have ever thought about trading your Jira tickets for developer advocacy, you have probably opened a few job descriptions (JDs) and felt immediate whiplash. I spent the last week auditing modern DevRel JDs to see what it actually takes to bridge the gap.
Here is the breakdown of what I found, minus the corporate buzzwords.
1. The Catalyst: Why look outside the IDE?
Let’s be honest. Building features is fun, but sometimes you realize you enjoy talking about the technology just as much as writing it. I noticed my favorite part of a sprint was explaining a complex system architecture to a junior developer or writing the internal documentation. That spark is usually the first sign of a DevRel pivot.
2. The Tech Stack vs. The People Stack
When an engineer reads a standard SWE description, we look for languages and frameworks. When you look at a DevRel description, the requirements look a bit different:
What we expect: "Must have 5 years of production Python experience."
The reality: "Must be able to build a quick API demo, write a tutorial about it, and present it without sweating through your shirt."
The technical depth is still required, but the output shifts from production-grade code to educational collateral. You aren't shipping enterprise software; you are shipping understanding.
3. The "Aha!" Moment
The biggest takeaway from analyzing these roles is that DevRel is not a marketing job masquerading as engineering. It is a translation layer.
Your job is to look at a product through a developer's eyes, find where it hurts, and help them fix it. You are an engineer whose primary debugging tool is empathy and communication, rather than a linter.
Image credits: designed by Freepik-Magnific.com
To keep myself accountable, I did a quick inventory of my own toolkit.
What transfers immediately:
The technical foundation: Knowing how developer tools work because I use them daily.
Empathy: I know exactly what makes a developer close a tab in frustration (looking at you, broken documentation).
The immediate gaps to bridge:
Public proof of work: It is one thing to write clean code for a private repository. It is another thing to write an engaging public article or record a video walkthrough that keeps a developer's attention for more than 30 seconds.
The next step:
Instead of just waiting until I magically feel ready, I am treating this transition like a engineering sprint. I found some roadmaps, joined the right communities, and I am going to build my way into the role by doing the actual work in public.
If you are an engineer who has successfully made the jump, or if you are currently staring at the same JDs I am, let me know what your biggest roadblock has been!
Top comments (0)