Developer relations is the function that earns a technology company trust with the engineering community — not by selling, but by helping developers succeed with the product. The role sits at the boundary between engineering, product, and community, and it is one of the most genuinely remote-compatible roles in tech: documentation, tutorials, conference talks, and open-source contributions are all deliverable from anywhere.
Three jobs are hiding inside "developer relations"
Community DevRel is the original model: attend conferences, run hackathons, answer questions in Discord or Slack, seed the ecosystem with early adopters. The output is measured in active community members, developer sentiment, and organic word-of-mouth. This is the most relationship-intensive variant of the role and benefits from someone with genuine credibility in the relevant developer community.
Content and education DevRel focuses on documentation, tutorials, sample apps, and video courses. The output is measured in content views, time-to-first-successful-API-call, and developer activation rates. This variant requires strong technical writing and the ability to think like a beginner even when you are not one. It is the variant that scales best with content production and overlaps significantly with the technical writer role.
Developer experience (DX) engineering is a newer, more product-oriented variant: improving the SDK, the onboarding flow, the error messages, and the CLI. Output is measured in activation rate, time-to-hello-world, and support ticket deflection. This variant requires strong engineering skills and blurs the line between DevRel and product engineering.
Four employer archetypes
API and infrastructure companies. The home territory for DevRel. The entire business is selling to developers, so DevRel is a strategic function — well-resourced, given real authority over product feedback loops, and held to commercial metrics (pipeline influenced, developer signups, SDK adoption). Expect a high bar for technical credibility: you need to have shipped things with the product.
Developer tool and platform companies. Similar to API companies but often earlier-stage, where DevRel is doing everything at once: content, community, conferences, and DX feedback. These roles demand broad range — the ability to write a tutorial in the morning, run a live workshop in the afternoon, and file a detailed GitHub issue in the evening. High autonomy, harder to measure output cleanly.
Horizontal SaaS companies with developer tiers. Companies like Zapier, Notion, or Airtable have built developer ecosystems around extensible platforms. DevRel here is less technically intense than pure API DevRel and more focused on enabling power users and integration builders. Good entry point for people coming from a less purely technical background.
Open-source companies. DevRel at an OSS-backed company means working with contributors as much as end users. The community is more technical, more opinionated, and holds the company to a higher transparency standard. Influence is earned through genuine open-source participation — pull requests, public GitHub discussions, honest changelogs — not through polished marketing.
What the weekly work actually looks like
The DevRel workweek rarely repeats. A typical week might include: writing or reviewing a getting-started tutorial for a new SDK feature; triaging community questions in Discord and escalating product bugs via GitHub; preparing a conference talk abstract or delivering a live workshop; synthesising developer feedback into a prioritised product input document for the PM; and reviewing a new API design for developer ergonomics. The breadth is the appeal — and the exhaustion risk.
Remote DevRel specifically lives on async: detailed written feedback on product decisions, high-quality documentation contributions, and active forum presence replace the hallway conversations that office-based DevRel relies on. Strong async written communication is not optional.
Six things worth checking before you apply
- Reporting line. DevRel that reports to Engineering produces different work than DevRel that reports to Marketing. Engineering-reporting DevRel tends to have more DX influence; Marketing-reporting DevRel tends to have more content and event budget. Both are legitimate — know which model you are walking into.
- Metrics. Ask what DevRel is measured on. Vague answers signal that the company has not thought through what it wants. Specific answers (activation rate, tutorial completion, SDK download velocity) signal operational maturity.
- Travel expectation. Conference-heavy DevRel roles can involve 20–40% travel even for "remote" positions. Clarify the expected conference budget and cadence before accepting.
- Feedback loop to product. Ask how developer feedback from the community reaches the product team. A structured intake process signals that the company takes DevRel's product intelligence function seriously.
- API or product maturity. A v0.9 API or an unstable SDK is very hard to advocate for honestly. Ask about the stability roadmap — it directly affects your credibility with the developer community you are trying to cultivate.
- Team size. A solo DevRel hire at a company with no prior DevRel history requires building the function from scratch — strategy, metrics, tooling, and content infrastructure — before doing any of the visible work.
The bottleneck is always credibility
Developer relations fails when the people doing it are not credible to the developers they are serving. Engineers have a finely calibrated detector for marketing dressed as technical help. DevRel professionals who cannot write real code, who have not shipped real things, or who cannot admit product limitations publicly will lose the community's trust quickly — and it is very difficult to recover.
The best DevRel practitioners maintain their own technical practice deliberately: they write sample apps, file real bug reports, participate genuinely in open source, and keep their coding skills current. The visibility of the role amplifies both credibility and credibility failures, so the investment in staying technically sharp is directly tied to the role's effectiveness.
What the hiring process looks like
Remote DevRel hiring typically involves: (1) recruiter screen on technical background and community experience; (2) a take-home exercise, usually writing a short tutorial or explaining a technical concept to a target audience; (3) a portfolio review — blog posts, talks, GitHub activity, community contributions; (4) a technical interview that may include a live coding exercise or a mock workshop delivery; (5) cross-functional interviews with a PM and an engineer who works closely with DevRel. The take-home and portfolio review are the differentiating steps. Candidates without a public body of work — no blog, no talks, no GitHub activity — face an uphill battle regardless of how well they interview.
Gateway to current listings
RemNavi does not post jobs. We pull them from public sources and link straight through to the employer, so you apply at the source every time.
Frequently asked questions
What is the difference between developer relations and developer advocate? Developer advocate is usually a specific role within the broader developer relations function. Developer relations is the team or discipline; developer advocate is often the individual contributor title for the outward-facing community and content work. Some companies use the terms interchangeably. At larger companies, the DevRel team may include developer advocates, developer experience engineers, and technical writers as distinct roles.
Do you need to be a software engineer to work in developer relations? Not always, but you need genuine technical credibility. Most successful DevRel professionals have an engineering background and can write and understand real code. The depth required varies by company — API-first companies expect hands-on coding ability, while platform companies with visual interfaces may require less. If you cannot use the product as a developer yourself, you cannot credibly represent it to developers.
Is developer relations a marketing or an engineering role? It depends on the company, but most mature DevRel functions sit closer to engineering or product than to marketing. The credibility of the function depends on independence from commercial messaging. DevRel that is structurally subordinated to marketing tends to produce content that developers perceive as promotional, which defeats the purpose.
What does career progression look like in developer relations? Common paths: senior DevRel → staff DevRel → head of DevRel → VP of developer experience. Lateral moves into product management, technical program management, or engineering leadership are also common, because the cross-functional exposure makes DevRel professionals effective in product roles. At smaller companies, the DevRel function often reports to the CTO until the team reaches four or five people.
RemNavi pulls listings from company career pages and remote job boards, then sends you straight to the employer to apply. We do not host the listings ourselves, and we do not stand between you and the hiring team.
Related resources
- Remote Developer Advocate Jobs — The most common individual contributor title within DevRel; deep overlap with this role
- Remote Technical Writer Jobs — Documentation-focused role with strong overlap on the content side of DevRel
- Remote Solutions Engineer Jobs — Technical customer-facing role; adjacent to DevRel in developer-tool companies
- Remote Product Manager Jobs — The primary internal partner; DevRel product feedback loops run through the PM
- Remote GTM Engineer Jobs — Technical go-to-market role; related function in developer-led growth companies