What Is DevRel (Developer Relations) and What Does a DevRel Program Manager Do?

DevRel (Developer Relations) is the function that builds and sustains relationships between a company and the developers who use, extend, or evaluate its technology. A DevRel program manager runs the programs that make those relationships repeatable at scale—hackathons, community events, advocacy, and feedback loops back to product—rather than personally doing all the outreach. This explainer is for people evaluating a DevRel role, hiring for one, or trying to tell DevRel apart from DevEx and developer marketing.

DevRel vs. DevEx vs. developer marketing vs. community management

These four are often conflated because they share an audience: developers. The difference is the primary job.

In practice the lines blur. A DevRel program manager often owns community programs and contributes to advocacy content, while DevEx owns the product and docs experience. The cleanest way to separate them: DevEx improves the product surface developers touch; DevRel improves the relationship between the company and developers.

What a DevRel program manager actually does

The role is program-shaped, not purely evangelist-shaped. Day to day it tends to include:

• Designing and running developer programs—hackathons, office hours, ambassador or contributor programs, workshops—with clear goals, budgets, and repeatable playbooks.
• Community building at scale, including event logistics, partner coordination, and onboarding new community members.
• Advocacy and enablement: talks, demos, sample projects, and helping internal teams communicate credibly with developers.
• Feedback loops to product: collecting developer pain points from events and community channels and routing them to engineering and product.
• Cross-functional coordination with marketing, product, docs, and open-source teams.

The "program manager" part matters: success is measured by whether programs can be repeated and scaled, not by one person's conference schedule.

How DevRel is measured

Because DevRel sits between marketing, product, and community, metrics are usually a blend:

• Reach and participation: event attendance, hackathon submissions, community growth.
• Depth of engagement: repeat participants, contributors, active community members.
• Product signal: feedback items surfaced, issues filed, feature adoption traced to DevRel programs.
• Advocacy output: talks, samples, and content produced with or by community members.

A common misconception is that DevRel is measured only on impressions or follower counts. Programs that survive budget scrutiny usually tie back to developer adoption or product feedback.

Skills and career path

Typical entry points are engineering, technical writing, developer support, or community organizing. A DevRel program manager usually needs:

• Enough technical fluency to demo, debug, and earn credibility with developers.
• Program and event management discipline—budgets, timelines, partners.
• Strong written and verbal communication.
• Comfort operating across product, marketing, and open-source teams.

The path often runs from developer advocate or community manager into program management, or from program management in adjacent fields into DevRel.

How DevRel differs across AI, open source, and game dev

The core function is the same, but the context changes the emphasis:

• AI: fast-moving APIs and models mean DevRel leans heavily on samples, tutorials, and rapid feedback to product; trust and accuracy matter more than hype.
• Open source: DevRel overlaps with maintainer relations, contributor programs, and governance—community health is a first-class concern.
• Game development: programs center on creator communities, game jams, and tooling ecosystems, with a strong event and showcase component.

A DevRel program manager working across these areas, as in the Lee Reilly profile referenced here, typically builds "joyful developer programs, hackathons, and community experiences at scale"—the program-management framing is the through-line.

Common misconceptions

• "DevRel is just evangelism." Advocacy is one output; program design, community operations, and product feedback are core.
• "DevRel and DevEx are the same." They overlap but own different surfaces—relationship vs. product experience.
• "DevRel is marketing." It shares goals with marketing but is judged on developer trust and two-way feedback, not campaign metrics alone.
• "It's all conferences." The scalable work is playbooks, programs, and feedback systems; events are one channel.

If you are deciding whether to build a DevRel function, start by clarifying which of the four functions above you actually need, then define one or two programs with measurable developer outcomes before scaling.