What I Thought DevRel Was vs. What It Actually Is (A Mentee's Honest Take)
Source: Dev.to
A few weeks ago, if you’d asked me what “DevRel” stood for, I would’ve squinted, smiled, and given you a confident‑sounding non‑answer. Today I’m in a DevRel mentorship program, so let me close that knowledge gap for you the way it got closed for me.
The “Before”: What I Thought DevRel Was
When I first heard the term Developer Relations (DevRel), my brain did what most brains do—it grabbed the two words and built a half‑decent guess. Not quite.
I also assumed it was basically being a tech influencer: someone who posts on Twitter/X, shows up at events with a branded hoodie, and tells everyone how amazing their company’s product is. Half marketing, half cheerleader.
The “During”: What DevRel Actually Is
DevRel is the bridge between a company that builds tools for developers and the developers who actually use those tools.
Think of it like this: imagine a company builds a really powerful kitchen appliance, but only professional chefs can figure out how to use it. That appliance will flop—not because it’s bad, but because nobody knows how to get value out of it. DevRel is the team that writes the cookbook, hosts the cooking class, listens to chefs complain about the buttons, and then walks back to the engineers and says, “Hey, can we move this button?”
In tech, that “appliance” is usually an API, an SDK, or a developer tool. The “chefs” are software developers around the world. DevRel is the function that makes sure the two actually connect.
“You can’t honestly bridge two worlds if you only live in one of them. If you’ve never written code, you don’t know which parts of a product are confusing, broken, or magical. You can talk to developers, but you can’t speak with them.” — Mentor, first session
The Three Cs of DevRel
- Code – DevRel folks build things. They use the product themselves, ship demo apps, write sample code, and feel the same friction real developers feel. This is how they earn the right to speak.
- Content – They turn the product into something learnable: documentation, tutorials, blog posts, videos, livestreams, conference talks. If you’ve ever Googled “how to do X with [tool]” and landed on a guide that actually made sense, that was probably DevRel’s work.
- Community – They show up where developers gather: hackathons, meetups, conferences (e.g., DevFest Lagos), Discord servers, Twitter/X Spaces. They’re not there to sell; they’re there to listen, teach, and build genuine relationships.
The “After”: How I’m Actually Getting Started
I won’t pretend I’ve figured this out. I’m at the very beginning, having been accepted into a mentorship program. Here’s what “getting started” looks like in practice:
- Become a developer first – Not optional. Before I can advocate for developers, I need to be one, even at a beginner level. Code is the foundation that everything else stands on.
- Learn from people already doing it – A few I’m watching closely (follow their blogs, talks, and open‑source contributions).
- Put myself out there – This blog post is exactly that. Writing in public is one of the best ways to practice content, learn to explain, and invite feedback at the same time. (This is me practising.)
A Quick Word on Career Paths
DevRel isn’t a single job; it’s a family of roles. You can specialize as a:
- Developer Advocate
- Technical Writer
- Community Manager
- Developer Experience (DX) Engineer
- DevRel Engineer
Some roles lean more toward code, some toward content, and some toward people. There’s no single ladder, which can be intimidating at first but becomes freeing once you accept it.
So… What Do You Take From This?
If you’re a fellow developer wondering whether DevRel could be a fit, it is—if you like teaching and don’t mind being visible.
This post is part of my journey through the DX mentorship program. I’ll be writing more as I learn. Feel free to follow along, or share your thoughts in the comments about what you thought DevRel was before reading this. I’m collecting answers! 🥑