Factors to Consider Before Hitting the Send Button

Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.

Sending email is so easy and straightforward that we’ve assumed this is a common skill that everyone has.  While it is almost ludicrous to think that training on ‘sending email’ would be beneficial, perhaps that isn’t such an odd thought.  There’s more to consider than just a set of email ‘rules of etiquette’ (although this article does share a few tips that probably don’t appear elsewhere).  The novel thought here is applying the Getting Things Done framework before ever hitting the send button.


Article Summary

Have only 60 seconds to read this article?  Here are the highlights:

  • When we go against commonly understood rules of email etiquette (e.g., by sending length messages), we’re almost always disappointed that our email does not achieve the desired outcome.
  • Etiquette lists are pervasive on the internet – I’ve includes links to a few that are applicable to project teams.
  • These are my tips when sending email  (derived from an analysis of my incoming and outgoing email traffic; a similar analysis of your email traffic might result in a similar list):
    1. Master the art of a concise message. No one reads long messages anyway.  Try a limit of five sentences.
    2. Front-end load your message. Start with the message in the very first sentence, then follow that with your supporting information.
    3. Meet or call instead of sending email. Talking is more effective if you have a lot to cover, or for complex topics.
    4. Publish documents, don’t send via email. Sending documents via email to someone may be simple for you, but creates a documentation management nightmare for the recipients.
    5. Develop communication channels (e.g., Blog, Discussion Board) to replace some emails. Sometimes it is better to publish on a Blog or use discussion boards.
    6. Handle complex topics outside of email. Create a more effective forum (e.g., conference call, meeting) for controversial topics,
  • The one big technique: use the GTD framework when sending email. While we think of Getting Things Done as a method for handling incoming work/email, apply the framework to your task of sending email.


My Story – A Terrific Email, But Too Lengthy . . .  and Unread

It seemed like a good opportunity to help.  My boss had sent the question out via email to  a few people, and I had the answer.  Time to get started on a response; 30 minutes later I had my reply of 1500 words of incisive explanation ready to send.  I even added a few people to the CC: list who undoubtedly would want to read my comprehensive reply.  Completed the final proof reading and spell check, and then clicked the send button.  Off it went.

Three days passed without a single reply.  How could this be?  I checked in with my boss, who, as it turned out, had not read my email.  I contacted three other recipients of my reply and was crushed: no one had read it.  Claimed they were too busy to read such a lengthy email.  Of course I was aware that sending lengthy email messages was a problem, but I failed to see how that ‘rule’ of email etiquette pertained to me and my important email.  Rethinking this disappointing situation, it occurs to me that perhaps there is something of value in those email etiquette lists.

There are many sins of email.  Violate any one of them and chances are that your email will not receive the due attention and response that you’d like.  You can pretend that they don’t apply to you because of your position in the company or because your topic is so important, but you will be deluding yourself.  Periodically revisit those lists to refresh your ability to recognize when you are about to breech a rule of etiquette.  This article suggests five tips when sending email in the work environment and also provides references to other, lengthier lists. More importantly, the final suggestion (below) is to apply the Getting Things Done framework before ever hitting the send button.


Sending Email – the problem

It’s a common situation: you send an email with an anticipation of a positive result.  Instead, you find that your email is ignored, the attachment is unread or misplaced, your words are misinterpreted, you are flooded with requests for clarifying information, the fruits are your labors are not used, or the expected responses never materialize.

In short, your email doesn’t give the intended results.  This doesn’t happen to all of your sent email, but it happens to enough of them that email no longer can be considered a fully reliable method; you just can’t be certain that others will receive and handle your email.

In spite of this lack of confidence in email, there are steps you can take that will improve the chances that your email will receive proper attention.We could start by looking for some “email etiquette” list – and this is a good idea if you are not familiar with a general set of conventions for the email that you send (However, I do wonder sometimes how these lists are generated; are they just a set of ideas, or was there a method that identified a problem and its significance which then resulted in constructing a reasonable ‘rule’ to solve the problem?).  Here are a few good ones: Microsoft Office Online Tips, Microsoft Small Business CenterFour Tips from Harvard Business Publishing, Harvard Business School Tips for Mastering Email Overload,  and PC Mag 25 Golden Rules of Email.


Using Your Sent and Inbox Folders to Identify Poor Email Behaviors

