DevRel

Developer relations is the profession I helped define and the discipline I’ve spent fifteen years practicing, critiquing, and occasionally despairing over. DevRel is the organizational function responsible for the relationship between a company and the developers who use its APIs and tools — the team, the roles, the programs, and the practices that turn an API into an adopted, loved, well-supported platform. It sits at an awkward and important intersection: part engineering, part marketing, part product, part support, part community, and not fully any of them. That ambiguity is both DevRel’s superpower and its perpetual organizational problem. I’ve watched the profession emerge, mature, get funded, get cut, and reinvent itself, and I have strong opinions about what makes it work and what makes it fail — most of which come down to whether the company treats DevRel as a genuine relationship function or as marketing in a hoodie.

What is an API evangelist — the question I tried to answer formally in 2012 — is really the question of what DevRel is, because the title and the discipline grew up together. I defined the role as someone who emerged from the convergence of the social, cloud, and mobile technology waves, whose job was to bridge the technical and the human, to make APIs understood and adopted. The skills required, which I laid out as early as 2011 when I asked whether you could be an API evangelist, are unusual in combination: you need to be enough of a hacker or engineer to be credible with developers, enough of a business person to align with company goals, enough of a marketer to reach an audience, and self-motivated enough to operate in a role that rarely has a clear playbook. The demand for evangelists that I tracked in 2012 was driven by exactly this scarcity — companies needed people who could be equal parts engineering, product, business development, sales, and marketing, and those people are genuinely hard to find. That multi-disciplinary requirement has never gone away; it’s the defining characteristic of the DevRel professional.

The naming has always been contested, and the contest matters because it reflects real tensions in the discipline. Evangelist, advocate, developer relations, developer experience, developer marketing, developer success — these titles proliferated as the field matured, and they’re not interchangeable. “Evangelist” carries a faith connotation that some find off-putting and that developers, as I wrote in 2012, often instinctively resist. “Advocate” reframes the role as representing the developer’s interests back to the company rather than selling the company to the developer — a meaningful shift in emphasis that many in the field preferred. The Akamai job posting I quoted in 2014 defined the role beautifully as “a thoughtful voice that spreads awareness and encourages participation,” and that phrase has stuck with me as one of the best definitions of the discipline regardless of what title sits on the business card. The proliferation of titles is partly genuine specialization and partly companies trying to signal that their version of DevRel is the authentic, developer-first kind rather than the marketing kind.

DevRel is a team function, not a solo heroic act, and the failure to understand this is one of the most common organizational mistakes. I wrote in 2014 that it takes a team of evangelists to raise an API, using SendGrid’s structure as the model — a Director of Developer Relations, a manager, and a team of developer evangelists each covering different surfaces of the developer experience. A single evangelist can’t simultaneously write the documentation, run the events, produce the content, answer the forum questions, build the sample code, and represent developers in product planning. DevRel at scale requires a team with specialized roles and a leader who can articulate the function’s value to the rest of the organization. The companies that hire one developer evangelist and expect them to single-handedly build a thriving developer ecosystem are setting that person up to fail, and usually to burn out in the attempt.

The organizational placement question — where DevRel reports — is where a lot of the discipline’s dysfunction originates, and it’s a question I’ve watched companies get wrong repeatedly. When I surveyed seventy companies hiring evangelists and advocates in 2016, one of the most important things I flagged, drawing on wisdom from people like Keith Casey, was to look at where the role reports, how its success is measured, and what channels it owns. DevRel under marketing tends to get measured on leads and reach, which pushes it toward the salesy behavior developers reject. DevRel under engineering or product tends to get measured on developer success and product feedback, which aligns better with what the role should actually do, but can leave it without the resources and reach that marketing controls. There’s no perfect home, but the reporting structure shapes the incentives, and the incentives shape whether the DevRel team does authentic relationship work or quota-driven marketing in disguise. The measurement question is inseparable from this: I argued in 2012 that DevRel KPIs should be optimized for developer success rather than vanity metrics, because what you measure determines what the team actually does.

