The hard part of managing a remote team is not that people are far away; it is that knowledge stays in people’s heads. Across time zones this becomes more visible: one person is asleep while another waits for a decision. Below are the habits I rely on when working with remote teams in different time zones. They summarize how I work; they are not a claim about a specific client or a measured result.
1. A decision that is not written down has not been made
A decision taken in a meeting only becomes shared knowledge once it is written. For every critical decision I keep a short record: what was decided, who decided, why, and which options were dropped. That record is the first thing someone waking up in another time zone reads, and three months later it is the answer to “why did we do it this way?”.
2. A shared task board
The answer to “who is working on what?” must live in one place. I split the work into small, finishable pieces; each piece has an owner, an acceptance criterion and a status. Nobody has to ask “what are you doing right now?” — the status is read from the board.
3. Settle the communication rhythm up front
At the start of a project I agree the rhythm with everyone: a short weekly status summary, a demo at the end of each sprint, and a written record for critical decisions. For quick questions I use instant messaging; for anything that must stay on record, e-mail or the board. Once the rhythm is clear, the uncertainty of “when will we hear back?” disappears.
4. Build the time-zone gap into the plan
When shared working hours are scarce, I reserve them not for meetings in general but for topics that truly need a live conversation. Everything else should be able to move asynchronously: write a clear question, put the context needed for the decision inside the message, and say when the waiting work becomes critical. A well-written question can replace a meeting.
5. Demos and working output
In remote work, saying “we are progressing” is not enough. At the end of every sprint I show a working output; in AI projects that could be a pilot result, a recording of an agent flow, or RAG answers shown with their sources. A demo lets the team and the decision makers talk while looking at the same thing.
6. Make risks visible, with an owner
In remote teams problems are noticed late because there are no hallway encounters. So I keep risks in a register with an owner and a mitigation, and show them at the top of the status summary. Bad news grows when it is hidden; the purpose of the register is to make it discussable early and calmly.
7. Handover: do not let the work depend on one person
In a distributed team one person’s absence is more expensive. So I do not leave technical documentation and usage knowledge to the end; I keep them current throughout, and at delivery I give the team a short knowledge-transfer session. The aim is that the system can be run without me.
Summary
Working remotely does not mean more meetings but clearer writing: written decisions, a shared board, a defined rhythm, working output and visible risk. You can read how I work remotely across time zones on the How I Work page, and answers to common questions on the FAQ page.