DevRel Field Notes: Help Developers Decide What to Do Next

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?