Write Heavy, Read Light: Clarity Is the Writer's Job

Earlier today I came across an online discussion about whether you should react to Slack posts with :thinking_face: or :eyes:. The people who use them usually mean well: “I’m thinking about it” or “I’m looking at it.” But the person who wrote the post can read those reactions in other ways. A thinking face might mean the post is controversial, or that the reactor disagrees. Eyes might mean they saw it and nothing more, and the poster has no idea what happened after that.

A reaction is extremely easy to leave. The cost shows up when someone reads it: the reactor’s intent is unclear, and the poster has to guess.

I think business communication should work the other way around. The writer takes on the cost so that the reader doesn’t have to. I call this Write Heavy, Read Light. Heavy here means effort, not length: the writer does the work of removing room for interpretation.

Ambiguity is paid for in the reader’s time

If you abstract the Slack example, you get a pattern that I think is common. Someone sends a message or an instruction in an ambiguous form. The receiver misreads it, or comes up with several interpretations, and time is wasted sorting it out. I believe this leads to rework, delays, and wasted hours more often than we notice.

This doesn’t make reactions bad in themselves. If everyone in a channel agrees on what a reaction means, it is cheap to leave and cheap to read. The trouble starts when only the person reacting knows what it means.

Slack reactions are only one case. Here are two more.

Instructions without background

Ordinary messages and instructions can be ambiguous too. One common form is the bare command: “Do X,” with no background at all. If the receiver doesn’t know what the work is for, they can’t move on their own, and you end up having to keep giving them instructions.

A command alone rarely carries enough for the receiver to work out your intent. I see it working only in a high-trust organization where people already share enough context.

Abbreviations move the cost to the reader

Abbreviations are another example. A long term gets compressed into two or three letters to make it quicker to get across. It works like dictionary-based compression. Compressing is cheap for the writer, but it puts a heavy load on the reader.

So using abbreviations is a trade-off. What matters is whether the abbreviation is part of the reader’s vocabulary. Abbreviations save time only when the reader already knows how to decode them. To decompress an abbreviation, the reader needs the dictionary, and the abbreviation makes carrying that dictionary the reader’s job. The load is heaviest on people who just joined and on anyone who doesn’t have the context yet. I think this does more harm than it seems to.

Written once, read a hundred times

There is a common lesson about writing documentation: you write it once, and it gets read a hundred times. A message may be read by many people, often more than once. With that in mind, you should write clearly enough that what you intended actually comes across, leaving as little room for interpretation as possible.

One way to see why: the cost of a message is the cost of writing it, plus the number of reads times the cost of understanding it each time. Extra effort while writing is paid once. Any reduction in the cost of understanding is multiplied by every read. This also explains when reactions and abbreviations are fine. If the reader already shares their meaning, the cost of understanding is close to zero, and the shortcut costs almost nothing.

I think this matters for business communication in general, not only for documents. The goal isn’t to write more. It’s to make understanding easier.

Every ambiguity we leave behind becomes a decision someone else has to make. Write Heavy, Read Light is about making those decisions while writing, instead of leaving them to every reader.