Content is one of the most-consumed outputs of a DevRel programme. Its value depends on whether it answers a real developer question, reaches the relevant audience, and remains accurate after publication.
What “content” covers
For DevRel purposes, content includes:
- Documentation (covered separately in Documentation as product).
- Blog posts and long-form writing.
- Tutorials and quickstarts.
- Sample applications and demo repositories.
- Video (tutorials, conference talks, screencasts, shorts).
- Podcasts (own and guest appearances).
- Newsletters.
- Social posts (X, Bluesky, LinkedIn, Mastodon).
- Webinars, livestreams, and event recordings.
Coordinate these formats through a shared editorial calendar and a regular planning meeting.
The four jobs content does
Map every piece of content to at least one of these jobs:
- Awareness. Reach developers who do not yet know your product exists.
- Activation. Help developers who have signed up successfully use the product.
- Retention. Help developers go deeper or solve new problems with the product.
- Trust / authority. Demonstrate relevant technical knowledge through accurate explanations and working evidence.
Do not produce a piece that serves none of these jobs. Record each intended job before production so that distribution and measurement follow from it.
(For a more granular goals model, see AAARRRP framework.)
Content formats and what they’re good for
| Format | Primary job | Strengths | Costs |
|---|---|---|---|
| Reference docs | Activation, retention | Always-on; AI-readable | High maintenance |
| Quickstart | Activation | Drives first hello-world | Must be perfect; high stakes |
| Tutorial (written) | Activation, awareness | SEO-friendly; long shelf life | Time-consuming |
| Long-form essay / thought piece | Awareness, trust | High shelf-life; reach | Risk of empty thought leadership |
| Comparison / benchmark | Awareness | High click-through; HN-friendly | Must be honest |
| Sample app | Activation | Highest signal of “yes, you can build with this” | Expensive to maintain |
| Video tutorial | Awareness, activation | YouTube search; broad reach | Production cost |
| Short video (60-second) | Awareness | Algorithmic boost; share-friendly | Hard to do well |
| Live stream | Trust, awareness | Authentic; community-forming | Slow audience growth |
| Conference talk | Awareness, trust | Compounds (recordings); credibility | Travel cost |
| Podcast guest | Awareness, trust | High-trust reach | Time |
| Podcast (own) | Trust, retention | Brand build | Slow; high failure rate |
| Newsletter | Retention, awareness | Direct relationship | Cadence demand |
| Case study | Trust, awareness | Credibility | Requires customer cooperation |
| Release notes | Retention | Required if you ship | Should be excellent |
Diátaxis: a useful documentation framework that applies broadly
Daniele Procida’s Diátaxis framework distinguishes four documentation types by user need:
- Tutorials. Guided lessons. Goal: learning.
- How-to guides. Recipes. Goal: solve a specific problem. Concise.
- Explanation. Background. Goal: understanding. Why something exists.
- Reference. Information. Goal: lookup. Comprehensive and exact.
Most DevRel content failure traces to mixing these. A “tutorial” that is actually reference is unhelpful for learning; a “reference” that is actually explanation is unfindable when you need an answer.
Apply Diátaxis to docs and other content. A blog post is usually a how-to or an explanation, and occasionally a tutorial. Be explicit which.
Voice and authorship
- Credit named authors. The reader should know who wrote the technical claims.
- Publish engineers’ own explanations under their names. Do not present ghostwritten opinions or experiences as their work.
- Provide author information. A bio and relevant links establish expertise and give readers a route for questions or corrections.
SEO discipline
- Target a specific search query per long-form piece.
- Avoid keyword stuffing. It makes prose repetitive and less useful to readers.
- Optimise for the question. “How do I deploy Next.js to AWS?” expresses intent more clearly than “AWS Next.js deployment.”
- Update old content. A 2021 post that ranks well is a maintenance opportunity, not a finished project.
- Internal linking matters. Every post should link to 3 to 5 other posts on your site.
AI-readiness
From 2024 onward, content is consumed by both humans and LLMs. Practical implications:
- Use semantic HTML / Markdown. Clear headings, lists, tables.
- Be explicit about versions and dates.
- Code samples should be runnable and complete.
- Avoid burying key information in images without alt text.
- State conclusions early. AI assistants extract the first informative paragraph.
Distribution
Publication does not supply distribution. Assign channels and an owner for each long-form piece.
For every piece of long-form content, plan distribution:
- Your own newsletter.
- Cross-post to dev.to / Hashnode with canonical URLs.
- LinkedIn carousel or essay version.
- X / Bluesky thread or post.
- Reddit (in appropriate subreddit, if the post is genuinely useful).
- Internal Slack channels asking employees to share.
- Targeted email to high-relevance individuals.
- (Where appropriate) Hacker News submission.
Distribution needs its own plan and owner alongside editorial quality.
Cadence
- Choose a cadence the team can sustain.
- Set a publishing schedule the team commits to.
- Front-load batched recording (video, podcast) to absorb production variance.
- Maintain a 4 to 6-week content calendar.
Content audit
Once a year, audit existing content:
- Remove or update anything stale.
- Identify your highest-performing pieces and test whether their format works for another relevant subject.
- Identify topical gaps.
- Consolidate duplicates.
Measure the corpus by current coverage rather than post count: update or remove dated material.