SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Writing Better Emails

In January 2009, I made the transition back to being a senior DBA. One of the first things my manager pointed out to me was that I needed to improve my email writing. His main beefs:

  • I took too long getting to my point.
  • I sometimes forgot about the target audience.
  • I was wordy.

He noted the good things, too. For instance, in emails that had to detail a technical issue, the details were accurate and complete. But the majority of emails weren't of this nature. Here are some things I've adopted, after reading a lot of advice about how to write better emails.

State the Point in the First Sentence:

Unless I'm looking to do an introduction or something of that sort, I try to make the point in the very first sentence. That way, if for some reason the email doesn't apply to the person receiving it (especially since emails tend to be forwarded around), they know immediately it's not applicable to them. Also, if the email is applicable to the given person, he or she knows exactly what I want right up front. Emails aren't supposed to be a test of reading comprehension.

Keep It Short:

I now try to keep the email body itself fairly short. I may make bullet points to clearly identify the highlights, but otherwise, if I start going over about 5-6 sentences, I take a hard look at what I'm writing. If I am doing a technical write-up, it probably needs to be in a separate document and included as an attachment.

Include Notifiers to Indicate No Reply/No Thanks Necessary:

I've learned to use NTN and NRN when I don't expect anything back. As a DBA there are a lot of times when I'm completing a task and letting a developer know the task is done. I don't need the email saying, "Thanks!" So I included NTN = No Thanks Necessary the first couple of times I deal with a particular individual and then simply go to NTN. This prevents him/her from sending an unnecessary email and me having to process an email that inherently has no value.

Target the Email Appropriately:

I see a lot of times when everyone and his brother is included on an email. This is especially true on a heavily technical email thread where a bunch of business folks are included. The thread might as well be written in Japanese to them. What's the point of including them? Better for the technical folks to work through the issues and then communicate to the business users, in business terms, in a separate email thread. The same is true on the other side. If it's a long thread, such as one trying to determine a root cause and it's important for others to be updated periodically, then do so, again, using appropriate language, as the need arises. Don't include that on the same thread as the technical nitty-gritty. It just confuses things.

What if you receive an email that you need to reply to but it has too many folks on there? I unashamedly trim the address list. And I include a comment as to why I trimmed it. I usually find that the trimming is honored.

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by Steve Jones on 4 May 2011

Good points, and a lot of the same advice I give authors. Get to the point and stick to the point.

The NTN and NRN are good ideas. I haven't used them before, but I will start. As nice as it is to get thanks, it's also processing time.

Posted by aquilahanise on 5 May 2011

I agree with Steve on this one. One tends to find a number of authors dwelling on issues outside of what is important.

This sometimes becomes a distraction and readers never understand the point of the article/blog.

Posted by dave.clark on 5 May 2011

I think that as technical people, we tend to write all of that technical stuff in the emails.  I agree that we definitely need to target the audience and understand if what we are writing is going to mean anything to the reader.

I find myself always trying to shorten my emails because they tend to be too lengthy.

Posted by Nick Hodgson on 6 May 2011

Some really interesting points.  They are all obvious - now that you've pointed them out!

Also, interesting re th NTN / NRN, how many emails have been archived and backed up around the world that simply say "thanks".  

Posted by sjb500 on 6 May 2011

I like the idea about NTN/NRN but I fear I'll generate even more email replies asking me what the acronyms mean ;-)

Posted by thomas.bast on 6 May 2011

I plan on adding the NTN and NRN definitions just above my signature. I also use EOB when dealing with dates. Example:

"I will send you the stuff by EOB (End Of Business) on 1/1/2011.

Posted by Bob on 6 May 2011

re: stating the point in the first sentence - isn't that what the subject line is for? I'm curious how you distinguish between "the point" and the Subject.

Posted by K. Brian Kelley on 6 May 2011

Bob, it would be if I started the thread. But if I don't, it's usually better for me to leave the subject alone. In that case, since I'm responding, I make that first sentence a good one.

Posted by JimFive on 6 May 2011

I would add one more item to the list.  Don't just keep forwarding/replying with the whole thread in the email.  At some point summarize it and dump the cruft.



Posted by Mike Good on 6 May 2011

Good points.  

For me the challenge of being concise is wanting to be precise, which requires qualifying what would otherwise be simple statements.  Simple statements may be shorter & easier to digest, but technically might not correct in all cases.  People I have discussed this with generally just want simple statements anyway.

Maybe a solution to eliminating NTN/NRN queries would be to implement these as hyperlinks rather than straight text.

Anyway thanks for post.  

Posted by Jayaram on 6 May 2011

I like the option of NTN/NRN.

Posted by rporter 68345 on 6 May 2011

