Writing async status updates a colleague can actually act on

Distributed teams rarely fail because people are not working. They fail at the seams — the moment where one person finishes for the day and another picks the thread up eleven hours later without the context that would have taken thirty seconds to say out loud.

Each individual instance is small. A few minutes lost re-deriving something. A question that has to wait a full day for an answer. Multiplied across every handoff in a week, it produces a team that feels slow without anyone being slow, which is a demoralising thing to be part of and a difficult thing to diagnose.

The usual response is to add a meeting. That works, briefly, and then the calendar fills with syncs held at inconvenient hours for whoever lives furthest from headquarters. The better response is to get better at writing things down.

What a colleague actually needs

Most status updates are written as a report to a manager. They describe effort. The reader who matters is usually not a manager — it is the teammate who picks this up next, and they need something different.

Compare:

Worked on the payment integration today. Made good progress, ran into some issues with the webhook handling but got most of it sorted. Will continue tomorrow.

Enthusiastic, and nearly useless to a colleague. What issues? Sorted how? What is the remaining part? Can anyone else help, or is this blocked on you specifically?

Payment integration — webhooks now verified and storing correctly. The retry path is not done: our handler is not idempotent, so a duplicate delivery would double-charge. Next: add an idempotency key on payment_intent_id. Not blocked. If you are touching webhooks.ts before I am back, that is the part that is incomplete.

Marginally longer. Vastly more useful. The difference is that the second one was written for someone who has to act, not for someone who has to be reassured.

The format

Four parts, in this order.

State, not effort. Where the work is now, not what you did. "Auth flow is working end to end for email, not yet for OAuth" beats "spent the day on auth".

The specific next step. Precise enough that someone else could pick it up. "Next: wire the OAuth callback to the session handler" — not "continue on auth".

Blocked or not, explicitly. Say it in words. Blockers hidden in the middle of a paragraph get missed, and a blocker that is missed for a full day is the most expensive kind.

What a reader should know before touching this. The part people skip and the part that saves the most time. Half-finished states, decisions taken, things that look wrong but are deliberate.

The habits that matter more than the format

Write it where the work is. An update in a chat channel is gone in a day. Put it on the task, so the next person to open the task finds it — including in three weeks, when nobody remembers which channel it was in. This is a large part of why we build comments onto tasks rather than relying on a chat integration alone.

Say when something is blocked, on the day. The strongest predictor of whether a distributed team feels fast is how quickly blockers become visible. Waiting until the next sync to mention a blocker costs the whole team a day, and the reluctance is almost always social rather than practical — it feels like admitting failure. Normalise it loudly, particularly if you are senior.

Write the handoff, not the diary. If nobody will pick this up before you return, one line is enough. If someone will, spend the extra two minutes. Calibrating effort to whether a handoff is actually happening is what stops this becoming performative.

Name people directly. "Someone should look at the migration" is addressed to nobody and will be actioned by nobody. Assign it, or name a person and ask.

Say the times

Everyone knows time zones cause problems. Fewer teams fix the specific thing that causes most of them.

"Due Friday" is ambiguous across a nine-hour spread — Friday morning in Berlin has already happened when Friday morning starts in San Francisco. If a deadline is genuinely time-sensitive, say the time and the zone in the task itself: "needs review before 14:00 UTC Thursday". If it is not time-sensitive, a date is fine.

The same applies to availability. "I am around tomorrow" means nothing to someone whose tomorrow overlaps yours by two hours. "I am online 09:00–17:00 CET" is actionable.

Removing meetings is the point

Written updates are not a supplement to your existing syncs. They are a replacement for the part of those syncs that only exists to transfer status — which, in most teams, is most of them.

The sequence that works is: get updates written reliably, confirm the meeting has become redundant, then cut it. Doing this in the other order — cancelling the meeting and hoping writing fills the gap — reliably fails, because the writing habit has not been established and the status simply stops flowing.

What should survive is the meeting where people talk about something contested or genuinely hard. Those are worth arranging across time zones. A meeting to hear what everyone did is not, and it is the one distributed teams keep holding out of habit.

A worked example

Here is a task update that does the job, in about ninety seconds of writing:

Customer export CSV — Export runs correctly for accounts under ~5k rows. Over that it times out at the 30s gateway limit.

Decided against streaming for now; going with a background job and an emailed download link, which matches how the invoice export already works.

Next: add the job + email template. Roughly half a day.

Not blocked. Heads up for anyone in exports/: the synchronous path is still live and I have not removed it, so both routes exist until the job lands.

State, decision, next step, blocked status, and the thing a colleague would otherwise have been confused by. Nobody has to wait eleven hours to ask a question, because the question was already answered.

---

TIBLR keeps status on the task itself, with explicit ownership and acceptance, so handoffs do not depend on overlapping hours. See how it works for remote teams.