The short version
- Watching people work is not available on a distributed team. What replaces it is a short, protected interval between pieces of visible output.
- Weekly delivery on every account caps the gap between a wrong assumption and finding it at seven days. Roughly 50 correction opportunities a year against about 12 on a monthly cycle.
- A status report is written by the same person as the work and fails in the same direction. Count the built artifact instead. On one account 44 content pages sit behind such a count.
- Load never shows on a video call. It shows as the gap between somebody's visible outputs stretching while their status lines stay confident.
Nobody on this team can be watched working. We run 8 client accounts across four time zones, so what I know about the state of the work comes from what the work leaves behind: something visible that shipped, and a count that ran against it. The job is keeping the gap between those two signals short.
How do you supervise work you cannot watch?
By making the work produce evidence on a fixed interval. Something a client’s customer could see goes live every week on every account, and the cadence is protected the way a print deadline is protected. That caps the worst case for discovering a wrong assumption at seven days rather than the eight weeks a monthly cycle allows, which is roughly 50 correction opportunities a year against about 12.
That ratio is the argument. Correction inside a room is free and immediate. On a distributed team every correction has to be bought with a finished piece of work.
What each instrument tells you, and how long it takes to say it:
| What a room used to show you | What tells you instead | What it costs to run | Lag before it speaks |
|---|---|---|---|
| Whether the work is on track | Something visible shipped this week | A protected weekly cadence | 7 days |
| Whether it meets the standard | A count run against the built page | One validator, 44 pages behind it | At publish |
| Whether somebody is overloaded | The interval between their outputs stretching | Nothing extra, the same cadence | The week it slips |
| Whether a decision was made | It appears in the shared channel for that relationship | One channel per relationship | Same day |
| Whether an item is moving | The wording of its status line changing | A named owner per surface | 7 days |
Why is a status report the wrong instrument?
It is written by the same person as the work and inherits the same blind spot: a plausible account of what was produced rather than an inspection of it.
So the check runs against the artifact. On one account 44 content pages sit behind an automated count before publish: rendered length, FAQ entries, a real table, links that resolve to pages that exist. A count returns a number, and a number cannot be met with a summary.
How do you tell who is overloaded?
Not from the call, where everybody has the same square and the same lighting. The signal is the interval stretching. When somebody’s visible output slips while their written updates stay confident, the load has surfaced in the only place it can.
Asking how somebody is doing returns the word fine. What works is asking for the list of everything they are holding right now, in order. People will not report strain and will happily read out a list.
What has to have a name against it?
Every live surface. A blog we ran went down during a rebuild and stayed down for weeks. It sat on the status list the whole time, described accurately, between two vendors and two internal functions, with nobody’s name against the restore.
Nothing in a building reminds anybody a surface is still broken, so unowned work is the normal case here. Each surface gets one owner who reports its state on the same day every week, whether or not it moved.
Everything I know about how the work is going, I know from something the work left behind.
What does the client see?
Their own work, on a link that belongs to them. Per-client portals make visibility structural rather than a weekly email somebody has to remember, and those updates report status without making the strategic call.
The two mechanics underneath all of this are counting the built artifact instead of reading the report and what happens to work with no name against it.
Frequently asked questions
How do you manage a remote team without micromanaging?
Shorten the interval between visible outputs and inspect the output rather than the person. Something ships on every account every week, which caps the time between a wrong assumption and finding it at seven days.
How do you know if remote employees are actually working?
You do not observe it. What you can observe is whether work appeared this week and whether it cleared a check that returns a number. Both are answerable without asking anybody how their day went.
How do you spot burnout on a distributed team?
By watching intervals rather than faces. Somebody carrying too much keeps reporting confidently and ships later, so the gap between their visible outputs stretches before anything is said out loud.
How often should a distributed team ship something visible?
Weekly, on every account. A monthly cycle lets a wrong assumption run about eight weeks before anybody catches it, which is roughly 12 correction opportunities a year. Weekly caps that gap at seven days and produces roughly 50.
How do you review work when you cannot look over someone's shoulder?
Against the built artifact, using checks that return numbers: rendered length, FAQ entries, whether a real table exists, how many internal links resolve. On one account 44 content pages sit behind that count.
How do you stop work falling through the cracks on a remote team?
Put one name against every live surface and have that person report its state on the same day each week. A blog we ran stayed down for weeks while sitting on the status list with nobody's name against the restore.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
