2. How Asynchronous Writing Works in Tech

Description

When you write a message at work, your instinct comes from spoken Spanish: you toss out an idea, wait for the other person's reaction, adjust on the fly. It's a fast back-and-forth. But on a distributed team, that back-and-forth doesn't exist when you need it. The person who's going to read your message is asleep, or in another meeting, or lives eight time zones ahead. You're going to write to them now and they're going to answer tomorrow. Between your message and their reply there's a gulf of hours, and everything you didn't say clearly turns into one more question that stretches that gulf out further.

That's the mechanics we're going to take apart in this lesson. It's not an English problem yet — that comes in the next lesson, where we work on the sentence itself. It's a problem of how information gets structured when the person reading you can't ask you immediately. And there's good news here for anyone who feels their English isn't ready: asynchronous writing gives you time. You can write, reread, delete, rewrite, and only then send. Nobody sees your three attempts. In a spoken meeting you compete at a disadvantage against a native speaker improvising at full speed; in a written message you compete on equal footing, because the only thing that matters is the final text, and you polished that text calmly.

Connection to the module: The previous lesson showed you that in remote work, text is the visible product of your day. This lesson installs the rules of the game — complete context, the important part first, the right channel, follow-up without pressure — that apply equally to everything you'll write afterward: chat, bug reports, pull requests, status updates. They're the operating system lessons 4 through 7 run on. And they set up lesson 3, where we go from structure down to the concrete sentence.

---

The complete-context rule

Let's start with the idea that organizes everything else. In asynchronous communication, one single law rules: the message has to be self-sufficient. Whoever reads it can't ask you for clarification and keep going; if something's missing, they stop, ask you, and wait for your answer. That wait doesn't last two minutes. It lasts as long as it takes your time zone to line up with theirs again.

What "complete context" IS: including, inside the same message, everything the other person needs to act without talking to you again. Think about the difference between a phone call and a letter. On the phone you can say "hey, yesterday's thing isn't working" because the other person is right there to ask "what thing?" A letter that only said "yesterday's thing isn't working" would be useless: by the time it arrives, whoever wrote it isn't there anymore to explain. An asynchronous message is a letter, not a call. It has to hold up on its own.

The analogy I like: it's like leaving instructions for someone who'll arrive at your house after you've already left for the airport. You can't shout clarifications from the plane. The note you left on the table is all that person is going to have. It's either complete, or that person is left standing there not knowing what to do.

A message with complete context usually answers, without anyone having to ask, these five things:

What to include	The question you save the reader	Minimal example
What's happening or what you need	"What are you talking about?"	The checkout page returns a 500 error
Where it happens / what it refers to	"Which part? Which repo?"	on staging, in the payments service
When it started or by when you need it	"Since today? Is it urgent?"	since the deploy at 14:00 UTC today
What you already tried or already know	"Did you check the obvious stuff?"	I already checked the logs, no clear cause
What exactly you're asking for	"What am I supposed to do with this?"	Could you confirm if the DB migration ran?

It's not a rigid template to copy every time. It's a mental checklist. Before sending, reread your message and ask yourself: if I weren't here to clarify anything, could this person act? If the answer is "they'd have to ask me X," then X goes inside the message.

What to expect

At first your messages are going to feel long, almost redundant. You're going to feel like you're explaining obvious things. That feeling is normal and it's a good sign: what feels obvious to you — the service's name, the branch, the time — is exactly what the other person is missing. Over time you'll stop calculating it consciously. You're going to learn to hear the eight-hour silence before sending, and to fill in the gaps in advance. That's the central muscle of the whole module.

The important part first: BLUF structure

Here's the most important structural adjustment you're going to make, and it's counterintuitive if you think in Spanish. It's called BLUF: Bottom Line Up Front.

What it is: putting your main point — what happened, what you're asking for, the decision — in the first line, and leaving the detail, the context, and the justification below, for whoever wants to dig deeper. The opposite of the order we're usually taught to build an argument in.

In Spanish, especially in formal register, we're taught to arrive at the conclusion at the end. First the context, then the development, then the evidence, and, as a corollary, the request. It's narrative order: you build the case and close with the ask. It sounds polite and well-constructed. In an asynchronous work message, that order works against you.

Why: whoever gets your message is probably reading it between two meetings, on their phone, with twenty other messages queued up. You get their first eight seconds. If in those eight seconds all they read is context and they still don't know what you want from them, there are three possible endings: they postpone it "for when they have time" (and it never comes), they skim it and miss the ask, or they reply eight hours later with "what exactly do you need?" BLUF eliminates all three. The first line already told them what this is and what's expected of them.

