The default failure mode of a distributed team is not the distance — it is trying to schedule the distance out of existence. Calendars fill up to compensate for process that was never written down, someone ends up on calls at midnight, and within a quarter that someone has quietly stopped attending. We run squads in Kathmandu for European product owners, and none of it depends on anyone’s heroics after dark. Here is the actual mechanics, starting with the clock.
The overlap window, in plain arithmetic
Kathmandu is UTC+5:45 — a few hours ahead of Central European time. That produces a structure, not just an offset. The Kathmandu morning happens while Europe sleeps: heads-down implementation, no interruptions. When a European owner starts their day, the team is already hours into its own — overnight questions have answers, pull requests are up and waiting for review. The European morning through early afternoon overlaps the Kathmandu afternoon: a shared window, hours long, every working day, wide enough for standups, reviews, pairing and hard conversations.
Run well, the day has a rhythm: Kathmandu builds while you sleep, you review over coffee, decisions land in the shared window, and the team acts on them the same afternoon. A single day gets two productive shifts — but only if the handoff between them is clean, and a clean handoff is a process property, not a geographic one.
Async-first rituals that survive distribution
- Written specs — if it was said in a call and never written down, it does not exist. The spec is the interface between time zones; ambiguity in it becomes a lost day, because the question it raises waits for the next overlap window.
- Decision logs and ADRs — every consequential decision recorded with its reasoning and the alternatives rejected. This kills the most expensive recurring meeting in any distributed team: “why is it built this way?”
- Review gates as artefacts — a pull request that carries its tests, its eval results and its checklist can be reviewed properly at any hour. Review quality must not depend on both people being awake at once.
- A prepared overlap agenda — the synchronous window is the scarcest resource in the system, so it is never spent on status. Status is readable; the window is for what genuinely needs live discussion, prepared in writing beforehand.
What must stay synchronous
Async-first is not async-only, and pretending otherwise is its own failure mode. Some things belong in the live window, on purpose: architecture disagreements, because written debate slows to a crawl when people disagree about fundamentals; incidents, obviously; kickoffs and anything else where trust is being built rather than information transferred; and bad news, which should never arrive as a comment thread. The rule of thumb we run: synchronous time is for disagreement, ambiguity and trust. Everything with a defined shape — status, review, specification, decisions already made — travels as a written artefact.
How the AI loop reduces synchronous dependency
Our delivery loop — spec compression, assisted implementation, review gates — was built for engineering quality, but it turns out to be a distribution tool as well. Spec compression forces the ambiguity conversation to the front: a spec precise enough for agentic tooling to work from is, by construction, precise enough to survive a timezone gap without a clarifying call. The ambiguity gets resolved once, during overlap, instead of leaking out across a week of pinged questions.
Eval-gated merges do the same for correctness. When “does this work” is answered by an eval suite running in CI rather than by a conversation, the answer is available at any hour, in either hemisphere. And accountability stays undiluted: an engineer signs every merge, machine-written or not — the signature is asynchronous, the responsibility is not. The net effect is that the shared window gets spent on judgement instead of coordination, which is the only thing it was ever worth spending on. The same discipline shows up in our applied AI practice: artefacts over meetings, gates over vibes.
None of this requires exceptional people staying up late. It requires ordinary discipline applied every day — which is harder to sell and easier to live with. If you want to see how a standing squad in this setup would attach to your organisation, the shape of the engagement is on our services page — and the first conversation is a technical call, not a sales call.