Working with clients across time zones: each exchange costs a day, so every message must finish its job in one round

Picture yourself 12 hours apart from the client’s data team. At the end of your day you write: “Could you check whether something is wrong with the orders table?” The next morning the reply is: “What kind of problem?” You explain, then wait another night. Two days have gone by and the pipeline has not moved.

FDEs know this scene well. Clients can be anywhere, and the moments you are most stuck tend to be the ones where you need the client to grant access, settle a schema decision or confirm the data.

Common Knowledge’s handbook puts it bluntly: because asynchronous work is slower than synchronous work, writing with missing information can cost the whole team several days.

The skill to practise here is not “replying faster”. You need three things working together: updates written fully enough that nobody has to ask a follow-up, a small shared window kept for hard work, and a set of response rules both sides have agreed.

Why does the first message usually fail?

When you write, you know everything: which query you ran, where you saw the odd number, what you suspect. The reader knows none of it. The principle to remember is to write for someone who has not been inside your head all day.

The team at thoughtbot observes that when a message is rewritten clearly, the client can give an answer that moves the work forward in a single round.

When each round costs a day, that is the difference between finishing today and finishing next week. So the goal of every message is precise: the recipient must be able to answer straight away without asking anything back.

Rewriting the orders table message

Here is a second version of the message from the start of this article, written in five parts:

Context: The pipeline that syncs the orders table to the data warehouse
runs daily at 02:00 UTC. Last night the job succeeded, but the row count
dropped by roughly half compared with the day before.

Finding: All the missing rows have status = 'pending'. The check query
and its results are in the attached link.

Please choose:
  A. 'pending' rows are excluded on purpose (a change on the source system side)
  B. This is a bug, and 'pending' rows must be kept

Default: If there is no answer by Thursday 15:00 UTC, the FDE side will
keep the existing data and pause the job, so the dashboard is not wrong.

Meanwhile: The FDE side is writing a test that counts rows by status so
this is caught immediately next time.

Each part answers in advance a follow-up question the client might ask. The context answers “which job?”. The finding answers “how do you know?”. The options turn an open question into a decision the client can answer with a single letter.

The last two parts are the ones most often skipped, yet they matter most. A default means that even silence leads to an outcome, so the work is never left hanging. The deadline must state the day, the hour and the time zone, because nobody is sure whose “tomorrow afternoon” is meant.

The end-of-day handoff: where context is most easily lost

Between two time zones, a handoff happens every day: you stop just as the client starts. That is also where most context falls through the cracks. With no meeting to ask for status, status exists only if someone writes it down.

A good handoff needs only four lines, posted in the same place every day. Continuing the orders table example, that evening’s handoff might look like this:

Handoff Wednesday, 18:00 UTC+7 (11:00 UTC)

Done: row-count-by-status test for the orders table, merged.
Blocked: orders sync job, waiting for you to choose A or B
  (message sent at 17:30 UTC+7 in the project channel).
Awaiting client decision: keep or drop 'pending' rows,
  deadline Thursday 15:00 UTC.
FDE side next: if B, fix the filter condition and rerun the job;
  if A, update the schema documentation.

Note that the “blocked” line says exactly who it is blocked by and points to the exact message that needs an answer. The last line shows the client how their answer will be used, which gives them a reason to reply early.

The test is simple: the client reads it and has nothing to ask. Do this consistently and the person in the other time zone no longer loses out on information just because their hours differ from yours.

The shared window: small, protected and fair

Writing does not solve everything. Renegotiating scope, delivering bad news or settling an architecture decision still calls for talking directly. Fortunately, even with a large time difference you can usually find 30-60 minutes of overlap, which many teams call “core hours”, for a video call or stand-up.

The trick is to use that window for the right things. Do not waste it on status updates, which writing already covers. Keep it for matters that would take many rounds to resolve in writing.

There is one more point FDEs tend to forget: the time-zone arrangement should say plainly who is meeting too early or too late. If you are always the one on the 22:00 call, write that down and rotate when you can. An FDE who burns out after three months is no longer any help to the client.

Response rules: write them down before you need them

Most of the strain of working across time zones comes from expectations nobody stated. The 24-hour mark is a sensible starting point for an agreement with a client: Common Knowledge sets a default of responding to comments within 24 hours, Monday to Thursday, and Doist also expects people to reply within 24 hours.

The other half matters just as much: never demand an immediate reply unless it is a genuine emergency. That is why production incidents need a separate channel, such as a phone number or an alerts channel, along with a clear definition of what counts as “urgent”.

Type of work	Channel	Response time
Routine questions and decisions	Message written in five parts	Within 24 working hours
Daily status	End-of-day handoff	Read at the start of the other side’s day
Hard decisions, bad news	Shared 30-60 minute window	Next shared meeting
Production down	Separate emergency channel	Immediately

Common mistakes

The most common mistake is an open question with no default, because it forces the work to wait. The second is giving a time without a time zone, or using “tomorrow” or “end of the week” without a specific date.

The third is using the shared window to read out status, while the decisions that genuinely need a conversation get pushed into messages.

The last is harder to spot: treating every message as urgent. When everything is urgent, the client stops believing the word, and when production really does go down, nobody reacts in time.

Exercise: count the rounds you are losing

Go back over the last five messages you sent to a client or colleague in another time zone. Mark the ones where the first reply was a question back, then rewrite the worst one using the five parts above.

Put the two versions side by side and ask yourself: had you sent the new one, how many rounds would you have saved? That number is how many days you lost without noticing.

Turning this skill into evidence when job hunting

Don’t just write “good communicator” on your CV.

Describe the specific work: how you set response rules, a shared window and a handoff template with a client so many hours away, and how much faster blocked decisions were cleared. In interviews, the before-and-after pair of messages from the exercise above is the easiest evidence to talk through.

Next time you are about to send a question at the end of your day, reread it through the eyes of the person who will open it while you are asleep. If they have to ask you something back, you have just lost a day without knowing it.