Declared Work State for Async Teams: A Practical Guide

Async teams have a coordination problem that synchronous teams solve with meetings. In a synchronous team, you can call a standup, go around the room, and everyone's state gets declared in real time. In an async team, the synchronous moment doesn't exist — or if it does, it's expensive. State has to be declared differently.

Declared work state is the practice of explicitly communicating current work state in writing, at regular intervals, using a consistent format that makes the information easy to find and consume. It's the async substitute for the synchronous "so where are you?" conversation.

Why "just ping me if you need to know" doesn't work

The on-demand model — where engineers answer state questions as they come in — seems efficient but has several failure modes. First, it creates interruption costs: every "quick question about state" fragments the recipient's focus. Second, it creates timezone gaps: if the person with the knowledge is asleep, you wait. Third, it creates knowledge silos: only the people who thought to ask know the answer.

Regular declared state eliminates all three failure modes. The information is available before anyone thinks to ask. There's no interruption cost because the record was written during the natural wrap-up at shift end. There's no timezone gap because the record was written when the knowledge was fresh and is readable any time.

The format that works

The most effective declared state format is structured around five questions, answered concisely:

• Completed: What is done and in what form? ("PR #447 merged — auth token refresh logic, deployed to staging")
• In progress: What is actively being worked on, and where exactly? ("Working on the session state migration — have the schema change done, mid-way through the data migration script")
• Blocked: What is waiting, and what is it waiting on? ("Deployment to prod blocked on security review from @Carlos — ETA unknown")
• Decisions: What calls were made this shift? ("Decided to use soft deletes instead of hard deletes for user records — discussed in #engineering thread at 3pm")
• Watch: What should the next shift pay attention to? ("The session migration script is not idempotent yet — don't run it twice")

This format takes three to five minutes to write. It takes two to three minutes to read. It replaces the fifteen-minute standup for context transfer purposes.

When to declare

The natural declaration point is end of shift — when the work period ends and handoff to the next shift (or to tomorrow) begins. This is when the information is freshest and when the habit is easiest to anchor to an existing behavior: you're already wrapping up, putting away the laptop, transitioning out of work mode.

For teams that don't have clear shift boundaries — individual contributors working flexible hours — a reasonable proxy is "end of work day" or "before closing the laptop." The habit has to be consistent to be useful; the exact timing matters less than the regularity.

What declared state is not

It's not a comprehensive daily report. It's not documentation of what was built. It's not a time-tracking record. Declared work state is specifically the handoff layer — the information that the next person needs to continue the work or understand the current situation. Anything beyond that is overhead, not value.

Frequently asked questions

What if nothing significant happened in a shift?

Declare that. "Spent the day in bug triage — no new PRs, no decisions, no significant state change" is a valid and useful declared state. The incoming shift doesn't need to search for context that doesn't exist. Knowing that nothing significant happened is itself useful information.

How do you handle sensitive information in declared state records?

Apply the same judgment you'd apply to any shared document. Personnel issues, legal matters, and unreleased financial information shouldn't go in broadly accessible state records. For these situations, either use a restricted-access context record or handle them through direct communication. Most day-to-day work state is not sensitive and benefits from broad visibility.