What is DevRel?

DevRel didn't start as a job title. It grew out of a problem: platforms only succeed when developers build on them.

The evangelist era (1980s–2000s). Apple hired "software evangelists" in the 1980s to convince developers to build Macintosh applications. Guy Kawasaki made the title famous. Microsoft, Sun Microsystems (Java) and later Google built large evangelism teams. The model was mostly one-way: travel, give keynotes, win developers over to a platform.

The API economy (late 2000s–2010s). Twilio, Stripe, SendGrid and others sold directly to developers. A developer could sign up with a credit card and ship in an afternoon, so developer experience was the sales funnel. Twilio's "developer evangelist" team became a template: engineers who wrote code in public, answered questions, and treated time-to-first-API-call as a core metric.

Open source and foundations (2010s). The rise of GitHub, the CNCF (Kubernetes) and company-backed open source pulled DevRel toward community building and contributor programs. Roles split into advocacy, community, documentation and developer experience.

Measurement and maturity (late 2010s–now). As teams grew, executives asked the hard question: what are we getting for this? Books like The Business Value of Developer Relations (2018) and Developer Relations by Lewko and Parton (2021) pushed the field toward strategy, metrics and journey thinking. AI tooling is now reshaping how developers discover and learn products, which puts even more weight on docs, examples and trust.

Why it matters for you: each era left behind expectations that still exist. Some companies still want keynote evangelists; others want DX engineers who fix onboarding. Knowing the history helps you read a job description and see which era it's hiring for.

"DevRel" covers a family of roles. When you search for DevRel jobs, postings fall into seven broad categories. They overlap, and titles are inconsistent between companies, so read each posting for the work and the metrics, not the title. Here's how they compare.

At a glance

One more label you'll see: Developer Success / Solutions roles help specific customers succeed with the product. They sit closer to sales and support, but they're a common stepping stone into DevRel.

Where to start

Early in your career, pick the category closest to your current strengths and add adjacent skills from there. An engineer usually starts as an advocate or DX engineer, a writer in docs or education, and a community organiser in community. Seniority means covering more of the table, not switching categories every year.

Reading a job posting

• Look at the metrics and the reporting line. "Pipeline" and "MQLs" point to a marketing-led role, "roadmap" and "activation" to a product-led one.
• Check the split. A posting that asks for content, community, docs, events and SDKs is a generalist DevRel role. That's great for learning, but ask what matters most.
• Ask what success looks like at six months. A clear answer means the role is well defined.

DevRel is one of the most interdisciplinary roles in tech. Almost nobody starts their career in it. People move in from a neighbouring role, and the one you come from decides which strengths you already have and which gaps you need to close.

There is no "best" background. Hiring managers look for technical credibility, clear communication and genuine care for developers. Every path below can get you there, just from a different starting point.

⚙ From Software Engineering

6–12 months to full transition

The most common entry path. Engineers bring technical credibility and can speak peer-to-peer with developers. Gaps are usually in content creation, public speaking, and community strategy.

Skills to bridge: Technical writing · Public speaking basics · Community listening

📣 From Developer Marketing

6–18 months to build technical credibility

Marketers who work closely with developer audiences often shift into DevRel. Strengths in content and campaigns; gaps in technical depth and community authenticity.

Skills to bridge: Build a real project · Earn a technical credential · Contribute to open source

✍ From Technical Writing

3–9 months with intentional exposure

Tech writers have strong documentation fundamentals and understand developer journeys. The shift is about expanding from docs into community, events, and evangelism.

Skills to bridge: Conference speaking · Community program ownership · Demo building

🌐 From Community Management

9–18 months for technical foundation

Community managers who work in developer spaces can bridge into DevRel naturally. Technical depth and content creation are the most common gaps to close.

Skills to bridge: Learn a programming language or framework · Publish technical content · Build a side project

🛠 From Developer Support / Solutions

3–12 months depending on experience

