Subject: Send better emails


  1. I want everyboy to change how they write emails, especially long ones.

There are good reasons to sometimes write long emails. However, I have seen too many that are ineffective. No action is taken until you bring the subject up later, and then it's almost as if the recipients never read it. And for good reason - they only got two or three paragraphs in and stopped reading. They never saw your conclusions, or your requested actions.

You and your recipients will be happier if you follow the guidelines herein.


The basic idea is simple - write your email such that whenever the reader stops reading, they have read the most important part for them to read. If they only read 10%, make sure it's the 10% you really want them to see.

Order of content:

  1. ACTION - The first lines should be a numbered list of the actions you want people to take. ALMOST NO DETAIL! Save detail for the "gory details" section.

  2. CONCLUSION - Now state your conclusions ... without supporting arguments.

  3. GORY DETAILS - This is where you build the case with all your data and logic.

Ideally, you've been succinct enough in 1 and 2 that even the most busy executive had time to get through them.


You see, the problem is that the most-important readers - the people with the authority to make things happen - they tend to be overworked. Everybody depends on them, so they have very little time. That's why it is unrealistic to expect them to read all the way through a long email to find the conclusion and action items. More often than not, they stop reading after the first screen. Given that you probably spent 2 hours or more writing it, an unread email is actually worse than no email at all.

Most people write by building a case. They lead the reader through a set of logical arguments, followed by their conclusion. Finally, they request action. This kind of email needs to be turned upside down. I sometimes tell people to write the email normally, then cut the last paragraph and paste it at the top. That alone probably gets you half-way there.

A few other suggestions:

Note that I started the "Gory Details" section of this page with a more-detailed statement of the problem. You frequently have to also state the problem near the top; the actions and conclusions may make no sense without the context of the problem you're trying to solve. Just be careful - it's easy to drift into providing supporting evidence too early. You want the early problem statement to be short - just enough so that the actions and conclusions have context. Save the detail and support for the gory details.

It can feel awkward to invert the order like this. Once I get into the gory details, I give myself more freedom to write the way I want to write. After all, the only people reading that part are the people who are *interested* in the gory details. So I'm less likely to lose the audience in the middle. (And even if I do, at least I got the really important stuff out of the way right up at the top.)

In case you haven't noticed, I've structured this article in the same way I try to write long emails. (And yes, I sometimes forget to follow my own rules.)


Bug reports, though technically not emails, should also be written similarly, except instead of starting with ACTIONS, start with THE PROBLEM. The goal is that a busy manager can get the gist of it after reading half a screen.

Many bug reports start out with instructions on how to reproduce the problem, followed by a description and discussion of the problem itself. It can be hard (and time-consuming) to find the actual problem statement.


THE PROBLEM: a short description of what the actual problem is. Don't get bogged down in suggesting a solution. It should not be, "change X to do Y." Rather it should be "X does this bad thing." (Don't explain yet *why* that thing is bad; just stick to the facts.)

CONCLUSIONS: tell why it is bad. Rate the urgency of fixing. This is where opinions and judgement calls are important! But be opinionated about what is wrong, not about a proposed solution.

GORY DETAILS: give instructions on how to reproduce the bug. If not easily reproducable, at least tell what was happening when the bug happened

Finally, preferably as a separate comment, you can give suggestions for fixing.

Retrieved from ""