Back in 2018, I wrote a post that tried to explain what Developer Advocacy is and why it matters. At the time, I was working at Microsoft, flying around the world to speak at conferences, and helping teams figure out how to connect better with the developers they were trying to serve.
It resonated, probably because Developer Advocacy still felt like a relatively new thing in many organizations. People were still trying to define it, justify it, structure it.
A lot of that’s changed. (Some of it dramatically. Team structures, reporting lines, expectations around ROI.) And a lot hasn’t. We’re still here to serve developers. And we’re still doing the messy, meaningful work of bridging the gap between what a company thinks developers want and what developers actually need.
So I’m revisiting this post now, not just to dust it off and update a few terms, but to reflect on how the role has evolved, where it’s headed, and how we keep showing up for our communities in a world that looks very different than it did in 2018.
Developer Advocacy in a Nutshell
Let’s start with the basics. You might hear this role called Developer Relations, DevRel, Developer Advocacy, or Evangelism. The names vary depending on the company or team. But at its core, Developer Advocacy is about serving developers. Period.
We are the connective tissue between the people who build software and the people who use it. We gather feedback, surface pain points, advocate for improvements, and translate between worlds. Sometimes we’re translating business priorities into developer needs. Sometimes we’re translating product decisions into accessible, actionable content. Sometimes we’re just asking the questions no one else thought to ask.
In the simplest terms: we represent the voice of the developer inside the organization, and we represent the product to the developer community outside of it.
But even that’s an oversimplification. Because today, the only way we can do both, advocate for developers and drive business value, is by building and maintaining a very specific kind of trust: credibility with the business, and authenticity with the community.
The company trusts us because we have credibility with developers. We know the ecosystem. We know what matters and what doesn’t. We can spot early signals of adoption or friction that product teams might miss.
Developers trust us because we show up authentically. We don’t just parrot marketing copy (or at least we shouldn’t). We tell the truth about what works, what doesn’t, what’s rough around the edges. We advocate for fixes when things break. We don’t pretend everything is perfect and that honesty is what earns long-term trust.
That double trust, inward and outward, is the backbone of Developer Advocacy. Lose it on either side, and the whole system breaks down.
And all of that is layered onto a job that touches nearly everything: product development, marketing strategy, developer education, support, community building. Today’s DevRel teams don’t just drop into one department, we stretch across them. Some DevRel orgs report into product, others into marketing, others directly to executives. This breadth is why the lone evangelist model, one person expected to do it all, is fading out and being replaced by more cross-functional, collaborative teams: content specialists, engineers, community managers, programs leads, all working together to build better developer experiences.
We’re Still Developers (Even if We’re Not Coding Full Time)
One misconception that’s never really gone away is that Developer Advocates aren’t “real” developers. That we’re just here to make videos or run social accounts or give talks. That we’re glorified marketers with GitHub profiles.
The reality is, and has always been, more complicated than that.
Most Developer Advocates I know have written production code. We’ve shipped features, debugged disasters at 2 a.m., refactored tangled APIs, and fought our way through broken docs like everyone else. We’ve been in the trenches. Some of us still maintain open source projects with thousands of users. Others are the go-to person in their org when it comes to new frameworks or integrations. Technical credibility isn’t optional in this work, it’s foundational.
That doesn’t mean we spend our weeks buried in tickets or sprints. And that’s okay. In fact, our value often comes because we’re not too close to the implementation. We can see the experience from a developer’s point of view. We notice when onboarding is confusing, when SDKs are missing critical examples, when the documentation skips the “hard but honest” parts. We bring that feedback to the teams that can fix it and we help build bridges to make sure it doesn’t happen again.
There’s still some gatekeeping in tech around what it means to be “technical,” especially when you step outside the bounds of shipping code five days a week. But the bar for this work isn’t just technical expertise, it’s technical empathy. Can you understand the developer’s pain point? Can you solve for it in a way that makes someone’s job easier? That’s what earns trust. That’s what makes you credible.
And it’s why DevRel salaries and roles have started to reflect that complexity. And we’re seeing more career paths open up: staff-level advocates, engineering leads within DevRel, even VP roles at major developer platforms. That kind of progression tells me the industry is starting to get it: you don’t have to be writing prod code full time to be building serious value.
Learning Never Stops (Especially Now)
If you’re in DevRel, you get very comfortable with not knowing things. We spend a huge chunk of our time learning new technologies, new APIs, new mental models. That was true in 2018, and it’s even more true now.
The difference is the speed. The pace of change in our industry used to feel fast. Now it feels borderline unmanageable. The rise of generative AI has changed not only how developers build and ship software, but how they even think about solving problems. Everything from debugging to scaffolding full applications has been accelerated or abstracted. And because so many of us sit close to the product, we’re also among the first to field questions like: “How do I integrate this responsibly?” “How do I explain this to my team?” “Why does the LLM keep hallucinating this error?”
In 2025, being a Developer Advocate doesn’t just mean staying up-to-date on frameworks or cloud tooling. It means learning how to prompt effectively. It means understanding when to trust an AI-generated response and when to stop and say, “Wait, this isn’t right.” It means knowing how to teach new mental models to teams who’ve built their careers around very different workflows. And it means navigating new questions around authorship, ownership, and ethics.
But it’s not just what we learn, it’s how we learn.
One of the most valuable shifts in Developer Advocacy over the last few years is the growing comfort with learning in the open.
We don’t have to wait until we’ve built the perfect end-to-end polished scenario before we share something. We don’t have to present ourselves as experts who already know everything. In fact, some of the most powerful moments come when we show the messy middle, when we say, “I’m figuring this out too. Here’s what I’m learning. Here’s where I’m stuck. Let’s solve it together.”
This kind of openness isn’t just refreshing. It’s necessary.
Developers are navigating an environment that’s changing faster than documentation can keep up. If we pretend we have it all figured out, we lose credibility. If we’re honest about the learning process, if we invite people into it, we build trust.
And in a world where AI generated content is on the rise, authentic, thoughtful learning, the kind that shows real context, judgment, and nuance, matters more than ever.
It’s overwhelming at times. But it’s also what keeps the work alive. Every new tool, every paradigm shift, every breaking change, it all gives us an opportunity to make something clearer, simpler, better than it was before. We learn so we can teach. We teach so others can build. And we build so others feel empowered to do the same.
The Role of Travel Has Changed
This is one of the biggest shifts since I first wrote about DevRel.
In 2018, travel was the heartbeat of Developer Advocacy. We were on planes constantly. If you were lucky, your company sent you to conferences around the world. You gave talks, led workshops, had late-night conversations over terrible hotel coffee, and built relationships in real life.
Then the world shut down. And when things opened back up, the travel didn’t fully return, not for most of us.
Budgets shifted. Carbon footprints became part of the conversation. And in the meantime, we got better, a lot better, at connecting with developers online. We launched YouTube channels, Discord servers, virtual office hours, async developer surveys, and regional community calls. We built new rhythms for connection that didn’t require a boarding pass.
In many ways, it’s made DevRel more inclusive. People who couldn’t fly, due to family care, finances, disabilities, or immigration status, are now leading communities, running events, and contributing in big ways that wouldn’t have been possible in the old travel-first model.
But something has been lost too.
We haven’t yet recreated the hallway track, the serendipitous, unplanned conversations that start over coffee and turn into a product idea, or a conference proposal, or a job offer six months later. We haven’t figured out how to replace that moment when someone walks up after a talk and says, “That made me feel seen.”
I’m not sure we can fully recreate that online. And I don’t think we need to go back to flying 200,000 miles a year to make Developer Advocacy “real” again. But I do think we need to keep investing in human connection, the slow, relationship-building kind. Because the tech might change, but this is still a people job. And people need to feel connected to feel seen.
Let’s Talk About the Moment We’re In
If you’re reading this while navigating a layoff, whether it’s your own or someone close to you, I want to acknowledge that up front. You’re not imagining it. There are a lot of DevRel folks on the market right now. We’re in one of those hard cycles again.
And it’s not because this work isn’t valuable. It’s because we’re still fighting for the rest of the industry to fully understand how to invest in it sustainably. DevRel often lives at the edges of a company’s structure, not quite product, not quite marketing, not quite support and that ambiguity can make it vulnerable when budgets get tight.
When companies are under pressure, it’s easy to cut what feels non-essential. And because DevRel’s value isn’t always immediate or easily quantified, we end up on the chopping block, even when the work we’re doing is what brought developers in, kept them engaged, and built long-term trust.
None of that changes the fact that this is a hard moment. And if you’re in it, I see you.
But I want to be clear about something: this wave doesn’t erase the impact you’ve had. It doesn’t undo the communities you helped shape, the product decisions you influenced, the careers you quietly supported behind the scenes.
This role asks us to show up with empathy, consistency, and credibility. And that work doesn’t disappear because a company didn’t know how to measure it.
So if you’re feeling untethered right now, that’s real. But so is your insight. So is your experience. So is your value.
And I hope the rest of this post reminds you of that.
The Work Is More Measurable (and More Measured)
And it’s because of all this, the visibility, the pressure, the need to prove value, that the conversation around measurement has changed too.
Back in 2018, a lot of DevRel teams were still building on instinct. We ran programs that felt valuable, created content that helped people, showed up where developers were gathering, and then struggled to explain why that work mattered on a spreadsheet.
We were the “trust team.” The “good vibes team.”
That’s changed.
Over the years, I’ve watched more and more DevRel teams shift from intuition to intention. We’ve started defining our goals more clearly, choosing metrics that match the stage our programs are in, and building habits around sharing our results, not just internally, but cross-functionally.
These days, it’s rare to find a DevRel team that isn’t tracking something. Maybe it’s product adoption. Maybe it’s retention or activation. Maybe it’s content performance or community health. A few are even connecting the dots all the way to sales influence or revenue outcomes.
And honestly? That’s a good thing.
Metrics don’t dilute the heart of the work. They help protect it. They give us language to advocate for what we know is true, that investing in developer trust pays off, even if the path isn’t always linear.
Especially in the aftermath of layoffs, especially when headcount is under scrutiny, having a clear and grounded story to tell can make all the difference. It helps you keep the work going. It helps you build buy-in. It helps you protect your team’s time and energy from being pulled in a dozen directions that sound urgent but aren’t actually useful.
To be clear: not everything that matters is measurable. You can’t put a number on belonging. You can’t quantify the moment someone watches a talk, tries a thing, and finally gets it.
But we can build proxies. We can notice patterns. We can tell better stories, stories that show impact and insight.
And we can use those stories to not only keep our seat at the table, but to shape the table itself.
The Emotional Labor Is Real
Here’s something I didn’t talk about in 2018, at least not directly: the emotional toll this job can take.
Developer Advocacy looks fun from the outside. And sometimes it is. You get to talk about tech, meet interesting people, share knowledge, represent products you believe in. But what people don’t always see is the cost of being that visible.
You’re always “on.” Your inbox is always full. People DM you at all hours. You’re expected to be upbeat, helpful, informed, and kind, regardless of what kind of day you’re having.
You’re the person developers vent to when something breaks. You’re the one who gets tagged when documentation is confusing. You’re the human buffer when a product decision sparks backlash. And in the middle of all that, you’re supposed to be creative. Strategic. Measurable. Inspirational.
And it’s gotten harder in the past few years. After the layoffs in 2023 (and even more this year), many DevRel teams were gutted, reduced to one or two people trying to do the work of five. Some roles were moved into marketing, others into support. And the people who stayed had to carry even more weight. The result? More stress, less support, and a deeper risk of burnout.
We don’t talk about that part enough.
We don’t talk enough about how hard it is to advocate for change while also carrying the emotional burden of community needs, executive expectations, and personal exhaustion. We don’t talk enough about the anxiety that comes from trying to maintain trust with both developers and stakeholders when those interests don’t always align.
And we definitely don’t talk enough about how to build boundaries when your work is tied so closely to your identity.
But we need to. Because this is sustainable only if we make it sustainable. That means building in recovery time. It means mentoring each other through the hard seasons. It means advocating for ourselves with the same energy we use to advocate for our communities. And it means designing DevRel not just as a function, but as a practice of care.
Advocacy Still Means Something
At the end of the day, this job is about trust. Trust with your community, and trust with your company.
That means showing up consistently. It means listening carefully. It means saying hard things with care. It means speaking up internally when something isn’t right. And it means understanding that you don’t have to be the loudest person in the room to make an impact, you just have to be clear, honest, and grounded in service.
And here’s the thing: that hasn’t changed. Not since 2018. Not even through AI shifts, budget cuts, or title changes. The core of this work, the real heartbeat of Developer Advocacy is still human.
It’s part educator, part engineer, part community builder, part translator. It’s deeply strategic and incredibly personal. And when it’s done well, it doesn’t just help companies grow. It helps developers feel seen, supported, and successful.
I could talk about this all day and maybe someday I will write the follow-up post on reporting structures, team models, and DevRel leadership. (Spoiler: they’re changing. More teams are cross-functional. More roles are emerging. The “DevRel of one” model is fading fast.)
But for now, I hope this gives you a clearer picture of what Developer Advocacy looks like in 2025 and why it still matters. <3