Writing an effective email

Opening an email with a hello bothers nobody. What wastes time is an email that buries the actual request in the third paragraph. This note covers a simple method for writing — and receiving — better emails.

The principle: BLUF (Bottom Line Up Front)

BLUF is a writing method with military origins, since picked up by engineering and the wider professional world: you put the essentials — the request, the question, the expected action — in the first lines, right after the greeting. Context and details come afterwards, for whoever wants to dig in.

In practice:

• A clear, specific subject line rather than a vague one: "Question about quote 2024-03" rather than "Question".
• One or two sentences after the hello are enough to state the request.
• Context and technical details come after, not before.
• An email ideally fits in under two paragraphs; beyond that, structure it with bullets or subheadings rather than making it longer.

Source: MIT Communication Lab — AeroAstro, "How to Write Effective Emails".

Before / after

An example, for a technical review request:

Same request, but the second version states right away what is expected, from whom, and by when.

Subject-line prefixes

Some technical teams prefix the subject line with a tag that signals the expected action before the message is even opened. Two common conventions, sometimes combined:

• General tags, inherited from technical mailing lists and IETF lists: [Action required], [FYI], [Urgent].
• More precise tags, in the spirit of the Minto pyramid (answer before justifying): [INFO] for a plain hand-off with no action expected, [DECISION] or [APPROVAL] when the recipient has to decide or sign off, [ACTION] or [ADVISE] when a specific task is expected, with a deadline — for example [ACTION] Sign off on quote 2024-03 by Friday.

EOM — when the subject line is enough

If the information fits in the subject line, it stays there, followed by [EOM] (End Of Message) — for example "Meeting moved to 3pm [EOM]". The recipient knows there is no need to open the email. An old convention, still common in internal company threads.

Beyond email

The same principles apply to any technical writing — and to tickets, Slack or Teams messages, where the point gets lost in a wall of context just as easily. The Google developer documentation style guide holds documentation to the same standard of clarity and concision.

It is also the logic I apply to systems: what matters should be visible without having to open the enclosure.