Write a Weekly Update Worth Reading

Every Monday at what was 9am for the people who scheduled it, a team I worked with held a forty-minute status meeting. Eleven people, four timezones. One by one, each person read their update aloud: what I did last week, what I'm doing this week. Everyone else sat there half-listening, waiting for their turn, occasionally nodding at a camera. The person in Singapore had joined at 10pm to say nine sentences that would have taken anyone ninety seconds to read.

Nothing was decided in that meeting. Nothing was debated. It was eleven people taking turns reading things aloud that the other ten could have read faster on their own. And it cost the single most expensive resource a distributed team has, which is the one hour a week all four timezones are awake at the same time.

That meeting is the most common waste I see on remote teams, and it hides in plain sight because it feels productive. Everyone showed up. Everyone shared. Surely that's alignment. It isn't. It's a broadcast pretending to be a conversation, and broadcasts don't need a meeting.

The status meeting is the wrong tool for status

Here's the test for whether a meeting should exist: does it need people in the same room at the same time? A real discussion does. An argument that only resolves in back-and-forth does. A decision where the thinking happens live does. Status doesn't. Status is one person telling the group a set of facts, and facts travel perfectly well as text that people read whenever their day starts.

On a colocated team the waste is small, because the overlap is all day and pulling people into a room is cheap. Spread the team across continents and the same habit gets expensive fast. Your overlap window might be two or three hours, and you just spent forty minutes of it on something nobody had to be present for. That's the same logic that pushes good remote teams to make decisions without a meeting: if a thing can be written down and read asynchronously, writing it down frees the scarce synchronous hours for the work that genuinely needs them. Status is the easiest thing on your calendar to move to text, and usually the first thing you should.

So kill the status meeting and replace it with a written weekly update. The catch is that most written updates are also bad, just bad in a way that's quieter.

Most weekly updates are unreadable, and here's why

Ask a team to write weekly updates and you tend to get one of two failure modes.

The first is the activity log. "Attended the planning sync. Reviewed six PRs. Had a 1:1 with Sarah. Responded to the customer ticket about exports." It's a list of things that happened, ordered by nothing, signifying nothing. It reads like a timesheet written to prove the week wasn't wasted, and nobody reads past the second line, because there's no signal in it. Whether the project is on fire or perfectly fine, the activity log looks identical.

The second is the fog. "Made good progress on the migration. Still working through some issues. Should be in a better place next week." That's three sentences that tell you nothing. What progress? Which issues? Better how? The writer knows exactly what they mean, because the whole week is loaded in their head. The reader has none of that context and comes away knowing less than before they read it.

Both fail for the same reason a bad async message fails: they aren't written for someone who wasn't there. This is the core discipline of async-first communication applied to status. The reader is a colleague in another timezone who didn't sit in your week, and the update has to stand on its own, because they can't tap you on the shoulder to ask what "some issues" means. They'll read it eight hours after you write it, form a picture, and act on it. Write for that person or don't bother writing.

What a good update actually contains

A weekly update worth reading answers three questions, plainly, in a few minutes of reading. What changed, what's next, and what's at risk.

What changed is outcomes, not activity. Not "worked on the export feature" but "shipped CSV export; it's live for beta users." Not "reviewed the auth PR" but "auth rewrite is merged, so the login bug from last month is fixed." The difference is whether the reader learns the state of the world moved, or just that you were busy. Busy is not a status. Shipped is.

What's next is the one or two things that actually matter this week, not an exhaustive backlog. You're telling the team where your attention is going so they can flag a collision before it happens, the teammate who says "wait, don't touch the billing code Tuesday, I'm mid-migration there." That early collision-detection is a thing an office gave you through overheard conversation, and the written update is where a distributed team rebuilds it.

What's at risk is the part people are most tempted to soften, and the part that matters most. If a date is slipping, say so now, in the update, while there's still a week to react, not in the standup the morning it's already late. And when you name a date, put it in a form that survives the trip across timezones, because "should land by Thursday" means something different in three different places unless you anchor it. An honest "at risk" line is the most valuable sentence in the whole update. A team where everyone's update is permanently green is a team that's going to be surprised.

Keep the whole thing short. If your weekly update takes more than fifteen minutes to write, it's too long, and if it takes more than three minutes to read, nobody finishes it. Brevity isn't a nicety here. It's what makes the ritual survive past the third week, when the novelty wears off and people start skipping the long ones.

The weekly cadence is doing its own job

A weekly update is not a slower standup, and the two aren't competing. The daily standup handles the tight loop: today's blocker, the thing you need unblocked before you log off. It's about the next twenty-four hours. The weekly update is the zoom-out the daily view can't give, the altitude where you can see that three days of small progress added up to a shipped feature, or that a project has been quietly stuck for a week in a way no single day's standup revealed.

Distributed teams need that altitude more than colocated ones, because they lack the ambient sense of momentum an office broadcasts for free. In a room, you feel the week's shape without anyone reporting it, from the energy and the hallway talk and the demo someone gave off the cuff. Remote deletes that signal. The weekly update is where you deliberately rebuild it, one honest paragraph at a time.

Roll it up so people see the whole

Individual updates are the raw material. The thing that makes them a team ritual instead of eleven monologues is a roll-up: one person, usually the lead, reads everyone's updates and writes a short synthesis of where the team as a whole stands. What shipped this week, what's at risk across all of it, what the team is pointed at next.

This does the thing the Monday meeting was pretending to do, and does it better, because the synthesizer actually reads everything and thinks about how the pieces connect, instead of eleven people each hearing ten reports go past and retaining none. It also protects your overlap hours for the work that needs them, the design argument and the hard decision, rather than spending them on eleven people reading aloud. Post the roll-up where the whole team sees it, including the person who was asleep when it went out, and the teammate nine hours off gets exactly the same view of the week as the person sitting next to the lead. Which, on a distributed team, is the entire point.

Make Every "By Thursday" Mean the Same Thing

The most useful line in a weekly update is usually a date, and a date is exactly what gets lost between timezones. Timely converts every time mention in Slack to each reader's own timezone automatically, so your "at risk, needs a call by Thursday 3pm" reads correctly whether your teammate opens it in Denver or Delhi, and your update means the same thing to everyone who reads it.

Add Timely to Slack — Free · See how it works