The Async Work State Update Template That Actually Works

Most teams that try to build a consistent update habit fail because of the template. Either the template asks for too much (nobody fills it out completely) or too little (the answers are uselessly vague). The right template is opinionated enough to prompt genuinely useful information and minimal enough to be completed in under five minutes.

Here's the format, why each section exists, and what good answers look like.

The template

## Work State — [Date] [Name]

**Completed this shift:**
[Specific things finished — PR numbers, decisions made, reviews done]

**In progress (and where exactly):**
[What you're mid-work on, with enough detail that someone could pick it up]

**Blocked:**
[What's waiting and what it's waiting on — or "nothing blocked" if clear]

**Decisions made:**
[Any call that affects future work — include brief rationale]

**For the next shift:**
[What to watch, what to prioritize, what risks to be aware of]

Why this structure

Completed this shift establishes ground truth about what's done. Not "I worked on X" but "X is done, in this state, at this location." The distinction matters — "worked on the auth refactor" could mean anything; "merged PR #447 to staging, verified against test suite" is specific enough to be acted on.

In progress (and where exactly) is the section that prevents the most friction. "Working on the API migration" is nearly useless. "The migration script is written and tested locally; needs staging deployment before the foreign key constraints can be dropped — the migration order is documented in the PR description" is what someone needs to continue the work without asking questions.

Blocked identifies things that can't proceed without an external action. This section surfaces dependencies before they become delays. Writing "blocked on Carlos's security review — ETA unknown" makes the dependency visible to the whole team, not just to the person waiting.

Decisions made is the section most teams skip and most consistently valuable. Small technical decisions made in the flow of work — using soft deletes, choosing a caching strategy, deferring a migration — are exactly the decisions that get re-litigated a week later when someone who wasn't there makes a different call. Writing them down takes ten seconds and prevents hours of undo work.

For the next shift is the active handoff. It's not a summary — it's a direct address to whoever is reading this. "Don't deploy the migration script before the foreign key issue is resolved" is a useful next-shift note. "Please review my work" is not.

What a complete answer looks like

Here's an example of a complete, useful update:

Completed: Merged PR #447 (auth token refresh logic), deployed to staging. Reviewed and approved PR #449 (error boundary component).

In progress: Session state migration — schema change is done (migration 0023 applied to staging), mid-way through the data migration script. It handles users created before 2024-01-01 correctly; still working on the edge case for OAuth users with multiple linked accounts.

Blocked: Prod deployment of token refresh blocked on security review from @Carlos. Opened the request Tuesday — no response yet. If it's not resolved by EOD tomorrow, we should escalate.

Decisions: Chose soft deletes over hard deletes for the session records after checking with Maria — customer support needs the audit trail. Noted in the schema comments.

For next shift: Do not run the data migration script yet — the OAuth edge case will corrupt records for about 3% of users. Should be fixable tomorrow morning.

That update took approximately four minutes to write. It would have taken two to three minutes of meeting time to communicate the same information — and the meeting would have required everyone to be available simultaneously.

Frequently asked questions

Should this be written in a specific tool or does the format travel?

The format travels. Teams use it in Notion, in Slack (in a dedicated #work-state channel), in a purpose-built context tool, or in a shared Google Doc. What matters is consistency: same format, same place, every shift. If the records are scattered across different channels and formats, they're hard to find and the habit doesn't build on itself.

How detailed is too detailed?

If a section runs more than four or five lines, it's probably too detailed. The goal is a record that can be scanned in two minutes, not read in twenty. If you find yourself writing paragraphs, step back and ask: what are the two or three things the next shift actually needs to know? Write those and stop.