If you’ve spent any time in tech Twitter, conference hallways, or job boards, you’ve probably encountered the term “DevRel” — usually in a bio that reads something like “Developer Advocate @SomeCompany | Building in public | ex-engineer.” It sounds vague. Is it marketing? Is it engineering? Is it just someone who gets paid to tweet?
The honest answer is that DevRel is all of those things, none of those things, and a few things nobody had a clean word for when the role was invented. It’s also one of the most misunderstood disciplines in technology — misunderstood by the companies that hire for it, by the engineers who interact with it, and sometimes by the people doing it.
This guide exists to fix that. By the end, you’ll know exactly what DevRel is, who does it and in what roles, what the work actually looks like day-to-day, why companies invest in it, and how to think about breaking into it as a career. We’ll start at zero and go deep.
Where DevRel came from
You can’t understand what DevRel is today without a brief stop in the 1980s. This is not optional context — it explains why the field looks the way it does.
Apple was building the Macintosh. The hardware was remarkable, but a computer without software to run on it is just expensive sculpture. Apple needed developers to build apps for the Mac, and convincing developers to bet their time on a new platform required more than a spec sheet. Enter Mike Boich and, later, Guy Kawasaki — Apple’s first “software evangelists.” Their job was to get developers genuinely excited about the Mac, help them build for it, and make sure Apple understood what developers needed to succeed.
Kawasaki didn’t give sales pitches. He showed developers what the Mac could actually do, helped them solve real problems, and became a genuine part of the community he was serving. It worked spectacularly. The Mac got software, the software attracted users, and a flywheel started spinning that Apple is still riding.
Microsoft noticed and, in 1989, created its own Developer Relations Group — staffed, notably, by actual developers, not MBAs. Different philosophy, same recognition: if your platform depends on other people building for it, you need people whose full-time job is making those builders successful.
That’s the seed. For the next two decades, DevRel lived mostly inside big platform companies — Apple, Microsoft, later Sun and IBM. The open-source explosion and the API economy of the 2010s changed everything. Suddenly Twilio, SendGrid, New Relic, and Stripe were building businesses that ran on developers choosing their APIs over a competitor’s. Twilio became the canonical example: their developer relations team was legendary, their developer experience was obsessively polished, and developers didn’t just use Twilio — they talked about it. Recommended it. Built their careers on it. Twilio put up billboards in San Francisco that just said “Ask Your Developer,” confident that developers would say good things.
That’s what a mature DevRel program looks like at its best. But we’re getting ahead of ourselves.
What DevRel actually is
Developer Relations is the practice of building genuine, mutually beneficial relationships between a company and the developer community. It’s the umbrella — and a large one — under which several different roles and functions live.
The key word is genuine. Developers are, as a group, remarkably good at detecting inauthenticity. A developer advocate who clearly doesn’t understand the product, or who disappears from the community the moment a conference talk ends, gets found out quickly. The whole discipline runs on credibility, and credibility takes time to build and seconds to lose.
DevRel sits at the intersection of three things: technical depth, communication, and community. Most people in the field came from engineering and grew into the communication and community side. Some came from writing or marketing and grew into the technical side. The rare ones who started with all three were probably insufferably good at school.
Importantly, DevRel is a two-way street. It pushes outward — helping developers understand, adopt, and succeed with a product. But it also pulls inward — bringing developer feedback, pain points, and feature requests back to the product and engineering teams. A DevRel program that only broadcasts is just marketing in a hoodie.
The roles inside DevRel
“DevRel” gets used interchangeably with “developer advocate,” but that’s like saying “engineering” means “backend developer.” The umbrella is much bigger. Here are the core roles you’ll encounter:
Developer Advocate
This is the most visible role in the field and the one people usually mean when they say “DevRel.” A developer advocate builds credibility in the community by being genuinely useful: writing tutorials, speaking at conferences, creating sample projects, recording videos, answering questions on Discord or Stack Overflow. They’re the human face of the product in developer spaces.
But advocacy isn’t just outbound. The second half of the job is internal: bringing the developer community’s voice back into the company. If the authentication flow is confusing, if the error messages are useless, if a certain SDK is broken in a specific runtime — the developer advocate is the person who surfaces that, tracks it, and keeps pushing until it’s fixed. Think of it as a feedback valve that runs in both directions simultaneously.
Developer Evangelist
The term is older and carries slightly different connotations. Evangelists tend to be more outbound-focused — more conference talks, more buzz-building, more “getting the word out.” They’re brand ambassadors with technical credibility. Some companies use advocate and evangelist interchangeably; others draw a real distinction between the community-service focus of an advocate and the awareness-building focus of an evangelist. Worth asking when you see the title in a job posting.
Developer Experience (DX) Engineer
This is the most engineering-adjacent role in DevRel. A DX engineer doesn’t go to conferences — they sit with the product and ask: what is it like to use this thing for the first time? They obsess over the time it takes a developer to reach their first successful API call (“time to first value,” or TTFV). They write SDKs, improve error messages, design onboarding flows, and fix friction in the integration experience. Good DX is invisible. You know when it’s missing because you’ve spent four hours reading docs and still can’t get the hello-world example to run.
Community Manager
Where the developer advocate builds credibility through technical content, the community manager builds and sustains the space where the community lives. Discord servers, Slack groups, forums, GitHub Discussions, meetups, hackathons — these don’t run themselves. A community manager sets the tone, enforces the norms, spotlights great contributions, handles conflict, and makes the community feel like a place worth being. They’re also the internal voice of the community in a different way than the advocate — less about product bugs, more about community health and sentiment.
Technical Writer
Not always formally part of DevRel, but deeply connected to it. Documentation is the primary interface between a developer and a product they’re evaluating. Good docs turn a skeptical developer into a confident one; bad docs send them to the competitor’s site. Many DevRel teams either own documentation directly or work tightly with the technical writing team. At companies like Twilio and Stripe, documentation has been treated as a first-class product feature.
DevRel Manager / Director
Eventually someone has to run all of this. A DevRel leader sets strategy, manages the team, owns the budget, interfaces with other departments (usually marketing, product, and engineering), and does the often thankless work of explaining to executives why developer goodwill is worth the investment. They also deal with the perennial question of where DevRel sits in the org chart — a question that has no universal right answer and causes more internal friction than it should.
What the work actually looks like
Here’s what a DevRel professional might have done last week:
Gave a 40-minute talk at a regional cloud conference on best practices for securing API keys. Stayed for two hours afterward answering questions from developers in the hallway. Opened a GitHub issue on the way home because three people independently asked why the rate limiting behavior wasn’t documented.
Wrote a tutorial on integrating the company’s SDK with a popular framework. Spent longer than expected on the tutorial because actually trying to follow their own documentation revealed three steps that were out of date. Filed internal tickets for each of them, then updated the docs before publishing.
Hopped into the community Discord at 9pm because a developer was stuck on a webhook verification issue that turned out to be a bug in the Python library. Debugged it live, filed a PR, and helped the developer implement a workaround in the meantime.
Attended a product planning meeting to flag that three separate community threads that month were about the same missing feature. Made the case for prioritizing it. Got the feature added to the next quarter’s roadmap.
That’s not an extraordinary week. That’s Tuesday through Friday for a developer advocate at a healthy company with a real DevRel program.
Why companies invest in DevRel
The cynical read on DevRel is that it’s marketing with a technical costume. That’s both partially true and a misunderstanding of why it works.
Developers don’t respond to marketing the way other audiences do. They’re deeply skeptical of vendor claims, highly influenced by peer recommendations, and willing to invest significant time evaluating tools before committing. A banner ad does nothing. A conference talk from someone who clearly knows what they’re talking about and answers hard questions honestly is enormously influential. A great getting-started guide that actually works is a product differentiator.
Twilio’s success is the frequently cited example, and it’s cited frequently because it’s genuinely instructive. Their DevRel team was legendary in the early days — technically excellent, present in the community, honest about limitations. Developers trusted them. And when developers trusted them, they integrated Twilio into products, which meant businesses adopted Twilio, which meant revenue. The connection between community trust and business outcomes wasn’t abstract.
There’s also the product feedback angle, which companies often underestimate. A DevRel team embedded in the developer community is a standing early-warning system. They hear about friction, confusion, and bugs before they show up in churn data. The companies that treat DevRel as a feedback channel get better products than the ones that treat it as a broadcast channel.
The hard thing about DevRel: measuring it
If you spend any time in DevRel conversations, you’ll hit this topic quickly. It’s the field’s biggest ongoing challenge.
The problem is that DevRel’s most important outputs — trust, reputation, community goodwill, developer confidence — are genuinely hard to quantify. And the things that are easy to measure (conference talks given, blog posts published, Discord messages sent, GitHub stars earned) are often the wrong things to measure. A DevRel team that optimizes for activity metrics looks productive while potentially doing nothing that drives the business.
The better framing, which has been gaining traction, is to connect DevRel activity to business outcomes. Time to first successful integration. API activation rates from developer community channels. Developer-influenced pipeline. Retention rates for developers who engaged with DevRel content versus those who didn’t. These are harder to set up but actually tell you something.
The worst-case version of DevRel measurement is a dashboard full of impressive-looking vanity metrics — follower counts, video views, event attendance — that no one can connect to business value. That’s how DevRel programs get cut in a downturn.
What DevRel is not
A few things worth clearing up explicitly, because the confusion is persistent:
DevRel is not just marketing. Marketing targets audiences. DevRel builds relationships. The distinction sounds subtle but drives completely different behavior. A marketing campaign ends. A community relationship you neglected for three months doesn’t restart cleanly.
DevRel is not just developer advocacy. Advocacy is one function under the DevRel umbrella, alongside experience, community, education, and sometimes documentation and support. A company with only a developer advocate and no DX work or community infrastructure is running on one cylinder.
DevRel is not sales engineering. Sales engineers explain technology to close deals. Developer advocates help developers succeed, often with people who will never become customers, because those developers talk to other developers. The motivation and the time horizon are different.
DevRel is not a support team. Some DevRel professionals do answer support questions, and doing so builds goodwill and surfaces product issues. But DevRel programs that get buried in support tickets stop being DevRel programs and start being underfunded support operations.
Who DevRel is for (companies)
Not every company needs a DevRel team. But if your product is a developer tool — an API, an SDK, a platform, a cloud service, a framework — and developers choose whether or not to adopt it, then you have a DevRel problem whether or not you have a DevRel team. The question is just whether you’re solving it intentionally.
The companies where DevRel has the clearest return on investment are API-first businesses (Stripe, Twilio, SendGrid), cloud infrastructure providers (AWS, Google Cloud, Azure), developer tooling companies (GitHub, Vercel, Postman), and open-source foundations (CNCF, Apache). In all of these, the developer community is not just a user base — it’s a distribution channel, a feedback mechanism, and a moat.
Getting into DevRel as a career
There’s no degree for this. People come from software engineering, technical writing, developer marketing, teaching, community management, and sometimes places further afield. What the successful ones share is a genuine interest in helping other developers, technical credibility they can build on, and some form of public communication they’ve already started.
If you’re an engineer thinking about moving toward DevRel, start doing the things DevRel people do before you have the title. Write a technical blog post about something you actually built and hit friction on. Give a talk at a local meetup. Answer questions in an open-source community forum. Contribute to a project’s documentation. Build a small demo and publish it with a writeup.
You don’t need all of this. But you need some of it, because DevRel hiring almost always comes down to evidence of the specific blend: can you code, can you communicate, and do you actually care about the developer community you’re trying to serve?
The tools stack varies by company and focus area, but you’ll encounter GitHub constantly, developer community platforms like Discord and Slack, content creation workflows, and increasingly, analytics tooling to measure what’s working. None of this is hard to learn once you’re in the role.
The one thing most people get wrong about DevRel
DevRel’s value is long-cycle. The developer you helped debug a gnarly webhook issue at a conference might not become a customer for two years — and when they do, no attribution model will capture why. The tutorial that helped a thousand developers integrate your SDK created goodwill that shows up in referrals, community reputation, and reduced churn, but diffusely and over time.
This makes DevRel structurally vulnerable to short-term thinking. When companies need to cut costs, a program whose value is “trust” and “reputation” sounds optional next to a sales team whose value is pipeline. The companies that have maintained strong DevRel programs through multiple market cycles — Stripe and AWS come to mind — have done so because leadership understood this. The ones that cut DevRel and regretted it learned the lesson the expensive way.
The developers who use your tools are not an audience to be managed. They’re a community to be served. That orientation — developer value first, business outcomes as a byproduct — is what distinguishes great DevRel from its cheaper imitations.
And it’s also, for most people in the field, why they chose it in the first place.