The source
“How we run a four-day async sprint”: a 2,500-word engineering blog post
An illustrative example: an engineering manager writes about replacing daily standups with written updates and a shorter sprint.
Key passages we'll work from
- Section 2: “We replaced the daily standup with a written update posted by 10am. Three questions: what shipped, what's blocked, and what you need from someone by name.”
- Section 4: “Meetings now need a written pre-read. If the pre-read answers the question, we cancel the meeting. About a third get cancelled.”
- Section 6: “What didn't work: async decisions on anything contentious. We tried it for a month and it created long threads with no owner. Those now go to a 25-minute call.”
The method
- Use the headings as a menu
A long article usually has one idea per section. Each section heading is a candidate post. Choose the ones that work without the context of the rest of the article.
- Lead with the failure, if there is one
The “what didn't work” section is often the most credible part of any article. Readers trust a writer who shows the limits of their own advice.
- Give the answer in the post
If the post is about three standup questions, list the three questions. Put the article link in the comments for people who want the full context.
- Space the posts out
Publish one post now, then the others over the next two weeks. Each can point back to the article in its first comment.
Three angles, not one summary
Each angle below could carry a post without the others. That's the test for whether you have distinct posts or one post cut into pieces.
The finished posts
Each post uses a different format so the series doesn't read like one idea split three ways.
We replaced our daily standup with three written questions, posted by 10am: 1. What shipped since yesterday? 2. What's blocked? 3. What do you need, and from whom (by name)? The third question does most of the work. “Blocked on review” is easy to ignore. “Need a review from Priya on the billing PR” gets answered before lunch.
A rule that cancelled about a third of our meetings: Every meeting needs a written pre-read. If the pre-read answers the question, the meeting is cancelled. No one has to argue that a meeting is pointless. The document settles it.
We moved almost everything on our team to async. One thing didn't work. Contentious decisions. We tried them in writing for a month. Every one became a long thread where everyone replied and nobody decided. Now the rule is simple: if a decision has real disagreement, it gets a 25-minute call with one named owner, and the outcome is written up afterward. Async is great for information. It's poor at resolving disagreement.
Mistakes to avoid
- “New on the blog: [title]. Link below.” gives the reader no reason to stop scrolling.
- Summarizing the entire article in one post. It ends up too long and too general.
- Reusing the article's SEO headline. Search headlines and feed hooks are written for different readers.
The source material in this guide is an illustrative example written for teaching, not a real company's content.