Michael Crump

DevRel Field Notes: Build Review Into the Work

2026-09-15T00:44:32+00:00

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:

Name the developer outcome.
Rehearse or test the path from a clean starting point.
Record the assumptions, limitations, and likely failure points.
Decide who will watch questions and feedback after publication.
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?

DevRel Field Notes: Help Developers Decide What to Do Next

2026-09-04T17:59:24+00:00

A newsletter, a beginner tutorial, and a developer community story offer three useful prompts for deciding where a DevRel team should spend its time.

I want developer content to leave someone with a clearer next step. That sounds straightforward, but it is a demanding standard for a content calendar. A post can explain a feature accurately and still leave the reader wondering whether it belongs in their work. A video can be entertaining without giving someone enough context to try what they watched.

For this first edition, I looked at examples from the week ending September 4. Three caught my attention. They are individual editorial choices, not evidence that an entire channel is growing or declining. What interests me is what I would borrow from them when planning and reviewing a DevRel team's work.

Give the newsletter reader a reason to choose

The September 3 edition of Console features llgo and Tailcat, with a short assessment of each tool's strengths and limitations. Its llgo review includes a caution about the cost of mapping goroutines to operating-system threads. The newsletter also offers RSS alongside email. Read Console's latest edition, which was dated September 3 when reviewed.

The useful editorial choice here is making room for a drawback. A reader gets help deciding whether to investigate, rather than another item to add to an already long reading list.

I would bring that standard into a newsletter review: Who is this useful for? What would make someone pass? What should they investigate before adopting it? If the writer cannot answer those questions, I would give them time to test the tool or talk with someone who has.

That is also a coaching decision. We should make it comfortable for creators to include an honest limitation, especially when they are covering a product their team cares about.

Make the tutorial's next step small

On September 3, Kayla Cinnamon published a beginner guide to running several agents in the GitHub Copilot app. It explains separate sessions and Git worktrees, then walks through an example involving a feature, an accessibility review, and tests. The closing suggestion is to start with two small tasks. Read the GitHub guide.

I like the bounded invitation. The reader has something specific to attempt after finishing the article. That is a useful pattern for technical blogs and for a YouTube demo: explain the idea, show a concrete use, then offer a manageable first attempt.

My own addition to a content brief would be a clear success check. What should the developer inspect before trusting the result? Where could the example fail? A polished demonstration should make those questions easier to answer.

As a manager, I would rather review that learning sequence early in an outline than discover during the final edit that the piece has no clear destination.

Leave room for the people behind the tools

The September 2 VS Code release notes promote The Story of VS Code, with a premiere scheduled for September 4 at 8 a.m. Pacific. The description points to the project's beginnings and the community that helped shape it. This is an observation about the announcement and its placement; I have not evaluated the film or its audience response. See the release notes and premiere announcement.

Putting that invitation inside release notes is an interesting distribution choice. Developers arriving for product changes also encounter the people and history behind the product.

For a DevRel video calendar, I would keep some space for that kind of story. A maintainer explaining a difficult design decision could be valuable alongside a walkthrough. I would start with a specific person and a specific question, then choose the production effort the story deserves.

One announcement does not establish a YouTube trend. It does give me a reason to ask whether a content program shows enough of the community that makes its tools possible.

The management work is choosing and following through

Taken together, these examples push me toward a practical editorial rule: every piece should help a defined audience make progress, and the team should be able to explain what that progress looks like.

I would put that discussion before the channel discussion. Start with a developer's question. Decide whether it needs a demonstration, a reference they can scan later, or a short recommendation. Sometimes it will need more than one format, but each version should have a job of its own.

That also means reserving time for the work surrounding publication. Someone needs to check the sample, answer the follow-up question, and correct the confusing step. If every available hour goes toward the next release, those responsibilities become whatever people can squeeze in. I would make ownership and follow-up time part of the plan.

For measurement, I would choose an outcome before publishing. For a tutorial, that might be whether a few volunteer readers can complete the task without help. For a newsletter, it might be replies that reveal which decision readers are trying to make. Views and clicks can tell us about reach; I would pair them with evidence about usefulness. A handful of reader conversations will not establish a population-wide result, but they can expose a confusing instruction worth fixing.

My experiment for next week would be small: choose one recurring developer question, create one focused answer, and ask three developers to try it. Record where they hesitate, revise the answer, and share what changed with the team. That gives the next editorial meeting something concrete to work from.

What is one piece of developer content that recently helped you make a decision—and what did it do well?

Hello Again

2026-07-22T13:30:14-07:00

I’ve been writing on the web for a long time, but it has been a while since this site felt active. This is the start of a new chapter.

The new michaelcrump.net is intentionally simple. There is no application framework, database, or site generator behind it—just static pages, a small stylesheet, and GitHub Pages. That leaves more room for the part that matters: writing.

I plan to use this space for practical notes about software development, developer tools, AI, and the things I learn while building and experimenting. Some posts will be short. Others will go deep. The common thread will be sharing something concrete enough to be useful.

It’s good to be back.