Compare the two orders with the same content:

Narrative order (conclusion at the end — avoid it):

Hi! I was working on the new onboarding flow yesterday and noticed that the email service was behaving strangely. I looked into the logs and saw some timeouts. I think it might be related to the config change we merged on Friday, although I'm not 100% sure. Anyway, I was wondering if you could take a look when you have a moment?

Whoever reads it reaches the end to discover you're asking for a review. They had to process the whole story without knowing where it was going.

BLUF order (important part first — use it):

Could you check the email service config on staging? I think Friday's change introduced timeouts.

Details: while testing the onboarding flow yesterday I saw timeouts in the logs. It lines up with the config change we merged Friday, but I'm not fully sure. No rush — sometime today is fine.

Same content, same courtesy, same degree of humility ("I'm not fully sure"). But the first line hands over the ask and the hypothesis. If the person only reads that line, they can already act. If they want the context, it's right below.

The practical rule for building a BLUF message:

1. Write it however it comes out, in whatever order you want. Let the conclusion fall wherever it falls.
2. Find your key sentence: the one holding the ask or the main news. It's almost always at the end.
3. Move it to the top. Cut that sentence and paste it as the first line.
4. What's left becomes the "Details:" or "Context:" section below.

It's a mechanical move: you write in mental Spanish (context → conclusion) and then flip it around before sending. In a few weeks you'll do it from the start, but at first it's completely fine to write naturally and flip it at the end. Nobody sees the draft.

What to expect

The first time you move the conclusion to the start it's going to sound blunt, almost rude. In Spanish, being that direct with no preamble can read as an order. But in technical work English, that does not read as rudeness: it reads as respect for the other person's time. The register of courtesy doesn't live in the preamble you cut — it lives in words like could you, when you have a moment, no rush, which you do keep. Getting to the point and being polite aren't at odds. Lesson 3 refines those formulas; for now, hold on to this: direct is not discourteous.

Public or private: choosing the channel

Where you write changes the effect of what you write as much as what you write does. At a remote company almost everything happens through Slack-like tools, Teams, or Discord, and every message either goes to a public channel (visible to the team) or to a direct message, DM (just you and one other person). Choosing wrong is a silent mistake: nobody corrects you, but your message performs worse.

Spanish-speaking instinct usually pushes toward the DM: asking in public exposes that you don't know something, so better to do it privately, one to one. In asynchronous work culture, that instinct is almost always backwards. The default answer is the public channel. Not because privacy doesn't matter, but because a public message works for more people than just you.

