Learning to work with e-mail

A few years ago, while working for agence pheromone in Montréal, I gave a presentation on using e-mail in the workplace. Unfortunately, it is still valid. This is part of the little things that are not taught.

Working well with e-mail is essential for numerous reasons:

• reducing stress at work
• learning to NOT read e-mail
• learning to work together under common rules
• making your workflow more fluid

The volume of mail received each month can be intimidating. Many people mention an objective of the week is "INBOX zero." That is, all e-mail is processed. Wouldn't it be better to set a goal to end the week knowing your work progress, ​​what has been done and what remains to be done? E-mail is just a tool to achieve this. A devilishly effective one when used correctly. It is the purpose of the following few recommendations, easy to implement in a small structure as well as among your customers.

E-mail is very simple. It consists of a sender (From), one or more recipients (To, Bcc, Cc), a subject line ((Subject)), and text. When each of these fields is used properly, many problems are solved.

About the subject line

The subject line is certainly the first pitfall in wasting time generating and processing e-mail. Here is a list based on actual situations at work:

1. Management meeting, tomorrow Wednesday 2PM
2. Project ballpark for comments on video section
3. Acme Inc
4. Love For Ever - Microsite Iceland - Kick-off
5. concept map

Can you tell those relevant from the catastrophic ones?

Of course, our immediate answer depends a lot on our own knowledge of the matter.

1. Good: "Management meeting, tomorrow Wednesday 2PM"

   E-mail is dated. "Tomorrow" tells me this is this week and Wednesday is the day of the week. A lot of information is already available and I know if I should read that mail or not. Be careful of contextual dates in case of an international distributed team. Note that perhaps [Agenda] is missing from the subject line, if this is the case. I would probably rewrite this: [Agenda] Management meeting, Wednesday 18 March 2009 or [Agenda] Management meeting - 2009-03-18. The complete logistics of the meeting should be in the body of the message.

2. Maybe: "Project ballpark for comments on video section"

   That message depends a lot on the shared context of the people receiving it. It will become very difficult to understand when a new employee joins the team or when you reread it in 3 years. The project in question is not mentioned.

3. Bad: "Acme Inc"

   This one is very bad. It supplies no context on the content and doesn't help me determine whether I must read it or may ignore it while I focus on useful work.

4. Good: "Love For Ever - Microsite Iceland - Kick-off"

   From this subject line I know the name of the project is "Love For Ever", that it is a Microsite for Iceland and it is probably the mail explaining the context of launching the project.

5. Bad:"concept map"

   Same comment as for "Acme Inc", the content is probably about a concept map, but why and in what context? Beyond a few months, the information will be generating noise.

The subject line is a filter. It allows you to:

• determine the attention level required (if you are the recipient)
• signal to your colleagues they must read (if you are the sender)
• throw a better anchor for the future when the mail has become an element of archive or memory.

About the recipient(s)

Another pitfall of work e-mail is the misuse of recipients. How often do we receive e-mail that isn't immediately useful to the execution of our work. In the To field you must include the person who is responsible for the action to perform or the person who must absolutely read the message. The more you add the less effective your message. It is always best to have a single point of contact even if that person works in a team with another person on a given task. The work will be done but one person only is responsible for its execution. Some messages serve to provide context more than action, as we'll see below.

Why does it matter? This allows each team member to create a dynamic mailbox displaying all messages that directly involve them. These messages then have priority for work progress.

Having chosen the person to whom the message is addressed, we can inform another who isn't directly involved in the execution but who needs to know progress is being made. The Cc field exists for this purpose.

Mailing list archives on the Web (private of public) are an essential element to e-mail based work in an organisation. If you work for one and Web mail archives aren't available, add it to your agenda as a work requirement.

Mailing lists with Web archives help get over the cognitive overload and stress of INBOX zero. They let you avoid to read everything, even delete messages if you do not wish to keep them.

They're an inexpensive way to automatically archive information, keep the context and ensure the continuity of history in the organisation without your presence. In most cases organisations have existed before your period of employment and will exist after you leave. Each message and/or discussion having a unique Web address (URL), it becomes possible to recall the context of a discussion, a decision or an action without having to resent a flurry of twenty or so top-posted messages.

You can create lists that are department-based, project-based, including your clients or not (I recommend you include your clients on projects lists).

For a given work message, fill the Cc field with the related mailing list. Person to person messages are useful only in specific circumstances such as human resource matters or high confidentiality. All the rest must be shared. If it is not the case, it is symptomatic of a workflow issue to fix in your organisation.

We covered the potential recipients of a message. The goal is for everyone to progress in work and avoid sources of distraction while keeping context in the background. A received message is not necessarily a message to read, everything depends on the elements that are included.

The body of the message

You have to send a message so that Paul can perform a precise task. You've included a recipient, a discussion list and given context. The subject line is good. Remember to begin your message with the name of the person to whom it is addressed. Think of it as a meeting with several people around the table. When you address someone, there is a physical and verbal language that accompanies your communication with someone, whether you're giving instructions or seeking an answer. The same goes for e-mail; name your interlocutor.

It is likely that the person needs contexts. A previous discussion archived 6 months before, the name of the project in question, etc. Try to be brief but concise to enable the person to understand what is being asked.

If the purpose of your e-mail is to get a response, you must ask a question. Your recipient is not supposed to guess whether it is information, a task to perform or a question.

What is the desired result of this message, what is the instruction that will achieve this result? We just want to maximise efficiency and save time for everyone in the exchange of information.

An example and its improvement

This received message indicates it is about a report on a release of the week prior. It includes interlocutors, has a subject line. The content is brief, perhaps too brief. It is already well done. Can it be further improved?

The subject line can be improved if conventions have been (collectively) agreed for [mobile-matcha] messages. A quick glance and one can tell in which category or project the message belongs. People can automatically sort messages by creating filters.

The subject line indicates the report is in January 2014. In this project there are monthly reports. After a few months, we get a global ideal of its evolution. Note: this is in response to another message which subject line was less relevant.

We have a single contact. This is a question to someone who can provide an answer, probably the main developer. The discussion list for this client's projects is copied, as well as someone else who needs to know of the project evolution, perhaps the main contact on the customer's side.

The body of the message starts with the name of the main recipient. Precise questions are asked and context is supplied via information that is already on the Web. It ends on a thank you note.

Progressing work with healthy communications

Sometimes, in a work relationship, e-mail is an opportunity to let one's hair down. This isn't professional. So, another advantage of involving customers in discussions is that it may prevent such misconducts in communication.

Using insult, inappropriate language, or trolling, is the best way to put a wrench in the gears of your project and not go forward. If you are upset because the project is not progressing as you want, insult is the best way for your project to remain off-rail. Be polite, it saves time and efficiency.

Conclusion

Those are very simple rules. They allow you to handle with peace most of your messages. They do not cover everything. There are many other things, but that could be for a more complete presentation.

1. Use dynamic filters; they let you build and undo work contexts for your messages without worrying about sorting them.
2. Use text for your messages, not HTML and no colours. You don't know if your contacts use a mail user agent that can display your messages as you crafted them. If your colours disappear, the message becomes hard to understand and you are wasting time.
3. Do not send a Word document containing what you wish to convey. If this is text, type it directly in your e-mail.
4. If the document is big, if it is meant as a reference for a project, do not send it over e-mail, but put it online first in a controlled environment shared by the organisation, and place a link to it in your message.
5. Web archives of your messages are here to preserve the memory of the project. Send the URL of an old message to recall context. Do not top post, remove everything that is not necessary and answer in line and in context.