What Is DevRel? Developer Relations Role, Skills, and Career Path

Developer Relations (DevRel) is often misunderstood as “marketing for developers” or “getting paid to travel and speak at conferences.” That reading misses the strategic value. DevRel captures developer reality and feeds it back into product development. It also scales developer education past what a documentation team can cover alone. Everything else follows from that definition: who thrives in the role, and when a company should fund one.

In a previous article on Forward Deployed Engineers, I explored a role that bridges code and business through hands-on customer implementation. DevRel represents a different kind of bridge: connecting products to the broader developer ecosystem through education, community building, and advocacy. Both roles share the characteristic of working at the intersection of technical and non-technical domains, but they serve fundamentally different purposes.

The Feedback Direction

Companies that treat DevRel as one-way communication (company to developers) miss half the value. The direction that runs the other way, developers back to the company, is usually the one that pays:

• It improves products in ways that matter to actual users
• It prevents building features no one needs
• It identifies competitive threats early
• It surfaces use cases that inform go-to-market strategy

This is also the practical difference from marketing. A campaign ends when the quarter does; a feedback channel has to face the same developers next quarter, and that is what keeps the reporting honest.

Job Titles Under the DevRel Label

DevRel is a functional area, and it covers several distinct specializations:

Role	Primary Focus	Key Activities
Developer Advocate	Two-way advocacy	Speaking, content creation, feedback synthesis
Developer Evangelist	Outbound awareness	Conferences, meetups, demos, visibility
Developer Experience (DX)	Product usability	SDK design, onboarding, documentation
Community Manager	Community operations	Forums, events, engagement programs
Technical Writer	Educational content	Documentation, tutorials, guides
DevRel Engineer	Technical enablement	Sample code, integrations, developer tools

The boundaries between these roles blur in practice. A Developer Advocate might spend significant time on content creation. A Community Manager might speak at events. Smaller teams often combine multiple functions into generalist DevRel roles.

Reporting Line and Its Side Effects

DevRel teams report to different departments depending on company priorities:

Under Marketing: Focus on awareness, lead generation, and brand building. Metrics tend toward reach and conversion.

Under Product: Focus on feedback loops, developer experience, and product improvement. Metrics emphasize adoption and satisfaction.

Under Engineering/CTO: Focus on technical credibility, open source, and developer tools. Engineering mindset prevails.

Under CEO/Founders: Common at startups where DevRel is strategic to the business model. Direct executive sponsorship.

The organizational placement significantly affects priorities, metrics, and perceived value. Where the team reports often predicts its challenges: marketing-aligned teams struggle to prove technical credibility; engineering-aligned teams struggle with business justification.

Developer-First vs Developer-Plus Companies

Developer-First (B2D model): the primary customers are developers, so DevRel sits at the centre of the business model. Twilio and HashiCorp have both written publicly about how they staff and run it.

Developer-Plus: developers are one audience next to consumer or enterprise buyers. DevRel supports platform and API adoption, and companies in this group usually fund it as a subset of marketing or product, later and more cautiously than developer-first companies do.

Where the Hours Go

Company and role change the mix, but the same buckets keep showing up, and content usually takes the largest share.

Content: blog posts, tutorials, code samples, video, live streams, documentation contributions, sample applications.

Community: forum answers, Discord and Slack moderation, social media, office hours, and finding the people who are already helping others.

Speaking and events: conference talks, meetup presentations, workshop facilitation, podcast and video appearances.

Internal work: synthesizing product feedback, prioritizing it, arguing for it on the roadmap, keeping other teams aligned.

Coding: sample applications, SDK improvements, integration testing, checking that the code in the docs still runs.

What the Glamour Costs

Seen from outside, the job looks like travel, talks, and a paycheck. The travel and the talks are real, and so is the satisfaction of watching someone get unstuck because of something you wrote. The rest of the package is less visible: jet lag, the same question for the hundredth time, always-on community expectations, scope creep, and the pressure to prove business value for work that is mostly relationships. Average tenure in DevRel tends to be shorter than in traditional engineering roles, and burnout is part of the reason.