The relationship between DevRel and support is one of the most underexamined and most consequential, and I wrote about it specifically in 2017 because I kept seeing it break. DevRel does the outreach, builds the relationships, makes the promises — and then support has to deliver on the day-to-day reality of developers who are stuck. When there’s a gap between them, the evangelist’s authentic advocacy gets undermined by slow bug fixes, unanswered tickets, and unresolved issues that the evangelist has no control over. You can’t build trust with a developer community while the support experience is betraying that trust. DevRel and support, along with documentation and product, have to function as an integrated developer experience, or the relationship work that DevRel does gets quietly destroyed by the parts of the experience DevRel doesn’t own.

Internal evangelism is the half of DevRel that nobody talks about enough, and it’s often the harder half. I wrote in 2019 about the four phases of internal API evangelism — silence, challenges, questions, and engagement — as a change-management framework for winning over your own organization. The external-facing developer program gets all the attention, but inside large enterprises the developers and stakeholders you most need to reach are your own colleagues, and they move through predictable phases of resistance before they adopt. Everyone is an evangelist in an API-driven company, as I wrote in 2012, but getting to that state requires deliberate internal evangelism work that looks very different from the external kind — more politics, more patience, more repetition, less stagecraft. The DevRel professional who only knows how to work a conference stage and can’t navigate internal organizational change is only doing half the job.

The toolkit of the discipline is broad, and I tried to catalog it in 2019 as the common building blocks of evangelism: blog posts, social media, Q&A, email, meetup talks, conference talks, webinars, images, video, audio, tutorials, white papers, guides, code repositories, proofs of concept, prototypes, and collections. DevRel is a content and presence discipline as much as a relationship discipline — you reach developers through a steady, multi-format production of genuinely useful material, and through showing up in the places developers are. Going outside the echo chamber, as I argued in 2019, is part of this maturity: the best DevRel doesn’t just preach to the already-converted at API conferences, it reaches across industries and verticals to the developers and stakeholders who aren’t already part of the API conversation. And the authenticity imperative runs through all of it — you can feel it when an evangelist is the real deal, and developers can feel it even more sharply. I’ve encouraged DevRel professionals to publicly share their failures, not just their successes, because that transparency is itself a form of credibility, and because the discipline learns more from honest accounts of what didn’t work.

The sustainability of the profession — and of the professional — is something I learned the hard way and have warned others about ever since. My one piece of advice to the next generation of API evangelists, which I wrote in 2016 after my own health crisis from overwork, was to take care of yourself. DevRel is a role that demands constant travel, constant output, constant presence, constant emotional labor of representing a company to a skeptical audience and representing that audience back to an indifferent organization. It burns people out at a high rate. The performance aspect is real — I’ve written that API evangelism is a performance, and that I am an evangelist in a way that involves genuine faith and genuine stagecraft — but the person doing the performing is not infinite, and the companies that treat their DevRel people as inexhaustible content machines lose them.

Where the discipline is heading is genuinely uncertain, and I wrote about that uncertainty pointedly in 2025 when I asked where developer advocacy actually is. Hiring has declined from its 2021 peak, the Google Trends line has fallen, and I raised the uncomfortable question of whether developer advocacy ever had the cross-platform solidarity it claimed or whether it was always just platform marketing wearing the costume of community. That same year I moved into a Chief Community Officer role, after years as a Chief Evangelist, because I believe the next chapter of this work is more about genuine community stewardship and less about the evangelism model that the industry commercialized and partly hollowed out. AI agents are changing the audience — when your consumers are increasingly machines, what does developer relations even mean? My honest answer is that the core never changes even as everything around it does: DevRel is the discipline of caring, authentically and structurally, about the people on the other side of your API. The titles will keep shifting, the org charts will keep reshuffling, the audience will keep evolving. The work is, and always has been, building and tending a genuine relationship between a platform and the people who depend on it. Everything else is implementation detail.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

DevRel

References

Guidance Details

Explore more

Discover APIs