If you’re already familiar with such lists, then dig into your own project culture to uncover inefficient email behaviors - with a goal of finding about 5 that seem to occur frequently with a significant impact to your project team.  From this, we are looking to identify actions the sender can take to improve email effectiveness.

You’ll look at your sent folder to understand your own email behaviors, and then scan through your inbox to see the problems that others are causing for you.  A small number of badly behaved emails aren’t all that much of a problem – look for widespread patterns that are hurting the effectiveness of the team.

Looking at my inbox and sent folders, I have made several observations about emails that I’ve sent to others and that others have sent to me.  Analyzing the impact of the items in my list, it was no surprise that the Pareto principle was in effect here.  Just a few problems, listed below, constitute most of my email inefficiencies; this also implies me that my project teams generally are acting within the guidelines of most email etiquette lists. (Also, I found almost no instances of the ‘simple’ problems like using ALL CAPS, poor grammar, missing a signature block).

You’ll have your own list of observed poor email behaviors, and you’ll need to make a judgment call on which of those behaviors are seriously impacting team effectiveness.  Here are the top 5 items on my list:

  1. Too many emails with attachments that I was expected to read and file.  About fifteen of these were weekly status reports.
  2. A few overly verbose emails on critical topics, from two different people.
  3. Moderate volumes of informational email from me to large distribution lists.
  4. Large numbers of email received from a seven individuals.  Also discovered large numbers of individual emails from me to a six individuals.
  5. Five lengthy email threads, two with over 15 received messages in each thread.

My complete list included many other ‘email infractions,’ but a moment’s thought led me to conclude that these items had essentially no negative impact to me or my project teams.  When you create your own ‘Top 5’ list, be sure to include only those items that you think have a pronounced impact on your team.


Six Tips For Senders - Preventing Problems Caused when you Send Email

Nearly all of the problems with email overload are experienced by the receiver, yet these problems are almost universally caused by the sender.  I’ve focused on a small set of key tips for sending email; these are based on an analysis of my email, but I have I’ve found that these are applicable in most organizations and project teams that I’ve directed:

  1. Master the art of a concise message. Long ago I scoffed at terse replies, thinking that the responder had given inadequate consideration in responding.  I’ve done a 180 and now see the wisdom of brevity; your desire to create a lengthy email is most likely an indicator that email is not the best vehicle for that topic.  No one reads long messages anyway.  Try a limit of five sentences.
  2. Front-end load your message. Start with the message in the very first sentence, then follow that with your supporting information.  In fact, the best start is to include the essence of the message in the Subject: line of the email.  You're not telling a story with a fabulous climax so there's no point in having your reader wait until the final sentence before encountering the real purpose for the email.
  3. Meet or call instead of sending email. A large number of messages to or from an individual is a clue that you need an ‘wide bandwidth’ communication channel; email (an inherently narrow bandwidth mechanism) is not efficient in this situation.  In circumstances involving complex topics or sensitive situations, calling or having a face-to-face meeting is much more effective.
  4. Publish documents, don’t send via email. Sending documents via email to someone may be simple for you, but creates a documentation management nightmare for the recipients.  Those documents belong in your document management system or on a well-organized Wiki anyway.  (This is the focus of the second articleof this series).
  5. Develop communication channels (e.g., Blog, Discussion Board) to replace some emails.  Find yourself sending frequent broadcasts to the entire project team?  Better to publish on a Blog.  Discussion boards are better suited for electronic discussions on project topics.  If email is your only viable channel for broadcasting information, then collect up multiple messages for a periodic bulk distribution (e.g., a weekly newsletter).
  6. Handle complex topics outside of email. Controversial topics, issues for which participants have varying degrees of awareness or understanding, and finalizing significant decisions are examples where email is not up to the task.  Create a more effective forum (e.g., conference call, meeting) for such cases.


What do you want the recipient to do with your email?  Considerations

There’s quite a bit you can do that goes well beyond simply applying email rules of etiquette.  The third article of this series introduced David Allen’s Getting Things Done productivity method.  The focus of his book and materials is on managing your incoming and existing work.  If that is only time we utilized GTD methods, then we’ve missed an important trick: we can also apply our understanding of GTD workflows when we are sending email.

While we think of Getting Things Done as a method for handling incoming work/email, let’s apply the framework to your task of sending email.  Consider what you want the recipient to do with your email and how you can best enable that result.  Put yourself into the position of the recipient and help them with the decisions they will make.  You’ll already know the questions that the receiver will ask in determining how to handle that email.