The Skill Mix

Enough Depth to Be Credible

You need enough technical depth to be trusted, not enough to be the deepest expert in the room:

• Programming proficiency in at least one relevant language
• Working knowledge of APIs, SDKs, and developer tooling
• Ability to read code in languages you do not write
• Git and GitHub workflow familiarity
• Basic understanding of cloud infrastructure

Open source history, a personal blog, and domain knowledge in the company’s specific area (AI/ML, databases) all help, but none of them are entry requirements.

Writing, Speaking, Listening

This is where the role diverges most from engineering. Writing covers technical posts that are accurate and readable, documentation someone else can maintain, and a social presence in your own voice. Speaking runs from lightning talks to keynotes, plus workshops and podcasts, and the skill underneath it is adjusting depth for the audience in front of you.

Listening is the part people underestimate. It means reading sentiment across forums, GitHub issues, and social media, asking the questions that surface the actual problem, and turning scattered complaints into something a product team can act on. Holding all of this together takes patience with repetition, tolerance for public criticism, and enough self-direction to plan your own week.

When Should a Company Invest in DevRel?

What Has to Exist First

1. Product-market fit established: don’t hire DevRel to find PMF; hire after you’ve validated it
2. Some organic developer interest: if no one is using your product, DevRel can’t amplify zero
3. Clear success criteria: “make developers happy” is not a strategy
4. First-hand DevRel experience inside the company: founders or engineers should have done the activities themselves before delegating them
5. Documentation that exists: DevRel scales what works; they shouldn’t start from zero

Timing Indicators

The First Hire

The common recommendation is to start with a generalist Developer Advocate who can:

• Create foundational content
• Engage with the early community
• Gather and synthesize feedback
• Define what specialized roles would be needed next

An alternative approach: promote from within. An engineer who already engages with the community reduces ramp-up time and establishes credibility immediately.

DevRel vs Similar Roles

Aspect	Developer Advocate	Developer Evangelist	Community Manager	Solutions Engineer
Direction	Bidirectional	Outbound-focused	Community-focused	Sales-aligned
Primary Goal	Developer success	Awareness and adoption	Community health	Deal support
Coding Level	Moderate-High	Moderate	Low-Moderate	Moderate-High
Travel	High	Very High	Low-Moderate	Moderate
Metrics	Engagement + Feedback	Reach + Awareness	Community health	Revenue influence

Developer Advocate vs Evangelist

The terms get used interchangeably, but the distinction is meaningful. Advocates work in both directions: representing developers to the company as much as the company to developers. Evangelists are primarily outbound, and the goal is awareness and adoption.

DevRel vs Marketing

Marketing owns campaigns, lead generation, and messaging optimization. DevRel owns relationships, technical credibility, and engagement that survives contact with the product. Both create content and both want adoption; the approach and the time horizon differ.

DevRel vs Sales Engineering and Support

Sales engineering is deal-shaped: a named opportunity, a named account, revenue influence as the measure. Support is ticket-shaped and reactive, focused on resolving one problem at a time. DevRel is ecosystem-shaped and proactive, measured by community health and product adoption, and the content it produces is meant to prevent tickets before anyone opens them.

Career Path and Growth

Career Levels

Progression runs along more than one axis: technical depth in a specific area, strategic scope from execution to program design, team leadership, and cross-functional influence over the roadmap. Different companies weight them differently, which is part of the next problem.

The Ladder Often Is Not There

Industry surveys suggest only about a third of DevRel professionals report having a defined career path at their organization. Career growth often requires:

• Self-advocacy for role definition
• Documenting impact in ways leadership understands
• Potentially changing companies for advancement
• Building external reputation that validates internal progression

Compensation typically matches engineering compensation at equivalent levels, though this varies by company type and region.

Where the Role Gets Hard

Proving Business Value

Relationship work resists measurement, and every DevRel team eventually has to answer for it. A few things help:

• Agreeing on metrics with leadership before the work starts
• Tracking engagement as a leading indicator alongside adoption as a lagging one
• Building attribution for content-influenced conversions
• Writing the report in the language other functions already use

