DevRel Activities

The activity map

DevRel work becomes visible through activities: the talks, posts, community threads, and feedback loops a team runs week after week. Activities are not a strategy. A strategy decides which developers you serve and what outcome the business needs; activities are how you get there.

The most common failure mode in DevRel is activity soup: doing a little of everything because everything is defensible. A team stuck in activity soup is always busy, rarely measurable, and first in line when budgets tighten.

This page maps the core activity clusters, what each one is good for, and how to choose between them.

The six clusters

1. Content

Writing and producing material developers use to evaluate and adopt your product: quickstarts, tutorials, guides, reference material, blog posts, videos.

Content is the highest-leverage activity for most teams because it scales without headcount and compounds over time through search and, increasingly, AI assistants. It earns its place from day one.

Signals it is working: rising traffic on problem-focused queries, quickstart completion, content-assisted signups. Failure mode: publishing what the company wants to say instead of what developers are trying to do.

The full practice has its own page.

2. Community

Creating and tending the places where developers using your product help each other: your own space, and your presence in spaces you do not own.

Community compounds like a network: every answered question becomes searchable capital, and every active member lowers the load on the next one. It earns its place once there is a steady stream of real users asking questions, and not before.

Signals it is working: falling time-to-first-answer, member-answered questions, returning participants. Failure mode: opening a Discord because everyone has one, then presiding over an empty room.

The full practice has its own page.

3. Speaking and events

Conference talks, meetups, workshops, webinars, and hackathons: high-touch moments where a person represents the product to a room.

Events create trust and reach density that content alone cannot, and they generate raw material for weeks of derivative content. They earn their place when you know which audience attends and what you want them to do afterwards.

Signals it is working: qualified conversations, workshop completions, follow-up adoption you can trace to the room. Failure mode: conference-driven development, where the calendar sets the roadmap and the team measures itself in booth hours.

4. Developer feedback and product influence

The inward-facing half of DevRel: collecting what developers struggle with and turning it into product and documentation changes.

This is the activity that separates DevRel from marketing. It earns its place immediately, because it makes every other activity smarter, and it is how the team proves value to engineering and product peers.

Signals it is working: filed issues that get fixed, roadmap items traceable to community input, shrinking lists of repeated questions. Failure mode: collecting feedback into a document nobody reads, which quietly teaches developers that talking to you changes nothing.

5. Developer experience work

Improving the product's first-run path: onboarding flows, error messages, sample apps, SDK ergonomics, and the documentation surrounding them.

Some organizations make this its own role, as covered in roles and responsibilities. It earns its place when the data shows developers stalling between signup and first success.

Signals it is working: time-to-first-successful-call going down, fewer support tickets on setup steps. Failure mode: shipping polish for the demo path while the real integration path stays rough.

6. Ecosystem and partnerships

Integrations, co-marketing with adjacent tools, guest content, and champion programs that give your most invested users a bigger stage.

Ecosystem work multiplies reach through other people's audiences. It earns its place after the basics work: partners amplify a good developer experience, they cannot fix a bad one.

Signals it is working: adoption arriving through integration paths, champions producing content you did not ask for. Failure mode: logo-collecting partnerships that produce a press release and nothing else.

Choosing activities by journey stage

Different activities move different stages of the developer journey. Start from where developers actually drop off, which your personas work should tell you.

• Awareness: talks, essays, podcasts, and being genuinely useful in external communities.
• Evaluation: comparison-friendly docs, honest quickstarts, sample apps that resemble real use.
• Activation: onboarding fixes, error message work, time-to-first-success instrumentation.
• Retention: release communication, changelogs, office hours, community support.
• Advocacy: champion programs, showcases, conference CFP support for community members.

If you cannot name the stage an activity serves, it is probably serving the calendar.

A sample week for a team of one

A realistic split for a solo DevRel practitioner with a shipped product and an early community:

1. Two mornings on content: one substantial piece in progress at all times.
2. One hour a day in the community and support queue, answering and logging patterns.
3. One afternoon on feedback synthesis: turn the week's questions into two or three concrete product or docs issues.
4. One afternoon on developer experience: fix the single worst snag developers hit that week.
5. A monthly, not weekly, slot for events and partnerships.

The exact split matters less than the discipline: recurring blocks, one owner, one measurable signal per activity.

Prioritization heuristics

• Few over many: two activities done every week beat six done occasionally.
• Repeatable over spectacular: a talk is a moment, the recording plus the write-up is an asset.
• Measurable over comfortable: prefer the activity whose effect you can observe, even roughly, using goals set the way the OKR planning guide describes.
• Downstream of strategy: when someone requests an activity, ask which goal it serves before asking when.
• Keep a stop-doing list: every quarter, name one activity you are ending and say why.

Related

• Crafting a DevRel strategy for deciding which goals the activities serve
• Content creation and community building for the two deepest clusters
• The importance of DevRel for the business case behind the work

---

Sources & References:

• The Business Value of Developer Relations by Mary Thengvall | Apress, 2018
• The AAARRRP Developer Relations Strategy Framework by Phil Leggetter | 2017
• Developer Relations: How to Build and Grow a Successful Developer Program by Caroline Lewko and James Parton | Apress, 2021