What do you do when you need a fair amount of detail? If I include everything relevant, people say the message or document is too long. If I just hit the high points, then I get a bunch of questions and requests to elaborate or clarify. That back and forth is very time-consuming compared to just writing it all out at the start. If it's a document, the revised document ends up being very like what I originally produced. Worse, in my opinion, is that for email, it leaves the necessary detail spread over several messages.

Posted by NULLgarity on 6 May 2011

I agree with almost everything here, but I would be more likely to use TAA (thanks are appreciated) than NTN.

Posted by K. Brian Kelley on 6 May 2011

rporter, email is the wrong medium for that. If there's quite a bit of detail needed, I usually find that producing a separate document with the details (and the formatting to make it easier to read and follow) is the better approach. So I'll put the summary in the email and refer them to the document if they need details. It also means the document can be placed on a SharePoint or intranet web site if retention is important and then you can simply use a link to refer to it.

Posted by dan_chr on 6 May 2011

Rporter, what I do in such cases is write the details into a separate document and attach it.  Then cover the high points in the body of the email and indicate that full details are in the attachment.  I have found this to be well received as the people who only need the high points don't have to wade through all the details, and for those that need them, the full details are readily available.

Posted by Rafael A. Colon on 6 May 2011

I agree with 99% of this article, but I will never tell anybody not to send an email with Thanks or any other kind of signal to remind us that we even within the walls of our business we are living in a society were good manners are important, forget about processing time, what makes the difference in any business is the quality of the people behind it, and is good to always try to keep an good atmosphere and cooperation among workers and business units. I know this by experince.

Posted by chris.s.powell on 6 May 2011

Another great acronym I am particularly fond of using is in the Subject line I tend to add a "- EOM" when I am merely informing others that a task is complete.  This End Of Message tag, lets the others know I am merely sending an informational bit and nothing is required on their end.

Posted by EFRAINVILLA on 6 May 2011

About your article... back i 1975 when I was a kid, .... just kidding :)   good advice thank you!


Posted by grayjohnr on 6 May 2011

I too have been admonished about unclear or wordy emails and have made an effort to improve my emails over the last several years. The most important thing I have found is to reread the email before I send it. I made several edits to this post to improve it.

One guideline you did not mention is to only include one subject in an email. I am going to break that by making several comments in this post.

Our team uses ROT: - read or toss, and FYI: - for your information

I have trouble with the idea of putting the contents of longer emails in attachments. People are less likely to stop and open the attachment, and I get questions back from recipients that were answered in the attachment. It is also easier to search for key terms when they are in the email body. I frequently summarize the email at the top and write or paste the technical details after the signature line -- my manager can see what they need and the other technical people can see the details they need.

Posted by mark.dalley on 9 May 2011

People seldom read the end of an email properly. The concentration curve of a busy person quickly tails off.

For this reason, two concise emails tend to work a lot better than one long one.

One could test this by inserting the following at the foot of an email:

"Tomorrow, you will be shot at dawn. This sentence, though untrue, has been put in to check how carefully you read your emails. Please forward to <email name> if you notice this paragraph."

It would be interesting to note the percentage response rate for emails of differing lengths.


Posted by Stephen_W_Dodd on 9 May 2011

You might often find this acronym - COB (Close of Business), instead of EOB.

Posted by Peter Maloof on 10 May 2011

A few things I try to keep in mind are:

1. One topic per EMail. I hate it when I get an EMail about a meeting, and at the bottom it says, "Oh by the way, can you create a new database this week?"

2. Sometimes I'll append '- Fixed' or '- Thanks!' to the Subject line, so the recipient knows the message isn't urgent.

3. If an EMail thread starts to veer off-topic (like from the meeting to the new database in #1 above), I'll change the Subject line from 'Meeting Agenda' to 'New Database'.

Posted by JJ B on 12 May 2011

I have to disagree about the "No Thanks Necessary" idea.  Not all e-mails go through.  And those that get through, sometimes something happens at the other end and the person doesn't see it or doesn't remember it.  When I get a reply back, even with one word: 1) I know at that moment that the e-mail was received, 2) I have documentation that I can save for future purposes that the e-mail was received.  If the person later claims that they never saw it...  I'm not saying all e-mails require a reply.  However, actively encouraging people not to reply so often that it requires an acronym would not be a direction I would encourage people to take.

I'd also like to say that the list, while complete for you, would be incomplete or misleading for others.  I find that most of the time, the problem with people's e-mails is not being too wordy, but not being wordy enough.  E-mails that are too short are often not communicating the point.  I hate having my time wasted (and imagine that multiplied by everyone who gets the e-mail) trying to figure out which of the many interpretations of the words was really meant.  I either have to spend time replying or just not know.  A perfect e-mail would be great.  But if an e-mail is going to error on one side or another, I would rather that the e-mail include a complete communication that I don't have to spend time interpreting.