Think of it with an analogy: asking in a DM is like asking one person for directions in a low voice. Asking in the channel is like asking out loud in a room: anyone who knows the answer can give it (you don't depend on that one specific person being awake), and everyone who had the same question no longer needs to ask it. Your question becomes documentation for the team.

Goes to a public channel	Goes to a direct message (DM)
Technical questions whose answer helps others	Personal or sensitive feedback about someone
Your work status, blockers, progress	Payroll, permissions, something private of yours
Decisions that affect the team or product	A "thanks" or a detail that adds nothing to the channel
Bug reports, questions about the repo	Coordinating something trivial between two people
Anything you want kept on record	A draft you don't want made public yet

A very common worry: "won't I be bothering everyone if I write in the channel?" No. In a channel, people read what concerns them and skip the rest; nobody's obligated to respond. A DM, on the other hand, does create pressure: it lands directly on one person and they feel like they have to answer. That's why the DM, which seems more considerate, often ends up being the one that actually interrupts.

Pocket rule: if the answer to your message would help someone else on the team, it goes to the channel. If it's specifically personal or sensitive, it goes to the DM. When in doubt, public.

A useful phrase for when you're unsure whether your question "is too basic" for the channel — it isn't, but if it makes you nervous, this is how you open it naturally:

Quick question, probably obvious — where does the staging DB config live? I checked the README but didn't find it.

That probably obvious doesn't make you look less capable. It shows you already tried (I checked the README) and it lowers the room's guard. It's a move seniors make too.

Response times: patience as a skill

Async brings an expectation that doesn't exist in spoken communication: the response isn't immediate, and that doesn't mean you're being ignored. Internalizing this saves you anxiety and keeps you from accidentally pressuring coworkers.

What to expect depending on the channel (these are typical cultural ranges on remote teams, not fixed rules at any specific company):

Type of message	Reasonable response window	What NOT to do
Channel chat, not urgent	A few hours; could be the next day across time zones	Rewriting "?" ten minutes later
Direct DM, not urgent	That person's same working day	Sending "hello?" a bit later
Pull request under review	1 to 2 business days	Pinging the same day you open it
Internal email	1 to 2 business days	Expecting a reply within minutes
Real incident / production down	Then yes, right now — and through the urgent channel	Treating everything as if it were this

The classic newcomer mistake — and the one that carries impostor anxiety — is reading silence as rejection or as having done something wrong. It's almost never that. It's that the person is asleep, focused, or your message is in their queue. The skill you learn here is tolerating silence without filling it with noise.

How to follow up without pressuring

When genuinely too much time has passed and you need to move something forward, there's a way to remind someone without sounding demanding. The principle: make it easy to respond and lower the pressure, don't raise it.

What to avoid:

Did you see my message?? — (two question marks, sounds like a reproach)

hello? — (passive-aggressive even if you don't mean it to be)

What works — a follow-up that re-includes the context (so nobody has to scroll up) and offers an easy way out:

Hey, following up on this — no rush if you're busy. Quick recap: I need a thumbs-up on the migration plan before I can deploy. If someone else is a better person to ask, just point me their way.

Let's break down why it works:

• following up on this — names it as a reminder, with no drama.
• no rush if you're busy — you explicitly remove the pressure; paradoxically that makes a response more likely.
• Quick recap: — you repeat the essentials so they don't have to scroll up to find the original thread. Complete context again.
• If someone else is a better person to ask — you open an exit door. Maybe you weren't asking the right person, and now they can redirect you without feeling guilty.

Another useful phrase for when the block starts costing you real time and you need to flag it without making it dramatic:

Gentle bump on this one — it's currently blocking me from finishing the payments task. Whenever you get a chance today would help a lot.

Gentle bump is the established tech term for "soft reminder." It names the real impact (blocking me) without accusing anyone. It's direct about the problem and courteous with the person: that's the combination we're after throughout the whole module.

The real cost of an ambiguous message

Let's close with the economic reason all of this matters, because it's what turns these "good manners" rules into a concrete advantage a manager notices.

In synchronous communication, an ambiguity costs seconds: you ask, they clarify, you move on. In async, every ambiguity costs a round-trip cycle, and every round-trip can cost a full day when time zones are involved. A message that leaves three things unresolved doesn't cost three sentences: it can cost three days.

Let's look at it with numbers. Imagine you write to a coworker in another time zone, about 12 hours offset, to unblock a task.

Ambiguous message:

Hey, the thing isn't working. Can you help?

Here's what follows, in real time:

Day	Who	What happens
Monday 9:00	You	"the thing isn't working"
Monday 21:00	Coworker	"Which thing? What's the error?"
Tuesday 9:00	You	"The checkout, it returns 500"
Tuesday 21:00	Coworker	"On staging or prod? Since when?"
Wednesday 9:00	You	"Staging, since yesterday's deploy"
Wednesday 21:00	Coworker	Finally can start helping

Three days just for help to start. Not because nobody had good intentions, but because each reply revealed a missing detail, and each missing detail cost a twelve-hour round-trip.

The same problem, with complete context and BLUF, in a single message:

Blocked on a 500 error in checkout on staging — could you help me debug?

Started after yesterday's 14:00 UTC deploy. The error fires on the payment step; logs show a timeout calling the payments service. I already ruled out the DB (migrations ran fine). My guess is the new timeout config, but I'm not sure.

With this, the coworker opens the message once and already has everything to get started. Help begins on the first round-trip, not the sixth. You compressed three days into one afternoon.

That compression is exactly what a good manager sees and values, and it's one of the things the market research flagged over and over: the problem is rarely your grammar. It's that the message gives no context, asks for nothing concrete, and forces a dance of questions. Fixing that doesn't require perfect English. It requires structure. And you control the structure, calmly, before sending.

Exercises

Practice what you just read with these four exercises. Work through them before checking the solution.

Exercise 1 — Spot the context gap

A coworker writes to you: "Hey, can you check the deploy? Something looks off."

Using the five questions from the complete-context table (what, where, when, what they already tried, what they're asking), identify what this message is missing to hold up on its own.

See solution

Almost everything is missing: it doesn't say what deploy or which service, it doesn't say where it's happening (staging or production?), it doesn't say when the problem started, it doesn't say what they already tried checking, and "something looks off" isn't a concrete ask — it's unclear what you're expected to do. A complete version would be: "Could you check the payments service on staging? Since this morning's 10:00 UTC deploy, checkout requests are timing out. I checked the logs but couldn't find the cause."

Why this works: every one of the five gaps you close saves the reader one question, and every question saved is a round-trip of hours that doesn't happen.

Exercise 2 — Flip the order to BLUF

Rewrite this message so the conclusion lands in the first line:

"I was reviewing the pull request this morning and noticed a few things. The tests are passing, but I'm a bit concerned about the error handling in the payment function — it doesn't seem to catch the timeout case. I also saw a small typo in a comment. Do you think we should merge this today or wait?"

See solution

A BLUF version:

"Should we merge this PR today or wait? My main concern: the payment function's error handling doesn't seem to catch the timeout case.

Details: tests are passing. There's also a small typo in a comment, unrelated to the merge decision."

Why this works: the first line hands over the decision that needs to be made and the main reason for it. The secondary detail (the typo) stays below, where it doesn't compete for attention with what actually matters.

Exercise 3 — Public or DM

For each situation, decide whether the message should go to a public channel or a DM, and say why in one sentence:

a) You found a bug in the shared repo that nobody has reported yet. b) You want to give a specific coworker feedback on how they wrote their latest pull request. c) You have a question about where the staging config lives. d) You need to coordinate with one specific person the exact time of a two-person call.

