Running Team Retrospectives Across Timezones

A team I worked with ran a retro every two weeks for a year. Then they hired in Manila and Berlin, the calendar tightened, and the retro was the first thing to go. Nobody decided to kill it. It just kept getting bumped for something more urgent, and after two or three skips it quietly fell off the calendar. Eight months later the same three complaints surfaced in nearly every 1:1: the handoffs were sloppy, the on-call rotation was brutal for Manila, and nobody trusted the staging environment. Everyone had known about all three for most of a year. There had just been nowhere to say it out loud in a place where saying it would turn into a change.

That is the retrospective's actual job, and it is why losing it costs more than it looks like. Every other ritual on a distributed team produces the work. The retro is where the team fixes how it produces the work. Skip it and the small frictions this whole blog keeps circling, the ambiguous handoff, the meeting that always lands at 11pm for one person, the doc nobody can find, never get named in a room where someone can decide to fix them. They pile up. On a distributed team they pile up faster, because there is no hallway where they leak out and get sorted informally.

Why the retro is the first thing to go

Two things make it fragile. First, it has the least obvious immediate payoff of anything on the calendar, so the moment there is schedule pressure it loses to shipping. You can always skip "talk about how work went" in favor of doing the work. Second, it is genuinely awkward to run live when the team is scattered. The retro is the one meeting where you want everyone in the room at once, reacting to each other, and that is exactly what a distributed team has the least of.

So teams do one of two things, and both are bad. They run it at an hour that suits headquarters and punishes everyone else, which quietly turns it into a retro of whoever happens to be awake and talkative at that hour. Or they give up and stop running it. The person in Manila dials in at 10pm and says nothing, or skips it. Either way the half of the team that is missing is the half most likely to be absorbing the worst of the friction, and the meeting meant to catch that friction never hears about it.

Split it into gather and discuss

The move that makes a retro survive a timezone spread is the same one that makes async brainstorming work: stop treating it as a single live event and separate the two jobs it is actually doing. Gathering what happened is one job. Deciding what to do about it is another. Fused into a single meeting they crowd each other out. Pulled apart, each gets easier.

Gathering should be async and written, and it is honestly better that way. Open a doc or a board a few days out with the usual prompts, what went well, what did not, what we should change, and give people a window measured in their own working days to fill it in. Written-and-async wins here for the reasons it wins in a brainstorm. Nobody anchors on the first thing said. The most senior voice in the channel does not set the frame before anyone else has thought. The engineer in Berlin types her real complaint at her desk on Tuesday morning instead of swallowing it on a call at her dinnertime. You collect more, and what you collect is closer to true.

The discussion is the part you protect

Here is where I part ways with the fully-async purists. Once the input is in, someone has to group it, and the team has to talk through the two or three things that genuinely matter and commit to changing them. That part is worth a live meeting if you can find one at all.

Not because async failed to surface the issues. The written round already did that. It is because the discussion is where you read the room. It is where "eh, it's fine," said in a particular tone, tells you it is not fine at all, and where two people discover they have both been quietly angry about the same broken handoff for a month. This is the same reason the recurring 1:1 stays synchronous: some conversations carry things that do not survive being typed. A retro that is only comments on a board decays into a suggestion box, and a suggestion box never builds the kind of trust that gets someone to say the hard thing next time.

So find the overlap and spend it here. A retro is exactly the sort of high-value, needs-everyone conversation you should be reserving your scarce overlap hour for, rather than letting routine status updates colonize it. If there is truly zero overlap between the two ends of your team, run the discussion as a tight, time-boxed, threaded async session with a facilitator who is genuinely present and replying in real time during their own window. Not a doc left to rot over a week.

Rotate the pain, and watch who goes quiet

Whatever slot you land on will be somebody's evening. Do not let it be the same person's evening every single time. Rotate it the way you would rotate any awkward recurring meeting slot, so the Manila engineer is not perpetually giving up her night to discuss problems that mostly land on her in the first place.

Then watch who is not talking. In a co-located retro you can feel a room tense up. Across a gap you cannot, so silence from the far end gets read as "no issues" when it usually means something closer to "I'm the only person from my region on this call and I would rather not be the complaint department tonight." A facilitator's real job on a distributed retro is to notice that the written input had three sharp comments from Berlin and the live call produced none, then gently pull that thread. A useful gut check: if your retros are cheerful and your 1:1s are full of grievances, the retro is broken, and the grievances are telling you exactly where.

A retro that changes nothing is theater

The thing that actually kills retros for good is not bad scheduling. It is running them faithfully and never changing anything. Three retros in a row where "handoffs are sloppy" comes up and nothing moves, and people reasonably conclude the meeting is theater and stop bringing anything real to it.

So close every retro the way you close any decision meant to stick: with a short list of concrete changes, each with one name on it and a date in a clock everyone can read. Not "we should document handoffs better." Instead, "Priya owns writing the handoff template by Wednesday 5pm IST." One or two real changes that happen will do more than ten good intentions that do not. The point of looking back at the last two weeks is to make the next two different. If they are never different, you have built an elaborate way to complain on a schedule.

This is a different animal from the incident postmortem, which digs into one specific failure after it blows up. The team retro is wider and quieter. It examines the ordinary way you work, the friction that never trips an alert but slowly wears everyone down. On a distributed team that friction is most of what stands between a four-day feature and a three-week one, and the retro is the only ritual built to catch it before someone quits over it. It is the hallway you no longer have, rebuilt on purpose. Skip it at your own risk.

Make Your Action Items Mean the Same Thing to Everyone

A distributed retro succeeds or fails on its action items, and half of that is whether the deadline you wrote lands as the moment you meant. "Priya owns the handoff template by Wednesday 5pm IST" only works if the three people in other timezones read it as their Wednesday, at the right hour. Timely converts every time mentioned in Slack into each person's own clock automatically, so the owners and dates that come out of your retro mean the same thing to everyone who has to act on them. No mental math, no missed handoffs.

Add Timely to Slack — Free · See how it works