When Marcus joined as head of engineering at a logistics software company in 2023, the team had people in Denver, Lisbon, Nairobi, Singapore, and Auckland. No two regions had more than two hours of working-day overlap. Most pairs had zero. He told me the first six months were rough, not because the work was hard, but because the coordination system hadn't been designed for this reality.
"We were trying to run a company that had twelve people in one city like we had forty people spread across the planet," he said. "Everything was organized around synchronous availability. It was a disaster."
They redesigned from scratch. Here's what they built.
Accept that real-time coordination is the exception, not the norm
The first thing Marcus's team did was stop treating real-time availability as the default assumption. In most companies, the implicit system is: if you need something, ping someone and wait. The faster they respond, the better the coordination. That model collapses when your teammates are asleep.
They replaced it with a system where work should be able to progress with an expected 24-hour response window, and anything that can't wait 24 hours needs to be flagged explicitly as time-sensitive with a reason attached. "Time-sensitive" is not a status you can self-assign for convenience — it requires context. "I need this before I can start the next phase of deployment" is valid. "I just want to know" is not.
This sounds like a small rule but it changes behavior dramatically. People stop firing off quick questions and expecting immediate answers. They start front-loading their requests with enough context for the other person to make a decision without a follow-up conversation.
The handoff note is sacred
In a single-timezone company, someone finishing a task can turn to the next person and say "here's where this stands." In a distributed team, that moment never happens naturally. You have to build it explicitly.
Marcus's team uses what they call the "end of day note" — a short async video or written summary left in the project workspace before someone finishes their working day. Not a status report. Not a summary of everything they did. Specifically: here's where this thing I was working on stands, here's what needs to happen next, here's any context the next person needs to pick it up.
The people in Singapore finish their day as Denver is starting. If the Singapore engineer leaves a clear handoff note in the project workspace, the Denver engineer can pick it up and make progress in their day without a single synchronous interaction. The baton passes. The work keeps moving across time zones like a relay.
It works when people actually do it. It requires culture and accountability to make it a habit — the same way code review or documentation becomes a habit. It doesn't happen automatically.
Decisions need a deadline, not a meeting
One of the most common coordination problems in distributed teams is decision gridlock. A decision needs to be made, someone posts about it in a channel, and then it sits there waiting for everyone to weigh in. The people in Auckland respond first. Then Lisbon. Then Denver wakes up and adds thoughts. Now there are three conflicting directions and nobody has authority to resolve them.
Marcus's team treats decisions like projects: they have an owner and a deadline. The decision owner posts a proposal with a decision date. Anyone who wants to weigh in has until that date. The decision owner reviews input and decides. They document the decision and the reasoning, and that's that.
The key word is "owner." Every decision needs a named person who will make the call. Decisions by committee in a distributed team tend to either drag indefinitely or create artificial urgency that pulls everyone onto a call at 6am. Neither is good.
The one meeting nobody cancels
With all this async-first structure, you might expect their calendar to be empty. It's not. They have one weekly meeting that every team member attends: a rotating thirty-minute team sync that moves through time zones every quarter so nobody is always the one getting up at 6am or staying up until midnight.
This meeting has a strict no-work-updates rule. No project status, no decisions, no blockers. Just: what's going on in your world, what are you working on that's interesting, what's something from outside work you've been thinking about. It's thirty minutes to remember that the people on the other end of your async messages are actual humans with actual lives.
It's corny to describe it that way. But they have a remarkably low turnover for a company of their size and complexity, and Marcus credits this meeting as part of why.
Documentation isn't optional at this scale
The real load-bearing infrastructure of a distributed multi-timezone team is documentation. Not formal documentation — not polished wiki articles that nobody writes because they're too formal. Living documentation: decisions recorded in context, context captured in project workspaces, reasoning attached to choices so the person who joins the project six months later doesn't have to reconstruct why things are done a certain way.
When context isn't documented, the people who know it become the bottleneck. They're the ones answering the same question from six different people in six different time zones. That's exhausting and it scales poorly. Document the answer once and point everyone to it.
What they'd do differently from the start
I asked Marcus what he'd tell a team of ten that was about to grow into six time zones. His answer was immediate: design the coordination system before you need it. Don't try to retrofit async-first onto a culture that was built around synchronous availability. It's harder to change habits than to form them.
Specifically: establish the handoff note habit when you have ten people. Build the decision-owner model when the decisions are small. Get people used to leaving context in writing when there are only a few of them. By the time you have forty people across six continents, these habits are just how the team works, not a new system you're trying to impose.
The alternative — which is what most teams do — is growing into the complexity and then scrambling to install process on top of chaos. It can be done. But it's a lot harder.