You send a quick message asking a teammate to review a document. An hour later, they reply: Which version? You answer. They ask when it's due. You answer again. By the end of the day, a two-minute task has taken six messages and interrupted both of you three times.

This pattern feels unavoidable, but it is mostly a design problem. Each round of clarification happens because the original message left out something the reader needed in order to act. The fix is not to write more. It is to write deliberately. This article sets out a three-part system: how to structure messages, how to supply context, and how to answer questions before anyone asks them.

Most messages follow the order in which the writer's thoughts arrived. There is some background, then a tangent, and the actual request sits in the last line. The reader has to dig for what matters. Message architecture means arranging information in the order the reader needs it, not the order you thought of it.

A reliable structure has four parts. First, state the action needed and who needs to take it. Second, give the deadline. Third, add the essential details required to complete the task. Fourth, include optional background for anyone who wants it. Journalists call this the inverted pyramid. The most important information comes first, so a reader who stops early still has what they need.

Formatting supports this structure. Use a subject line that names the request, such as Review needed: Q3 budget draft by Thursday. Put separate asks in numbered items so each one can be answered individually. Keep to one topic per message where possible. If you mix an urgent request with a casual update, one of them often gets overlooked. These habits add about a minute of effort, and they save the reader from having to piece together what you meant.

Takeaway

Write for someone reading on a phone between meetings. If they read only the first two lines, they should still know exactly what you need and when.

A well-structured message can still fail if the reader lacks the background to act on it. You know which project, which file, and which earlier decision you mean. Your reader may not. Context loading is the practice of including enough information that the recipient can act without searching, remembering, or asking.

A simple test helps. Imagine the recipient reads your message after a week away and remembers nothing of earlier conversations. What would they need? The answer usually includes three things. 1) A direct link or attachment, instead of a reference to “the file I mentioned.” 2) A one-sentence reminder of relevant past decisions. 3) The constraints that shape the task, such as budget limits, formatting requirements, or who else is involved.

Consider a student asking a professor for an extension. “Can I have more time on the paper?” invites several follow-up questions. A context-loaded version names the course, the assignment, the original due date, the reason, and a proposed new date. The professor can then reply with a single yes or no. The goal is not a long message. The goal is to include the specific details that unlock a decision. Leave out any context that doesn't help the reader act.

Takeaway

Every piece of context you leave out becomes a question someone has to ask. Work out what the reader would have to look up, and put it in the message instead.

The final layer looks ahead. Before sending, consider how the recipient is likely to respond and what questions their reply might raise. Response design means shaping your message so that the easiest possible reply is also a complete one.

Three techniques do most of the work. 1) Offer specific options instead of open questions. “When are you free?” starts a negotiation. “Does Tuesday at 2pm or Wednesday at 10am work?” can be settled in one reply. 2) State your default. Adding “If I don't hear back by Friday, I'll go ahead with option A” means the recipient doesn't need to reply at all if they agree. 3) Address the obvious objection. If you know the recipient will ask about cost, include the cost.

This approach applies a principle central to David Allen's work: clarify the next action. A message that ends with a vague “Thoughts?” leaves the next action undefined, so the recipient has to work out what kind of response you want. A message that ends with a decision to make, a stated default, and the information needed to decide gives them a clear next action. The conversation then closes in one round instead of four.

Takeaway

Treat every message as a decision you are handing to someone. The more of that decision you have already prepared, the faster it comes back resolved.

Endless back-and-forth rarely comes from difficult people or complex topics. It usually traces back to messages that lack structure, context, or a clear path to a reply. This system closes each gap. Put the action first, include the details needed to act, and plan the response before you send.

To start, take your next three outgoing messages and check each one. Is the request in the first line? Could someone act on it without asking anything? Is the reply easy to give?