The average knowledge worker sends and receives hundreds of Slack messages and emails per day. Most of them are unclear, incomplete, or require multiple follow-up exchanges to extract the actual information needed.

This is not a small inefficiency. Bad async communication kills remote teams, delays decisions, and creates a tax on everyone who has to participate in the clarification loop.

Good async communication is a skill. It is also one of the most leveraged skills an engineer can develop because it compounds across every interaction you have.

Why Async Communication Is Hard

In a synchronous conversation, confusion gets resolved immediately. You see someone’s face, you notice when they are lost, you can rephrase in real time.

In async communication, you get one shot. If your message is unclear, the other person has to decide whether to ask a follow-up question (interrupting their flow and yours) or guess at your meaning (which often leads to wrong outcomes).

The barrier to writing well is that it takes more upfront time. You have to think before you type. Most people default to the path of least resistance: write fast, let the other person do the work of figuring out what you meant.

The Hierarchy of Message Quality

Level 1: Drives confusion. Missing context, unclear ask, no indication of urgency.

“Hey can you take a look at the auth service?”

Level 2: Gets a response but generates follow-up questions.

“Hey, there’s an issue with the auth service. Can you help?”

Level 3: Self-contained and actionable.

“The auth service is throwing 500 errors on login attempts since the 2pm deploy. I checked the logs and it looks like the JWT secret env variable is missing in the prod config. I do not have access to the secret manager. Can you verify whether PROD_JWT_SECRET is set? If not, I can revert the deploy while we fix it.”

Level 3 takes 60 more seconds to write. It saves 10-15 minutes of back and forth. Do the math across 20 messages per day.

The Elements of a Good Async Message

Context first. Before stating your ask, give enough background that someone with no context can understand it. Do not assume the other person remembers your last conversation.

Clear ask. What exactly do you want them to do? Review something? Approve something? Give their opinion? Answer a specific question? State it explicitly.

Any constraints. Is there a deadline? Is this blocking someone? Is it low priority? Say so. People cannot prioritize your message correctly without this information.

Your proposed answer, if you have one. If you already have a recommendation, include it. “I think we should X because Y. Do you see any issues with that?” gets a faster, better response than “what should we do about X?”

The “No Hello” Principle

Do not send “Hey” or “Hi” and wait for a response before stating your actual question. This is extremely common and extremely disruptive in async communication.

By the time the other person responds “Hi, what’s up?”, you have already interrupted them once without even communicating anything. Then you interrupt them again with your actual question.

Just write the whole message up front. Yes, even if it feels abrupt. It is more respectful of their time than the alternative.

Writing Updates That People Actually Read

Status updates are an important form of async communication that most engineers do badly.

What makes a status update useless:

  • “Working on the feature” (no information)
  • “Making progress” (still no information)
  • Bullet points that just list what you did with no context about why it matters

What makes a status update useful:

  • What was accomplished (specific, not vague)
  • What is blocking progress, if anything
  • What is coming next
  • Any risks or changes to the original plan

This structure takes 5 extra minutes to write and saves everyone in the review chain from having to ask clarifying questions.

The Escalation Decision

A common mistake is staying in async mode when you should switch to sync.

If an issue requires more than three back-and-forth exchanges to resolve, pick up the phone or hop on a call. The accumulated async overhead at that point exceeds the cost of a 10-minute synchronous discussion.

Good async communicators know when to switch modes. They do not cling to async communication as a matter of principle when the problem has outgrown it.

Formatting That Helps Comprehension

For anything longer than 2-3 sentences:

  • Use bullet points for lists of more than two items
  • Bold the key ask so it is visible when someone scans
  • Put the most important information first, not last
  • Use headers for longer updates or documents

In Slack specifically: write a short first line that previews the content, then use a thread for details. This lets people triage without reading everything.

A Before/After Example

Before: “Hey I was looking at the analytics dashboard and something seems off with the numbers and I wanted to get your thoughts on what might be happening since it could be affecting the reports we send to the business team every week and they asked me about it on Friday and I was not sure what to tell them.”

After: “The weekly analytics dashboard is showing 30% lower user counts than last week with no corresponding drop in traffic. This is affecting the Friday business reports. Two possible causes: the new filter we deployed Tuesday, or a data pipeline delay.

Can you check if the data pipeline job ran correctly this week? I will investigate the filter change from my side. Need to have an answer for the business team by Thursday EOD.”

Same information, completely different usability.

Bottom Line

Writing well in async contexts is one of the highest-leverage skills a developer can build. Give context before asking, make your ask explicit, include constraints and your proposed solution when you have one, and skip the “hey” preamble. Good messages move things forward. Unclear messages just create more work for everyone.