Developer relations is the human layer of developer marketing: the people and programs that build a trusted relationship between your company and the developers you serve. Done well it compounds — every talk, tutorial, and answered question keeps working long after it ships. Done badly it’s an expensive events calendar. The difference is whether it’s built around genuine developer value or around short-term lead capture.

What DevRel is for

Most functioning DevRel programs balance three jobs:

  1. Advocacy (outbound) — meeting developers where they are: talks, tutorials, sample apps, streams, conference presence. The goal is awareness and trust, not a pitch.
  2. Education (enablement) — docs, workshops, courses, office hours, reference architectures. This is where interest becomes competence and competence becomes adoption.
  3. Feedback (inbound) — carrying the developer voice back into product. DevRel sits closest to real usage; a program that doesn’t feed the roadmap wastes its best signal.

A program that’s all outbound becomes a hype machine with no substance. All education and no advocacy stays invisible. The feedback loop is what earns DevRel a seat at the product table.

Community that compounds

Community is not a Discord server you open and hope. It’s a place where developers get value from each other, with your team as gardeners, not broadcasters.

  • Seed with utility. People show up for answers, examples, and early access — not for your brand. Give them a reason that isn’t you.
  • Answer fast, in public. A visibly responsive team turns a support channel into a trust-building asset that new developers read like reviews.
  • Recognize contributors. Champions, ambassadors, and expert programs work when the recognition is real (access, reputation, revenue) rather than swag. The platform-scale version is a verified record: Stack Overflow relaunched Developer Story in September 2026 as the base of a “Stack Identity” layer, and gave the reason every content community now faces — people “don’t need to come directly to Stack Overflow anymore” for answers because “the chatbots have that covered”. A track record only you can verify is an asset a model cannot paraphrase away; what shipped is self-written specialties, with verified cross-site contributions promised rather than delivered.
  • Reduce the cost of contribution. Good “good first issues”, clear contribution guides, and templates turn goodwill into pull requests.

Your contributors are agents now

A growing share of inbound contributions are AI-assisted or fully agent-written, and the projects handling it well govern rather than improvise. The working pattern, per GitHub’s own maintainer guidance (August 2026, drawn from AutoGPT’s experience): put instructions where agents actually look — an AGENTS.md beside the code, not a distant CONTRIBUTING page — enforce PR templates strictly with auto-close on non-compliance, make CI coverage thresholds required checks, and keep one deliberately human step (a CLA browser flow works) as a checkpoint. The norm now has its first landmark ruling: Debian put its AI-contribution policy to a binding project-wide vote in August 2026 — eight options, from outright ban to disclosure-conditioned acceptance — and “Responsible Use of Generative AI” won (result announced 2026-08-30): disclosure encouraged but not required, contributors fully responsible for reviewing AI-generated material, and mass automated changes expected to seek prior discussion and consensus. The largest project to decide chose governance over prohibition, which is the posture the pattern above assumes. The countertrend still exists — the Emacs project drafted an AGENTS.md that restricts agents rather than enabling them — and a community without a written policy inherits whichever norm wins elsewhere; deciding per-PR is the one approach that scales worst.

Events are advocacy with a venue

Conferences, meetups, hackathons and workshops sit inside the advocacy job, and they are the most expensive thing on this page per developer reached. The discipline that makes them pay is deciding the objective before booking: a launch moment, time with existing customers, contributors for the project, or a community that meets in person once a year. “Awareness” is the objective teams name when they have not chosen one, and it is the one nobody can grade afterwards. Prefer the small, specific event where your developers already are — the working-group meetup, the framework’s own conference — to the large one where you are a logo on a lanyard, and treat a workshop that ends with attendees having built something as the format that converts, because it is the quickstart delivered by a person. Staffing them past the DevRel team is the constraint, and PostHog’s programme (September 2026, self-reported, no pipeline figure published) is the working answer: 1 to more than 100 in-person events in a year with over half the company demoing and about 95% of events involving direct customer conversations, with no mandate and no speaker training — the events team proposes the slot, funds travel, ships merch, slides and demo guidelines, and a GitHub-reading skill turns an engineer’s recent commits into candidate talk titles. At least a fifth of staff declined and that is treated as normal; the mechanics are the copyable part, the counts are one company’s.

Don’t measure DevRel like sales

The fastest way to kill a DevRel program is to put a monthly lead quota on it. Advocates start optimizing for capture over trust, and the audience feels it immediately. DevRel’s value is largely leading-indicator and influence: developers reached, activated, and retained; sentiment; contribution; influenced pipeline. Measure those; measurement covers how without pretending everything is directly attributable.

Advocates are expensive and hard to hire, and protecting their time from becoming an unpaid support queue or a sales-demo bench is a staffing decision as much as a programme one — team, budget and stage has the numbers and the hiring order.