Writing Clear Messages on a Remote Team

At 6:10pm, wrapping up her day in Bangalore, Priya sent her teammate in Austin a quick message: "can you take a look at the auth thing when you get a chance?" Then she closed the laptop and went to make dinner. Dan read it at 9am his time, nine and a half hours later. Which auth thing? The login bug from Tuesday, or the token refactor? Look at it how, review the PR or actually test it? And "when you get a chance" meant what, today or next week? He typed back three questions and moved on to something else. By the time Priya read his questions, answered them, and he picked the work back up, it was two days after her original message. The actual task was twenty minutes of work.

That is the tax on a sloppy message, and almost nobody puts it on the invoice. In an office the same message costs nothing, because Dan would roll his chair over and ask "which auth thing?" and have his answer in four seconds. Distributed, every detail Priya left out became a round-trip, and each round-trip is priced in a full sleep cycle. On a team spread across the planet, writing a clear message stops being a matter of politeness or polish. It is throughput. The person whose messages get answered in one pass is quietly faster than the person who types twice as much twice as fast.

An unclear message is a hidden round-trip

The reason bad writing is so expensive on a distributed team, and so hard to see, is that it never shows up labeled as bad writing. It shows up as a slow project. The task sat for two days, and if you asked anyone involved they would say they were responsive. Priya replied promptly. Dan replied promptly. Everyone was responsive and the thing still took two days, because the delay did not live in anyone's reply speed. It lived in the number of times the message had to cross a night to get complete.

This is the same math that makes a three-round pull request cost three days regardless of how hard the code is, and the same reason latency compounds across a multi-step project until "everyone was fast" and "the whole thing crawled" are both true. What you actually control is how few times your message needs an answer at all. Reply speed barely matters next to that. A message that can be acted on the moment it is read, with no "wait, what do you mean," is worth more than a faster reply to a muddled one. So the goal of every message you send to someone hours ahead of or behind you is simple to state and weirdly hard to do: get it right in one pass.

Put the ask first

Most people bury the point. They open with background, walk through how they got here, lay out the context, and then, somewhere in the fifth sentence, arrive at what they actually need. That ordering is natural when you are talking, because the listener can nod along. It is terrible in writing read cold, because the reader has to hold all the setup in their head before they even know what it is for.

Flip it. Lead with the request, then give the context underneath it. Dan reading at 9am wants to know in the first line what Priya needs from him. "Can you review PR #412 today? It's the token refactor, and the release is blocked on it." Everything else goes below. Now he knows the shape of the ask before he reads a word of explanation, and if he is skimming an overnight backlog he can triage it in two seconds instead of parsing a paragraph to find the verb. This is the written version of sending a proposal instead of leaving a question open: you are handing the reader something they can act on, not a puzzle they have to solve first.

Answer the question before they ask it

The opposite failure is the bare ask with no context at all. "Can you approve the deploy?" Approve which deploy, why now, and what breaks if you do not? The reader has to come back with exactly those questions, and now you have your round-trip anyway.

The trick that fixes both failures is the same one. Before you send, picture the reader's most likely follow-up question, and answer it in the first message. Then picture the next one, and answer that too. You are spending thirty seconds of your time to buy a full day of theirs, which is the best trade available on a distributed team. If a decision is involved, say what you recommend and why, so they can reply "go" instead of opening a discussion. If there is a deadline, it belongs in the message, not in your head. The habit is the same one that keeps a project moving: answer tomorrow's questions today, while you are both awake inside the same message, rather than letting each one eat a night.

One message, one topic

When you finally get a teammate's attention after waiting out their night, it is tempting to unload everything at once. Don't. A message with five asks buried in one paragraph reliably gets one of them answered and the other four silently dropped, and you will not find out which until the thing you needed never happened.

Split them. Separate asks into separate messages, or at least a clean list, so each one is independently answerable and nothing hides behind a more interesting question above it. It also makes life bearable for the person working through an overnight pile at the start of their day, sorting what needs a reply from what is just noise. A tidy, single-topic message is easy to action and move past. A dense block with four requests tangled together is the kind of thing a tired reader stars "to deal with later" and then never does.

Say who, what, and by when in their clock

Vague asks create vague outcomes. "Can someone look at this soon?" names no owner, so everyone assumes someone else has it and nobody does. "By EOD" means a different hour to each person who reads it, and across a wide gap it can mean a day that has already ended. Name the specific person you need, not the whole channel, when the ask is for one human. Put the deadline in a real date and time anchored to the reader's clock, the way you would set any deadline that has to survive a timezone gap. And make the mode of the ask obvious: is this something you need done, or something you are telling them for later? A reader cannot always tell an action from an FYI, and when they guess wrong in either direction, something breaks.

Write for the person reading it alone at 2am

One mental model improves every message you send. Assume it will be read at the worst possible hour, by someone tired, alone, with no one online to clarify, possibly in their second language. That reader cannot ask you what you meant. They can only work with the words on the screen, and if those words leave room for a darker or more confusing reading, that is the one that will win at 2am.

So write plainly. Short sentences. Warmth you would not bother with in person, because tone that is obvious across a desk vanishes in text and gets reconstructed by whoever reads it in whatever mood they are in. Make the message skimmable, because it will be skimmed. None of this means padding. It means saying the thing directly enough that a stranger to your exact situation could act on it. If the answer is something the whole team will need again, the message is not where it should live. Send the nudge, then put the durable version in a doc so the next person does not have to find your Slack thread. The message gets the task moving. The doc keeps it from being asked again. That split is what working async-first looks like in practice, and clear writing is the part of it you practice one message at a time.

This is a skill, and it rewards the small effort

The best async communicators I have worked with are not the fastest typers or the most talkative. They are the ones whose messages almost never generate a confused reply. They have built one small habit: before hitting send on anything that crosses a timezone, they reread it once as the person who will open it tomorrow morning, and they fix the line that would have cost a day. It takes fifteen seconds. On a team where every misunderstanding is priced in a sleep cycle, fifteen seconds of rereading is the highest-return thing you will do all day.

Let Timely Handle the Clock Math

Half of a clear message is a clear deadline, and that falls apart the moment "by EOD" or "can you join at 3?" means a different hour to everyone reading it. When you write "review by 10am ET" or "sync at 3pm my time," Timely reads each person's Slack timezone and shows that moment in their own local clock, so the time in your message is one less thing a tired teammate has to work out before they can act on it.

Add Timely to Slack — Free · See how it works