Stop Writing Novels in Slack

You merged a PR at 2pm. By 2:07 you’d sent your team a Slack message explaining the change, the context, the tradeoff you considered and rejected, and a note about the edge case they should watch for in staging. Thorough. Professional. Two hundred and thirty words.

Three people saw the notification, glanced at the first sentence, and went back to what they were doing. One person - the one who actually needed to know about the edge case - never saw it at all. It got buried under six other threads before they checked Slack after lunch.

The change shipped. The edge case bit someone in staging. That someone spent forty minutes debugging before they found your message, scrolled up, and read paragraph four.

You didn’t under-communicate. You over-formatted a short decision into something that looked like work to read, and the person who needed it decided not to.

Treat Every Message Like a Request on a Critical Path

Every system you build gets instrumented. You measure latency. You set timeout thresholds. You ruthlessly cut anything that bloats the request. Add 200ms of unnecessary overhead to a critical path and someone is filing a ticket by morning.

Then you open Slack and write four paragraphs to explain a one-sentence decision.

The software runs tight. The communication around it doesn’t. That gap is not a stylistic preference - it’s a systemic efficiency loss, and it compounds. A team of ten engineers sending sprawling status updates, vague follow-up questions, and multi-paragraph handoffs isn’t communicating more. They’re generating more noise for everyone else to process.

Think of every message you send as a function call. The recipient has to parse it, extract what’s relevant, decide if a response is required, and then actually respond. The more ambiguous and verbose the input, the more expensive that parse. In a well-designed API, you don’t send a JSON payload of loosely related fields and let the server figure out the intent. You send exactly what the endpoint expects. Human communication works the same way. The cognitive overhead is just less visible, so we let it accumulate.

Write for the Scanner, Not the Reader

Nobody is reading your messages. Not the way you think.

Your PM has 47 unread threads before standup. Your tech lead has two pull requests open, a production alert in the background, and a 1:1 in twelve minutes. When your message lands, they scan it - top to bottom, two seconds - and decide in that window whether to act, defer, or move on. If your ask is buried in paragraph three, after the context, after the caveats, after the “hope this makes sense” - they’ve already moved on.

Format for that reality. A useful mental constraint: write every message as if the recipient has a phone at 1% battery, no charger nearby, and a meeting starting in ninety seconds. What do they need to know? What do they need to decide? What link or ticket number unlocks the next step? Put those three things at the top, in plain language, scannable at a glance. Everything else is optional.

A short message that buries the ask is just as broken as a long one. The goal is structure, not brevity. Context first, one sentence. The ask, explicit. Any blockers or dependencies, bulleted. The recipient should be able to hit the bottom of your message and know exactly what’s expected of them. If they have to re-read to figure that out, the message failed.

Kill the Preamble

“Hey, got a sec?”

That message costs more than it looks. The recipient stops, notices it, and now has an open loop in their head. They don’t know if it’s urgent, trivial, or somewhere in between. They have to either respond immediately - context-switching out of whatever they were doing - or consciously defer it and carry the weight of the unresolved ping until they can get back to it. All of that friction is on you, and you delivered zero information.

Don’t send the greeting. Send the message. Everything the recipient needs to act should be in the first send: the context, the question, the attachment, the link. If it’s not urgent, say so. If it can wait until tomorrow, say so. Let them triage it without having to ask for more.

The same principle kills the multi-part send - five rapid messages, each one a sentence fragment, each one triggering a new notification. Five notifications for a single thought is disruptive. Group it. One message, complete thought, sent when it’s ready.

Emoji acknowledgments exist for a reason. A 👀 on a deploy announcement costs one keystroke and tells the sender you’ve seen it. A ✅ on a completed task closes the loop with zero additional noise. These are not affectations - they’re protocol-level efficiency. Using them is strictly better than writing “Thanks, I’ll take a look” and generating another unread message for the original sender to parse and dismiss.

Ask Binary Questions

If answering your question requires a paragraph, you asked the wrong question.

“What do you think about the approach here?” is not a question. It’s a request for someone to do your thinking for you and then write it up. The recipient now has to determine what aspect of the approach you’re uncertain about, assess it, form a view, and translate that view into a message you’ll actually act on. You’ve just added a non-trivial task to their queue and created a high probability of a vague response that generates another follow-up round.

Questions should have binary answers. “Should we use optimistic locking or a queue here?” is answerable in three words. “Does this migration need a feature flag, or can we ship it directly?” Same. “Can we move the kickoff to Thursday?” One word. These questions are respectful of the recipient’s time. They’re also more useful - a clear yes/no forces you to have already done the thinking. You can’t ask a good binary question without first understanding the problem well enough to identify the decision point.

When you can’t distill it to a binary, that’s a signal. Either the decision is genuinely complex and needs a synchronous conversation - in which case, ask for fifteen minutes instead of writing a paragraph-long question - or you haven’t thought it through enough yet, in which case the message is not ready to send.

Close the Loop Explicitly

“Let me know what you think” is where momentum goes to die.

Open-ended endings are a trap. They feel polite - you’re not demanding anything - but they guarantee ambiguity. The recipient doesn’t know if you need an answer by end of day or end of quarter. They don’t know if you want a full review or a quick gut check. They don’t know if the thread is blocking anything. So they make a judgment call, and that judgment is almost always “I’ll get to it later.” Later becomes next week. Next week becomes a follow-up ping from you. You’ve added a full round-trip of latency for no reason.

End every message with an explicit action item or a hard question. “Needs your approval before I merge” is an action item. “Are you the right person to sign off on this, or should I go to someone else?” is a hard question. Both terminate cleanly. The recipient knows what they’re responsible for. They can either do the thing or tell you they can’t.

The same rule applies to meetings. A meeting that ends without explicit next steps - names attached, deadlines attached - is a meeting where everything discussed will be re-discussed. A good close sounds like: “Okay, you’re owning the migration script by Wednesday, I’m unblocking the API contract today, and we’ll sync Thursday if anything changes.” That’s not bureaucracy. That’s the difference between momentum and drift.

Communication is a protocol. Every message is a packet. Dropped packets, ambiguous headers, malformed payloads - they all have the same effect on a team that they have on a network: retries, delays, and degraded throughput. Fix the protocol and the work moves faster.