Emails in CC often cost recipients valuable attention, but conversely add little value. How many of the emails in CC would you rather not have received today?
Emails are still the most important communication medium in companies and organizations. However, emails are not only used for communication, but also for discussion, information filing and information retrieval. This overloads the medium of email, because it is intended for a different purpose.
While CC distribution lists are an obvious way for the email sender to provide information, it is an inefficient method that is more akin to a watering can. Email CCs subsequently tie up productivity in recipients that could be better used for other purposes. What alternatives are there to improve the situation?
Emails from a different angle
To get a different perspective, we analyzed various email threads. Instead of looking at the content of the emails, we examined them structurally. Topics became colored blocks to abstract from the content. The versions, i.e. how a topic develops in the email thread, are numbered. Example of the information structure of an email thread:
Jennifer writes an email with a subject (green). Peter and Jennifer take turns referring to the last status of this topic (orange arrows) and in the fourth version (number 4) everything is resolved.
This email thread looks textbook, but is likely to be rare in practice. When did you last see such a straightforward email thread?
There is also the question of the distribution list. There are three people in CC who read the entire thread in each round. This means that three people reading along have each traced the thoughts four times. Was this commitment of concentration and work time necessary?
Here is an example that is more like what we encounter in our everyday work:
Let's not go too much into the details, because you know this kind of email from your daily work anyway. But since we're in the structural helicopter perspective, what are the issues in this email thread?
- Jennifer includes two issues (green and blue) in her initial email. Could she have guessed that the topics would be discussed differently? Would she have been better off sending two emails in parallel?
- Peter responds to the green topic, but does not address the blue one. That's fine if he has nothing to say about the blue topic. But already you have to gather the content from different places. They are still close to each other, but that will change soon.
- Then Peter introduces a purple topic into the discussion, which is actually about green and blue.
- Jennifer references part of the blue theme, creating the light blue theme in version 2a. Also, in the green theme, she accidentally refers to her version 1 instead of Peter's version 2.
The actual issue is visualized by the orange arrows. In order to understand and comprehend the email thread, you have to mentally follow the orange arrows backwards every time you read it. This requires time and, above all, concentration. This effort is not only multiplied by the number of emails in the thread, but additionally by the number of recipients including those in CC.
Because emails are often used as resubmissions, there are additional rounds of someone having to piece together the contents of the email thread in their head from fragments.
By the way, many of the email histories we analyzed were actually even more complicated.
Small problems add up to big ones
Is it worth tackling the issue of email CC in general? Absolutely. A small calculation example: If, in a company with 200 office workstations, each employee sends 3 initial emails a day, while 3 people are in CC, the thread of this email is read 5 times (4 replies), and reading it takes 5 minutes of attention for everyone in CC, then this workload is equivalent to 5 full-time employees.
Since it is not easy to find five suitable employees in times of a shortage of skilled workers, the possibility of drawing the same amount of work from the existing pool is quite attractive.
This is only a calculation model, but for a calculation you have to start somewhere. Decide for yourself whether you consider the numbers you've applied to be realistic, or perhaps more conservative. Emails in CC are just one point where processes can be optimized and workflows made more efficient. In the end, they are just a symptom of a deeper optimization need anyway.
The interruption of workflow through redundant communication is an important leverage point to increase productivity.
Improvements to the email communication medium itself:
- Writing clear and understandable emails using the BLUF method is one of the better approaches, see blog post BLUF - Bottom Line Up Front->.
- One topic per email. When in doubt, send multiple emails at the same time to reach different discussion threads.
- Generally first consider who should really be in CC and not act reflexively.
- In long emails, always summarize the current status for all those reading along.
Email rules are impractical
Email is a flexible communication medium in which rules can hardly be monitored. Without control, rules are at best appeals that will be forgotten in a short time. After that, everyone goes back to the usual. Therefore, rules for emails tend not to be effective.
The benefit of chat or ticket systems
If a separate communication concept is developed for chat systems such as Teams or Slack, they can improve processes and speed up discussions. To access information they are rather unsuitable, because chats have a short life span and topics mix too much despite the use of channels.
Ticket systems provide a structure that is ideal for certain areas of application. Sometimes ticket systems are used as work management systems. As a result, they become misappropriated and unwieldy. In addition, long comment threads develop on individual tickets, which are just as counterproductive as long email histories.
The goal of Octaved Flow is to have fewer emails sent in general because email is widely used as a communication tool, but it is not really efficient. Especially internal emails with long email histories and many CC often paralyze productivity instead of boosting it.
The key in Octaved Flow to avoid redundant emails is the Wiki. Wikis are a central source of information with a predefined structure and clear organizational concept. Everything that is discussed and voted on individually is a separate block, called a board post. Because the whole board post is always displayed, you don't have to gather the information from different places, everything is always complete and gapless in one place.
Here is the information structure from the second image from the top when using Octaved Flow's Wiki:
The relevant information is visible at a glance (green, blue, purple). To reflect the current state of discussion, the board posts have versions. You always see the latest version and only access an older version if needed (as you have seen, this works very poorly with emails). The messy, orange arrows are not present.
Using different types of board posts makes communication more transparent and clear. Use the Release type when you need a release, Question when you need support, and FYI to let specific people know. Or use @firstname lastname to mention someone in a meeting report, for example. Traffic light colors make it easy to see if a question has already been answered.
Instead of receiving information "unintentionally", those who previously read along via email CC only access the information when needed. Alternatively, they are mentioned when the discussion has reached an appropriate point.
Bon mot at the end - what CC means
CC stands for "Carbon Copy", a term from the days of the typewriter, when carbon paper was used to make copies. Even the first email sent in Germany in 1984 contained a CC recipient.
- Blog post, BLUF - Bottom Line Up Front, writing emails so they can be read efficiently->
- Blog post, working in flow, why too many interruptions from communication paralyze productivity->
- Blog post, prioritizing efficiently, getting decision-making processes out of emails and approaching them with methods and tools suitable for that purpose->