Sync vs async communication

Published 21 October 2026

It is 6pm in Bengaluru and you are stuck on a migration. You post in the team channel: "hey, quick question about the orders table". Then you log off. Your teammate in Berlin sees it at 2pm their time, replies "sure, what's up?", and goes back to work. You read that the next morning. A whole day has gone, and nobody has said anything yet.

That is the difference this page is about. Synchronous communication happens when both people are there at the same moment: a call, a meeting, a chat where both of you are typing. Asynchronous communication is written so the other person can read it later and act on it without you: a message, a doc, a ticket, a pull request description.

In an office you can get away with being bad at async, because you can walk over to someone's desk. On a remote team spread over time zones you can't, and it decides how fast you get things done.

The real cost is round trips#

Each time someone has to reply before the work can continue, that is a round trip. In the same room a round trip takes ten seconds. Across a large time gap it takes a day, because every reply waits for the other person's morning.

So the question is never "is chat faster than email". It is: how many round trips does this message cause? "Hey, quick question" causes at least two. A message with the context, the question, your suggested answer and what you will do if you hear nothing causes zero.

Pick two cities below and see how many working hours you actually share. Then raise the number of questions your message leaves open.

A few things fall out of it:

• Bengaluru and Europe share three and a half to five and a half hours, depending on the city and the season. Plenty of time to talk, as long as you keep those hours for each other.
• Bengaluru and the US West Coast share none on a normal day. Engineers on these teams often start late (11am or noon) to buy an hour or two. That is a real cost to your evenings, so agree it openly rather than drifting into it.
• India does not change its clocks, but Europe and the US do. Your overlap moves by an hour in March and again in October or November. Check the calendar invites in those weeks.

The message that needs no reply#

Most async trouble comes from messages written the way you would talk. Talking is cheap to correct, so it starts vague. Writing should start complete. A message that needs no reply has four parts:

1. Context. What you are working on and why this matters now. One or two sentences.
2. The question or the decision. Exactly one, stated plainly.
3. Your recommendation. What you would do, and why. Now the reader only has to agree or disagree.
4. The default. What happens if they do not reply by a certain time.

Here is the migration question written that way:

I'm adding a currency column to orders (for the multi-currency launch on 12 Nov). Two ways: (A) add it nullable and backfill in batches over two days, no downtime; (B) add it with a default in one migration, which locks the 80 GB table for about 20 minutes. I'd go with A. If I don't hear otherwise by your Thursday noon, I'll start A on Friday morning IST.

Your lead reads it on their Wednesday, types "A, go", and you start a day earlier than you would have after a "quick question". If they say nothing, you still start on Friday. Either way, nobody waited on anybody.

Status updates and handoffs#

Two kinds of message do most of the work on a remote team.

The status update. Remote teams cannot see you working, so they rely on what you write. A short daily or twice weekly note answers three things: what moved, what is next, and what is blocking you and who can unblock it. The third one is the only one that has to be read today. Put it first if it exists.

The handoff. If your team covers more than one time zone, work can move across the day: you stop at 7pm IST, someone in Europe or the US picks it up. A handoff that works says where things stand, what you tried that did not work, the exact next step, and where the evidence is (the branch, the dashboard, the log query). "Was looking at the timeout bug, will continue tomorrow" hands nothing over.

When to talk instead#

Async is the default, not a rule against calls. Switch to a call when:

• The thread has gone back and forth three times and you are no closer. Something is being misunderstood, and writing more makes it worse.
• Someone is upset, or a message could be read as harsh. Tone is the thing writing carries worst.
• The problem is still fuzzy. Brainstorming, or debugging something nobody understands yet, is faster out loud.
• It is an emergency. A live incident is a call, not a thread. (See mitigation vs root cause.)

Then write down what you agreed, in the thread where the question started. A call that leaves no note behind only helps the people who were on it, and on a remote team that is rarely everyone.

In the interview#

Remote companies judge this whether or not they say so. The written application, every email to the recruiter, and the take-home README are all writing samples.

Checkpoint#