Burnout

Constant travel, public speaking, and an always-on community wear people down. The countermeasures are unglamorous: a cap on conferences per quarter, recovery days after events, speaking slots shared across the team, and stated hours when nobody is watching the Discord.

Scope Creep and Skill Atrophy

These two look like separate problems. DevRel gets asked for content, events, support, sales enablement, product feedback, and documentation. Every yes takes hours from somewhere, and the hours usually come out of technical work, which is the part that keeps the role credible.

The defence has to be written down: a documented list of what DevRel does not do, service agreements with the teams that keep asking, and a standing block for code. Keeping one substantial sample application alive does more for credibility than a shelf of hello-world demos. Pairing with engineering periodically and contributing to open source keep the skills from going stale.

The Measurement Paradox

Pressure to measure everything pulls attention away from the relationships being measured. You end up optimising for the dashboard. The way out is to pick one or two metrics the team actually believes in, report them with narrative context, and spend the leftover energy explaining to leadership how community building behaves over time.

What to Measure

Picking a North Star

Most teams track a dozen things badly. One metric the whole team can name is worth more. The common candidates are monthly active developers (how many people are actually using the product), time to first hello world (how fast a newcomer gets something running), and a developer satisfaction score.

The Funnel Underneath

The funnel below the north star is not special to DevRel:

• Awareness: content views and engagement, social reach, event attendance, new community signups
• Activation: signup-to-active conversion, tutorial completion, documentation engagement
• Engagement: community participation, support ticket trends, champions emerging
• Retention: developer retention over time, community-generated content, referral indicators

DevRel Qualified Leads

Sales-qualified leads count people likely to buy. DevRel Qualified Leads (DQLs) count community members who can contribute value back:

• Open source contributors
• Community speakers and writers
• Beta program participants
• Meetup organizers
• Champion developers

Tracking them gives the team a number for a contribution a sales pipeline has no column for.

Is DevRel Right for You?

The role fits people who enjoy teaching, like variety in problems and audiences and formats, and can work with their output in public. Community connections have to matter to you beyond what they convert into. You also need to switch contexts easily between reading code and writing for people who will not read any.

It fits badly if you want to become the deepest expert in one narrow thing, or if ambiguous outcomes frustrate you. Public speaking that drains you does not stop draining you at conference scale, and always-on community expectations sit uncomfortably with a firm boundary between work and the rest of life. Repetition is part of the job: the same beginner question arrives again next week.

If You Want to Move Into It

For engineers considering the switch:

1. Start a technical blog: consistency matters more than perfection. Write about what you learn.
2. Speak at local meetups: build the reflex before a large room is watching.
3. Contribute to open source: it shows technical skill and community behaviour at once.
4. Engage where developers already are: Stack Overflow, Discord, Twitter/X. Answer the questions you once needed answered.
5. Practice explaining concepts: can you make the same topic land for a junior and for a staff engineer?

When to Fund It, and When to Wait

Fund DevRel once there is product-market fit, some organic developer interest, and a written definition of what success looks like. Hire before that and you are paying someone to amplify nothing. Hire long after it and the first year goes to repairing community perception and documentation debt instead of building anything.

The same boundary applies to the individual choice. The role rewards people who want breadth, visibility, and teaching, and it frustrates people who want depth and quiet.

References

• State of Developer Relations Report 2024 - Annual industry survey on DevRel trends, metrics, and challenges
• DevRel Qualified Leads: Repurposing a Common Business Metric - Mary Thengvall’s framework for measuring DevRel value
• Measuring DevRel - Comprehensive guide to DevRel metrics and north star approaches
• Developer Relations at Twilio - Case study on building DevRel teams
• 2023 Developer Relations Compensation and Culture Report - Common Room’s research on DevRel burnout and compensation
• The Business Value of Developer Relations - Mary Thengvall’s foundational book on DevRel
• Developer Advocates vs Technical Evangelists - Role comparison and distinctions
• DevRel Career Ladders - Career progression frameworks for DevRel professionals
• How HashiCorp Does Developer Advocacy - Enterprise DevRel approach