See solution

a) Public channel — an unreported bug helps the whole team that touches that repo, and it doesn't depend on one specific person being awake to see it. b) DM — personal feedback about someone's work is sensitive; making it public adds nothing to the channel. c) Public channel — even if it feels "too basic," the answer saves someone else the same question; open with "Quick question, probably obvious..." d) DM — it's trivial logistics between two people that nobody else in the channel cares about.

Why this works: the pocket rule is a single question — "would the answer help someone else on the team?" — and applying it mechanically overrides the instinct to hide every question in a DM.

Exercise 4 — Write a follow-up with no pressure

Two business days have passed since you asked your manager to approve a deployment, and they still haven't replied. Write a follow-up message that re-includes the context and offers an easy way out.

See solution

One possible version: "Hey, following up on this — no rush if things are busy. Quick recap: I need your go-ahead to deploy the pricing update we discussed Tuesday. If it makes more sense for someone else to approve this, just let me know who."

Why this works: it names the follow-up with no accusation ("following up"), explicitly lowers the pressure ("no rush"), repeats the essential ask so they don't have to search for the thread ("Quick recap"), and leaves an exit door in case they're not the right person to answer.

Summary and next step

Let's recap the four rules that govern everything you'll write for the rest of the module:

• Complete context: the message holds up on its own, because whoever reads it can't ask you for hours. Before sending: "could this person act without me present?"
• BLUF, important part first: the conclusion and the ask in the first line; the detail below. Write naturally and flip the order before sending.
• Right channel: public by default (your question helps others and doesn't depend on one specific person), DM for anything personal or sensitive.
• Timing and follow-up: silence isn't rejection; tolerate the response window and, if you do follow up, re-include the context and lower the pressure (no rush, gentle bump).

Before moving on to the next lesson, you should be able to:

• Reread a message of yours and spot in seconds what's missing for it to hold up on its own.
• Take a message in narrative order and flip it to BLUF: conclusion up top, detail below.
• Decide whether something goes to a public channel or a DM using the pocket rule, without overthinking it.
• Write a follow-up that lowers the pressure instead of raising it.

And the idea I want you to take away above all: asynchronous writing is the terrain where your English competes on equal footing. You have plenty of time to reread, polish, and structure. Nobody sees your drafts. The only thing that gets evaluated is the final text, and you work on that with a calm a spoken meeting never gives you. If you feel like your English "isn't there yet," this is exactly the place where that matters least and where you can start looking good from your very first message.

In the next lesson we go one level down: from how the message gets structured to how the sentence gets built — clear technical English, word by word, so that structure sounds as good as it works.

Resources

• Asynchronous communication for remote work — GitLab's public handbook on how to structure messages and decisions when the team doesn't share a schedule.
• Inverted Pyramid: Writing for Comprehension — Nielsen Norman Group explains the technique of putting the conclusion first, the same logic behind BLUF, applied to any text that gets skimmed.
• Understand direct messages — Slack's official documentation on when a DM makes sense versus a channel.
• What is a channel? — Slack's official documentation on the role of public channels as the team's shared memory.
• Why async? — Doist's (the makers of Twist) manifesto on why asynchronous work reduces the pressure of an immediate response and what timing expectations are reasonable.