DevRel Field Notes: Build Review Into the Work

This week’s examples point to a useful DevRel habit: make rehearsal, evaluation, and honest reporting part of the work instead of treating them as final checks.

Publishing is visible. Review usually is not. That can make it tempting to protect the production schedule first and squeeze testing, rehearsal, and follow-up into whatever time remains.

I think that order is backwards. The review work is where a team discovers whether a tutorial can be followed, whether a live demo is ready, and whether an explanation matches what the product actually does. If those checks happen late, they become a gate. If they happen throughout the work, they improve the content.

For this edition, I looked at three examples from the week ending September 11. They come from different parts of the developer ecosystem, and I am not presenting them as a measured industry trend. Together, however, they offer a useful way to think about managing content quality.

Rehearsal should be an ordinary part of live content

YouTube’s creator update page now describes Live Practice Mode, a private space in its mobile app where creators can rehearse their setup and content, then begin the live stream when they are ready. Read the YouTube creator update.

The product feature is new, but the management lesson is familiar. A technical livestream deserves rehearsal time in the plan. That time should cover more than microphones and screen sharing. The presenter should run the demo from a clean state, identify the moments that need explanation, and decide what to do if a service or sample fails.

I would also use rehearsal as coaching, not merely inspection. The goal is to help the presenter find the simplest route through the material while keeping their own voice. A manager can watch for assumptions that an expert no longer notices: an unexplained tool, an account that is already configured, or a command whose result arrives too quickly to follow.

A private run also gives the team a chance to decide whether live is the right format. If the useful part is a precise sequence of steps, a written guide may be easier to revisit. If the value is seeing someone diagnose a surprise and answer questions, live video may be exactly right.

Evaluate the behavior you actually care about

On September 9, the Google Developers Blog published The Anatomy of Harness Engineering. Its summary argues for small behavioral evaluations that check discrete actions, such as tool calls or file changes, alongside broader end-to-end benchmarks. Read the Google Developers post.

That idea transfers well to developer education. A team can evaluate an article by asking whether it exists, whether the links work, and whether the sample builds. Those checks matter, but they do not tell us whether a developer understands when to use the approach or can recover from a common mistake.

For each important piece, I would define a few observable behaviors before production. Can a reader find the prerequisite? Can a viewer pause at a meaningful point and reproduce the step? Can someone explain the tradeoff after finishing? These are small checks tied to the job of the content.

This changes the editorial conversation. Instead of debating whether a draft “feels clear,” the writer and reviewer can look at where a test reader hesitated. The evidence will still be limited, especially with a small review group, but it gives the team a concrete problem to fix.

Trust grows when the difficult result is included

GitHub published its August availability report on September 9 and stated that five incidents caused degraded performance during the month. See GitHub’s latest posts and the availability report.

An availability report is operational communication rather than a tutorial, but it belongs in a broader developer content strategy. Developers form an opinion of a platform through its documentation, examples, support, release notes, and incident communication. A polished launch post cannot carry trust by itself.

For a DevRel manager, this means maintaining a relationship with the teams responsible for documentation, support, product communication, and reliability. DevRel should not invent the technical account of an incident. It can help surface the questions developers are asking, identify terms that need explanation, and make sure useful follow-up reaches the same audience that saw the disruption.

The same principle applies at a smaller scale. If a tutorial relies on a preview feature, say so. If a workaround has a cost, include it. If a demo only covers the happy path, tell the viewer where to look next. Completeness does not require documenting every possible failure. It requires being honest about the boundaries that affect the reader’s decision.

Plan for learning, not just output

These examples push me toward a simple operating model for a DevRel content team. Every substantial piece should have a short quality plan before production begins:

1. Name the developer outcome.
2. Rehearse or test the path from a clean starting point.
3. Record the assumptions, limitations, and likely failure points.
4. Decide who will watch questions and feedback after publication.
5. Bring what the team learns into the next brief.

This requires allocation choices. A calendar with every hour assigned to creating new assets leaves no room to improve them. I would reserve explicit capacity for technical review, rehearsal, accessibility, and post-publication follow-up. I would also protect creators from the idea that finding a flaw during review means they failed. Finding it before the audience does is the review process working.

The metrics should reflect that goal. Alongside reach and engagement, I would track corrections, repeated questions, sample failures, and the time it takes to answer a meaningful issue. I would look for patterns across several pieces rather than drawing a conclusion from one comment or one week.

My experiment for the coming week would be to take one planned tutorial and write three behavioral checks before drafting it. Give the finished piece to one developer who was not involved in production. Watch where those checks pass or fail, then revise the content before publishing.

Where in your content process does useful review happen today, and what would make it happen earlier?