Support engineers and solutions architects understand developer pain deeply. Transitioning into DevRel is often a matter of shifting from 1:1 to 1:many — from solving to educating.

Skills to bridge: Content creation at scale · Stage presence · Community program design

How to use this

1. Find your starting point. If you straddle two, pick the one your last role was closest to.
2. Lean into your strength. It's your differentiator. An engineer-turned-advocate and a writer-turned-advocate are valuable for different reasons.
3. Close one gap at a time. Use the bridge skills above as your first goals, and use this roadmap's Compass Challenges as proof you've closed them.
4. Do DevRel work in your current role. Internal docs, demos, lunch-and-learns and answering questions in community channels all count as experience.

Companies fund DevRel because developers adopt tools differently from other buyers. They try before they buy, they distrust sales pitches, and they decide based on docs, examples and what peers recommend. That creates a few business outcomes DevRel is uniquely placed to move:

• Awareness with credibility. A tutorial that solves a real problem reaches developers in a way an ad never does.
• Activation. Good onboarding, samples and docs shorten the time from sign-up to "it works", which is where most developer products lose people.
• Retention and expansion. Developers who feel supported, and part of a community, stay and bring their teams.
• Product feedback. DevRel hears unfiltered developer pain every day. Channelled well, that becomes a competitive advantage for the product team.
• Hiring and brand. A strong developer community makes engineers want to work for you.

The trap is that these outcomes are lagging and indirect. A talk today may lead to a sign-up in six months via a colleague's recommendation. That is why DevRel teams that can't articulate their impact get cut in downturns, and why you'll spend a whole phase on analytics later.

Watch Ace Abati's Strategy Room session on why technically excellent products still fail to win developers. It is the clearest argument for why this function exists.

Skills can be learned in any order. The mindset is what makes them add up.

Community first, company second — honestly. Your job is to help developers succeed, even when the answer is "our product isn't the right fit for this". That honesty is exactly what makes your recommendations trusted when the product is the right fit.

Long-term relationships over short-term wins. A single viral post fades. Showing up every week in the same community, answering questions and remembering names compounds.

Advocate in both directions. You represent developers inside the company just as much as the company to developers. If you only ever carry messages outward, you're doing marketing.

Teach, don't pitch. Lead with the problem the developer has, then show the solution. Mention your product where it genuinely helps.

Build credibility by building. Ship small demos, contribute fixes, write code in public. You earn the right to have opinions by doing the work.

Systems over heroics. Rohit Ghumare's Strategy Room session makes the case that sustainable DevRel is a set of feedback loops, not one person doing everything. Design programs that keep working when you're on holiday.

The two overlap and cooperate, but they're optimised for different things.

Healthy teams work together. Marketing brings reach, positioning and launch discipline. DevRel brings technical credibility, content that developers actually read, and a direct line to community sentiment. Friction starts when DevRel is measured purely on marketing numbers like leads and MQLs, or when marketing co-opts DevRel's community for promotions that erode trust.

A good practical rule: if a developer would feel sold to, it's marketing, and it should be labelled and handled as marketing. Adam DuVander's book title makes the point: "developer marketing does not exist" when it doesn't also educate.

Where DevRel reports is the single biggest predictor of how it will be measured.

• Under Marketing. Budget for events and content is easier to get. Expect metrics like reach, sign-ups and influenced pipeline. Risk: being treated as a content factory and losing technical credibility.
• Under Product. Strong feedback loops and influence on the roadmap. Expect metrics like activation, feature adoption and DX improvements. Risk: less budget for community and events.
• Under Engineering. Deep technical credibility and access to engineers. Great for DX and SDK work. Risk: public-facing work may be undervalued ("why aren't you shipping features?").
• Standalone / reporting to the CEO or CTO. Common in developer-first startups where developers are the customer. Maximum flexibility and the most pressure to prove value.

None is "correct". What matters is alignment: know your leader's goals and translate your work into them. In an interview, always ask "Who does DevRel report to, and what are they measured on?". The answer tells you what your job really is.