“What makes a good DevRel?” usually gets a personality answer: curious, empathetic, good on stage, writes well, ships code, loves community. Those traits help. They are not a definition of the job.
Good DevRel is a system for helping developers succeed with a technology — and helping the organization that funds that work survive contact with reality. The system looks different if you sit inside a product company versus an open source project, but the craft underneath is shared.
This essay is a practical bar. Use it to assess yourself, hire better, or decide whether your project actually needs “DevRel” or just better docs and a release process.
First: name the context
Industry language helps here. Developer First (B2D) companies sell primarily to developers — Twilio, Stripe, MongoDB, Unity. Developer Plus companies sell to businesses or consumers and also offer APIs, SDKs, or platforms (Apple, Salesforce, banks with developer portals). Open source projects may power either, or stand alone as community infrastructure with a thin commercial layer.
Context changes your scoreboard, your politics, and how much time you spend educating internal stakeholders versus external developers. Ignoring context is how good people get rated on the wrong game.
| Product company DevRel | Open source DevRel / maintainer-as-DevRel | |
|---|---|---|
| Primary job | Adoption + successful usage of a product | Healthy contributors + successful users of a project |
| North-star examples | Activation, monthly active developers, PQLs, expansion influence | Active contributors, issue quality, release adoption, ecosystem integrations |
| Main risk | Becoming expensive marketing cosplay | Burning maintainers / extractive “community” |
| Credibility source | Product truth + peer trust | Contribution history + fair process |
| Internal work | Heavy (Sales, Product, Marketing alignment) | Heavy (maintainers, foundation/company, CODEOWNERS) |
The shared craft: five capabilities that always show up
Whether you wear a company badge or a maintainer hat, the people I respect share these capabilities. Not “soft skills.” Capabilities you can practice and evidence.
1. Technical empathy with receipts
You can reproduce a developer’s failure mode. You know what “works on my machine” actually means in your stack. You do not hand-wave around setup pain. Empathy without technical depth becomes cheerleading. Technical depth without empathy becomes gatekeeping.
Evidence: a debug session write-up, a fixed sample app, a docs PR that removed three common errors, a workshop where 80%+ of attendees finished the path.
2. Teaching that creates independence
Good DevRel reduces the need for DevRel. Your content, samples, and office hours should make the next developer faster without you in the room. That is the difference between a hero support act and a scalable program.
Prefer paths over posts. Prefer runnable examples over abstract architecture diagrams. Prefer “here is the failure and the fix” over “here is why our product is exciting.”
3. Two-way advocacy
Outbound: put the technology in front of the right developers, in the right depth, at the right time. Inbound: carry developer reality into the people who can change the product or project.
Most teams over-index outbound because it is public. The mature ones protect inbound bandwidth and track whether feedback ships. If nothing ever ships, you do not have a feedback loop — you have a suggestion box.
4. Taste for channels that match the half-life
Not every message belongs on every platform. Social posts die in hours. Blog and docs compound for years. Workshops create depth. Conferences create proof and distribution if the talk is good enough to watch later. Good DevRels choose channels with intent instead of filling a content calendar for its own sake.
5. Measurement without self-betrayal
You can translate work into language leadership understands without turning relationships into pure pipeline. That means keystone metrics, leading indicators (time-to-first-value, activation, contributor first PR), and qualitative stories that explain the numbers — not vanity dashboards that impress nobody who funds you.
What “good” looks like inside a product company
Company DevRel fails when it becomes either a roadshow or a support ticket sink. It succeeds when it tightens the loop between product quality, developer activation, and durable trust.
A good company DevRel program usually includes:
- Clear org type awareness — Developer First vs Developer Plus changes messaging and metrics.
- An owned activation path — docs + samples + one “golden path” you improve continuously.
- A content system — not random posts; a series that maps to evaluation and implementation stages.
- Community with a purpose — support deflection is fine; free unpaid labor as a KPI is not.
- Stakeholder contracts — what Sales gets, what Product gets, what you will not become.
- A QBR narrative — activation, engagement quality, business impact — in executive language.
Company-specific skills that separate seniors
- Writing a 90-day plan leadership will fund
- Saying no to conference spam without becoming political dead weight
- Partnering with product marketing without dissolving into it
- Turning a customer conversation into a reusable teaching asset
- Knowing when PLG and docs beat another webinar
What “good” looks like in open source
Open source DevRel (or maintainers doing DevRel work without the title) fails when “community” means extraction: more users, more issues, more drive-by demands, same number of burned-out maintainers. It succeeds when more people can contribute safely and users can succeed without opening a crisis issue.
A good OSS DevRel posture usually includes:
- Contribution pathways — good first issues that are real, not toys; clear review norms.
- User education — tutorials and migration guides that reduce support load.
- Governance literacy — who decides, how RFCs work, how to disagree in public.
- Ecosystem work — integrations, examples in popular frameworks, conference education tracks.
- Health metrics that respect humans — contributor retention, review latency, release quality — not star cosplay.
OSS-specific skills that separate seniors
- Writing contribution docs that new people finish
- Moderating conflict without turning the project into a brand page
- Balancing corporate sponsor interests with project integrity
- Recognizing when “community growth” is actually support debt
- Building champions programs that give status and access, not swag-for-spam
The anti-patterns (both worlds)
| Anti-pattern | What it looks like | What good replaces it with |
|---|---|---|
| Conference tourism | Travel-heavy calendar, thin follow-up | 1–2 high-quality talks + recorded assets + local depth |
| Content mill | Volume without paths or maintenance | Fewer pieces, longer half-life, kept up to date |
| Support cosplay | DevRel as free L2 forever | Patterns → docs/product fixes; escalation rules |
| Metric theater | Stars, members, impressions only | Activation, contribution quality, DRQLs, retention |
| One-way evangelism | All outbound, no product loop | Tracked feedback that ships |
A simple self-assessment
Score yourself 1–5 on each. Be cruel. Inflation helps no one.
- I can take a new developer from zero to first success on our golden path without live screenshare heroics.
- I ship teaching assets that stay correct for more than one release cycle.
- I maintain a written list of top developer pains with evidence, not vibes.
- At least one product/project decision per quarter moved because of signal I brought.
- I can explain my work to a CFO-level audience without only citing impressions.
- Developers trust me as a peer, not a billboard.
- I protect deep work and have explicit non-goals for the quarter.
- (OSS) New contributors can land a meaningful first PR without private DMs to me.
- (Company) Sales/Product know what I own and what I refuse.
- I am getting better at one specialty (content, community, product/DX, education) instead of being mediocre at twelve.
Under 30: you are early — pick one path and go deep. 30–40: solid operator. 40+: you should be mentoring others and writing the standards your org lacks.
What it takes (the short version)
Good DevRel is not “being social online about technology.” It is the disciplined practice of making developers successful at scale, with enough organizational skill that the practice still exists next budget cycle.
In a company, that means activation, trust, and product loops under a clear charter. In open source, that means contribution health, user success, and maintainer sustainability under fair process. The costume changes. The craft does not.
If you want the field to be taken seriously, raise the bar past personality. Hire for systems. Practice like the developers you serve are watching — because they are.