Read our latest article: "devrel.directory is back"

devrel.directory

Content Creation

Planning, writing, and distributing developer content that actually gets used, from quickstarts to long-form guides, with a pipeline a small team can sustain.

Content is leverage

For most DevRel teams, content is the highest-leverage activity available. A good guide works around the clock, scales without headcount, and compounds: through search for years, and now through AI assistants that answer developer questions with whatever material explains the problem best.

The bar, however, has moved. Developers skim, verify, and bounce fast, and generic content is now free to produce and therefore worthless. What earns attention is content that is specific, runnable, and honest about tradeoffs.

Content types and the job of each

Different formats do different jobs. Confusing them is how docs end up with tutorials that read like reference and blog posts that read like ads.

  • Quickstart: from zero to one working call in minutes. Job: prove the product works and respect the reader's time.
  • Tutorial: a guided path to a meaningful outcome, with the reader following along. Job: teach by doing.
  • How-to guide: a focused recipe for one task the reader already understands. Job: unblock.
  • Conceptual explainer: how the system thinks, its model and its boundaries. Job: build the mental model that prevents the next ten questions.
  • Reference: exhaustive, accurate, boring on purpose. Job: answer precise questions precisely.
  • Blog essay: opinion, experience, architecture stories, honest postmortems. Job: reach and trust, especially with people not yet using the product.
  • Video and livestreams: demos, walkthroughs, launch streams. Job: show real usage, including the stumbles; the recording becomes an asset.
  • Example repositories: complete, running applications developers can clone. Job: be the starting point people actually build from.

The Diátaxis framework formalizes much of this split and is worth reading once. Use it as a lens, not a bureaucracy.

Writing for developers

The craft rules that separate content developers use from content they close:

  1. Lead with working code. Developers read prose to understand the code, not the reverse.
  2. Make every snippet copy-paste complete: imports, versions, and setup included, no invisible prerequisites.
  3. Show exact error messages. Errors are what people search for; matching their text verbatim is free search traffic and instant recognition.
  4. State versions and dates. Nothing destroys trust like a tutorial that silently broke two releases ago.
  5. Write for scanning: descriptive headings, short paragraphs, code blocks with language tags, one idea per section.
  6. Keep marketing out of the critical path. A quickstart that pauses to celebrate the product loses the reader at the pause.
  7. Edit ruthlessly. First drafts explain what you did; good drafts explain what the reader needs.

Test every tutorial by following it yourself in a clean environment, top to bottom, before publishing. Every step where you improvise is a step where readers get stuck.

These same properties (self-contained sections, exact errors, runnable snippets) are also what make content usable by AI assistants, which increasingly sit between your docs and your developers. Writing Docs LLMs Can Use covers that shift in more depth.

Distribution: where content meets developers

Publishing is not distribution. A realistic distribution model for a developer audience:

  • Search is the durable channel. Target the problem queries developers actually type, including error messages, not brand terms.
  • Your own channels are the asset you keep: docs, blog, newsletter, RSS. Every platform channel is rented ground.
  • Social platforms reward channel-native formats. A link dump performs poorly everywhere; a short standalone insight with the link in follow-up performs fine on most platforms.
  • Developer norms punish growth hacks. No engagement bait, no fake questions, no reply-guy automation; disclose who you are, as in community spaces.
  • Consistency beats virality. One useful post a week for a year outperforms one lucky hit, and it is plannable.

The repurposing tree makes one effort feed many channels: a conference talk becomes a blog post, the post becomes a code sample, the sample becomes three short posts and a newsletter section. Plan the tree when you plan the talk, not after.

A pipeline a small team can sustain

Content programs die of ambition more often than laziness. A sustainable loop for a team of one or two:

  1. Intake: keep one list fed by community questions, support tickets, sales objections, and release plans. Recurring questions are commissioning briefs someone already wrote for you.
  2. Selection: pick by audience impact and search demand, not internal excitement.
  3. Cadence honesty: commit to the rhythm you can hold on a bad week. Biweekly and reliable beats weekly and abandoned by March.
  4. Technical review: every piece gets an accuracy pass from someone close to the code.
  5. Publication checklist: metadata, code tested, links checked, one internal link to related material.
  6. Refresh loop: revisit the top pages quarterly; updating a high-traffic guide usually beats writing a new one.

Measuring content

Content measurement is directional, not precise, and pretending otherwise erodes trust in every number you report.

Leading indicators:

  • Search rankings and impressions for the problem queries you target.
  • Traffic to problem-solving pages, weighted by whether the page is on the adoption path.
  • Quickstart and tutorial completion, if instrumented.

Lagging indicators:

  • Content-assisted signups and activation: accounts whose session history touched key content before converting.
  • Recurring support questions disappearing after the answering guide ships.

Attribution will be incomplete: developers read on one device and sign up on another, and AI assistants increasingly consume content on their behalf. Report ranges and trends, note the blind spots, and set targets with explicit measurement definitions as in the OKR planning guide.

Pageviews alone reward clickbait. Pair every traffic number with a behavior that indicates the reader got somewhere.

Sources & References:

Edit on GitHub

Community Building

How to start, grow, and sustain a developer community, from the first fifty members to programs that scale, plus how to show up well in communities you do not own.

Contributing to devrel.directory

What contributions are welcome, how changes land, and the editorial bar every page has to clear.

On this page

Content is leverageContent types and the job of eachWriting for developersDistribution: where content meets developersA pipeline a small team can sustainMeasuring contentRelated