I really like some of your other points.  It IS good to get to the point.  It is important to only e-mail relevant people.  It is important to consider your audience.

I use some of the techniques that others have posted here.  I will include details below my signature line when it makes sense.  I am also not shy about changing the subject line.  Finally, the most important thing anyone can do is to re-read the e-mail a couple times, preferably with some time between readings, before sending.  

Bottom line: respect the time of the recipients.  All else follows from that.

Posted by FargoUT on 17 May 2011

pmaloof -- excellent additions. Those three are often among my biggest pet peeves when I get email. Especially #1. My boss would always do that, suddenly request something at the bottom of an email that was largely irrelevant. It doesn't happen enough to warrant a discussion with him, but when it does happen, part of my soul dies. </hyperbole>

My biggest pet peeve is when people send me emails with no subject at all or the generic "Hi/Hey" greeting. That drives me absolutely nuts, and it screws with Outlook as they all get lumped together.

Posted by Old Dave on 18 May 2011

Addressing communication issues is a great topic for all . . . of us.

I am sure there are a zillion books and articles on the subject, thus emphasizing the importance.  

Perhaps sometimes technical people focus on their technical skills so the issue does not get the focus we need to be effective.  Sigh.  

A hundred years or ago, I attended a training class on memo writing (ancient term for email).

The bottom line was the style of the memo would change based on the reader(s).  If you did not know the reader(s), then just stick the basics.  

hmmm, such as adding a comment to a forum. . .

Posted by longstrd on 18 May 2011

Other Points of interest:

Do not assume the readers understanding or memory:

We want to be brief and to the point as a courtesy of the reader’s time, however we need to include a reminder of the topic or enough of an introduction so they will understand the context of the information.  

The subject line may be sufficient.  

You would have to know the recipient(s) and what amount of text would be effective prior to the new information you wish to communicate.

Proof Read – ugh:

So true.  You shoot off a quick email.  ‘do you want to go to lunch today?’.  You get a dozen comments on how you could have worded the email, you misspelled lunch, you left out the word ‘to’, etc.  Yeah, so even the seemly simple email.  Reread a few times, spell check.  If you are working on a business communication ask for another person to read.  Only prob. With the ‘other person’ is if they could just tell you if the statements are clear, do they understand.  Some people want you to make style or preference changes.  You got to make your own call on that.

Posted by longstrd on 18 May 2011

This may be better as a differnt topic, I thought perhaps this is related.

Paradigm shift:

What medium to use to provide information:

Not long ago I met a prior colleague who had started managing projects with SharePoint.  One element she loved was ‘no emails’.  

When I mentioned this issue to a director at work the response was ‘would never happen’.  Then again there was a director I worked with, who loved his Central portal of communication and information.  

During other conversations with people in the technical industry I have heard the ‘would never happen’ and ‘you don’t understand’ comments, concerning Centralization of communication.  

Too bad really.  

If you are in a situation where you have control over the medium of communication and you can design a central communication portal, SharePoint or not there are lots advantages over the ‘sending an email’.   Announcements here,   Detail docs there, QA test plans, requirement docs, Technical info, Instructions here,  all located together and not in a hierarchal tree structure.  Emails would be used as an alert only element.

Even so, people may not make use of the medium.

I suppose this is a topic for another thread. I just wanted to agree about giving notice that information is available and that information could be located elsewhere.

I do understand that there are people who would still prefer an email and would not wish to navigate to the Central location.   I understand these people are the reasons for the ‘would never happen’ statements.

Important to note:  The communications would still have to be well written.

Posted by longstrd on 18 May 2011

One last note of importance:

Covering ones . . . job.

There are situations where you send out an email with attachments, details in the body etc, regardless of the audience.  Those are the times you just want to be able to say, ‘yes, I sent that information out to everyone’.   Sad but true, yes.

Posted by bclayton on 7 September 2011

I like to split potentially lengthy and technical emails into Summary and Detail sections.  I create a bold heading called Summary, and in one or two sentences free of jargon, I summarize the issue.  For most email recipients, that is good enough and they can close the email.  I then have a Details section, where I can provide a more in-depth explanation of the issue for those that need it.

Also, it is crucial to have well-thought out content in the subject, especially if you work on multiple projects.  I like to have the project acronym (as they all seem to have), followed by a brief description of the problem, ideally in 7 words or less.

Posted by Krishna on 21 October 2011

Good one. I do follow most of the points as I picked them from my mentors. But still I mix the techinical content in the emails. Now I will put them in a separate doc so that email looks simple.

Leave a Comment

Please register or log in to leave a comment.