Write an asynchronous status update from source records

Build the update from records, not recollection

Open the project board, accepted deliverables, decision log, and current blocker record before writing. The update should compress those sources, not replace them. If a claim cannot be linked to a task, document, commit, approval, or dated note, either add the record first or label the statement as an estimate.

GitLab’s public weekly async update template asks for progress and status, next steps, blockers, and confidence about the current milestone. The useful principle is the stable set of questions, not the company-specific cadence. Consistency lets readers scan several updates and notice what changed.

Use a five-part update

Write outcomes instead of activity. “Reviewed five files” says effort occurred; “approved the brief, with the attachment audit still open” tells the reader what changed. Use the source link on the noun or result, not a generic “here.” If nothing changed, say that plainly and identify the unchanged dependency.

Make blockers actionable

“Blocked” is not a status by itself. GitLab’s blocked-issue workflow calls for the cause, the person or team responsible for unblocking, actions already taken, and an expected timeframe when known. Adapt that to a small team. Add the smallest decision or input needed. If the blocker has no owner, assign the follow-up to the person writing the update until another owner accepts it.

Distinguish a blocker from risk and waiting. A blocker prevents the next planned step. A risk may affect a later outcome but does not stop today’s work. Waiting means another party has the next action and the team has a follow-up date. These labels prevent every uncertainty from turning the update red.

State confidence with a reason

A traffic-light label without evidence invites optimism. If you include confidence, pair it with the condition: “At risk because source approval is due one day before handoff; next check 22 September.” Avoid invented percentages. When a schedule changes, state the old date, new proposed date, decision owner, and source of the change.

A hypothetical update might read: “As of 19 September, the source inventory is complete and the writing brief is approved. The PDF table extraction remains blocked on a readable copy; the research owner requested one and will follow up on 21 September. Drafting can proceed for sections that do not use the table. Next checkpoint: source decision on 22 September.” This is an illustrative format, not a real project report.

End with the reader’s required action

If no action is required, say “No action requested.” If a decision is needed, name one decision, one owner, and a deadline. Do not hide three requests inside a paragraph. Link to the detailed task rather than copying its entire history into the update.

1. Open the source records before drafting.
2. Date the update and state the outcome first.
3. Link evidence for completed and changed work.
4. Describe blockers with cause, owner, action, and checkpoint.
5. End with one explicit request or “No action requested.”

When a status item came from a recurring meeting, reconcile it first using the meeting-action guide. When the update triggers an email response, the shared-inbox review keeps approval and sending roles clear.