As the sender ask yourself those same questions before ever clicking on the send button.  The answers can help you improve the wording of the email (so the receiver’s GTD questions are easier to answer), choose a different approach instead of sending email, add or delete from the distribution list, or make other adjustments that will help.  This is a powerful approach that goes far beyond the routine application of email etiquette rules.

As you create and ready an email to be sent, walk through these questions based on the GTD framework:

GTD Processing Framework

Factors for the sender to consider

If your email is not actionable, the recipient will:  

1. Trash – read your email then toss it  (Read and Toss – R&T)

Many messages are obviously R&T.   Sometimes a cue will help the reader:
  • Include “FYI” in subject line
  • Sometimes FYI isn’t accurate.  Consider creating a project team convention: e.g., “R&T” in subject
Recipients sometimes use heuristics to classify a message as T&R:
  • Excessively high number of TO: addressees
  • Overloaded recipients may choose to toss messages, sometimes without reading, where they are a CC:

2. Incubate - tickle it for possible later action

Avoid this type of non-actionable email, as the value of such an email is dubious.  With this email it is unclear what the recipient should do with it now.  Upon receipt, it creates administrative work for the recipient to file and later to revisit your email.  Consider what you want to accomplish with the email, possible transforming it into:

  • An R&T email message, or
  • An actionable email message

3. Reference - The recipient will file this for later use.

Eliminate this type of email.  If you own the information, and that information must persist and be retrievable in the future, then you should publish it in a project repository or Blog so it can be located easily.  Don’t turn your recipients into documentation clerks.

If you must send a “for Reference” email, consider how long you want the recipient to retain your email.  If this is a long period of time, then you are placing a responsibility upon them that is rarely easy to fulfill; in fact, that content will likely become outdated or misplaced.  More on this is in the second article of this series.

If your email is actionable – the recipient will decide the very next action:  

1. Do - if less than two minutes.

Help your recipient readily recognize the action for them that can be quickly completed:
  • Include "Action:" in the subject line.
  • Provide a clearly articulated question to answer or action to complete.  A clear message will avoid clarification questions or unusable responses from coming to you.
  • Put in the effort to be concise.  A lengthy description probably will not be read, and would relegate this to a deferred action.
  • Confirm to yourself that action is needed.
  • Specify the date or time frame in which you need a response.  If you omit this, then you are depending upon the judgement of the recipient to determine the urgency of your request.
  • Ensure that you are asking the right person
  • Sometimes a CC: to other people or the recipient’s boss is needed, but recognize that this may cause hard feelings or cause delays as a perfect response is constructed and reviewed.

2. Delegate - track on a “waiting for” list.

Minimize this type of email. In many cases, your primary contact’s actions of reading and then delegating this email only adds delay and doesn’t add value.  If you need to get information to or from someone in the primary contact’s project team, then establish a flow directly with those team members; if necessary you can set up the flow of information that has the primary contact on the CC: list for those exchanges.

In some instances your initial communication will be through a primary contact (e.g., when you don’t know who should handle the email), but move quickly to establish direct communication.

3. Defer - put on an action reminder list or in an action folder.

This is similar to a “Do - if less than two minutes” email, except this requires more work by the recipient. The recipient will prioritize this email with other ‘large’ requests.

Help by alerting the recipient of the urgency and due date – you’ll be more credible by avoiding emotional or subjective appeals and stick to the business need or impacts of a late response.  Clarity in your email is essential.


What’s Next?

The 'Six Tips for Senders' and use of the GTD framework can help your receipients become much more effective in handling the emails that you originate.

If you want to approach 'improvements when sending email' as a team activity and joint commitment, then use this article as a framework for a project team discussion. You might exchange information like:

  • Methods you use and factors your team currently considers when sending an email message.  Debate the viability of the Six Tips for Senders presented in this article and select a few to implement.
  • Discoveries you’ve each made in analyzing your outgoing and incoming email.  What key points does this highlight about sending email your project environment.
  • Views on how well the GTD framework would work as a quick 'checklist' to be considered prior to sending any email.

If you are approaching 'improvements to sending email' as an individual activity, then chose a few of the 'Six Tips for Senders'  to implement and then focus your attentions on the GTD framework (presented in the section immediately above).  You might print a copy of this framework to jog your thinking prior to hitting the send button.  Let your recipients know of your improvement activities and seek feedback from them on any perceived change for the better.