Email continues to be the main medium for digital communication in many companies, and at the same time is one of the biggest time wasters and productivity killers. Email is fast, convenient, and normal – and is often abused to a greater degree than any other digital communications technology.
One of the biggest problems is that email communication is frequently ‘unofficial’, as the contents are not centrally documented, transparent, and available to the entire organization. This does not mean that I want to condemn email as a whole – there are good and bad emails.
Admittedly, some of my colleagues are a little annoyed by these kinds of emails. After all, wasn’t Confluence brought in to (among other things) keep all this information together? This question, however, is a topic for another article.
In any case, many of the systems which we use send out automated email notifications: A colleague has expanded or commented on a Confluence page on which I have worked; a JIRA task that I created has been closed; someone mentioned me in HipChat while I was offline; the developers’ technical systems send emails for various occasions.
The recipient receives all of the relevant information without needing to fetch it. They can read messages quickly, remain in the loop, and, if they need to react, they can get into the system via a link in the email and reply centrally in a documented context. This is both effective and efficient.
Emails that can be deleted without losing the information
Keeping with the example of system notifications, these have another advantage – no matter what I do with the emails, their contents are not lost. Notifications from JIRA, Confluence, etc. can be noted by the recipient and then deleted. This is particularly easy with a tool like Inbox.
While the mailbox is emptied, the information is not lost, as it remains in the systems which sent the notifications.
Emails that can be handled quickly
Although I dream of a working world where most emails come from systems and personal emails are only written when absolutely necessary, we are still a good distance away. In the meantime, a good personal email is one which has an informative subject, from which the recipient can identify the essential contents and assess the relevance of the email to themselves. They are also concise and come straight to the point.
Such emails can be processed quickly and efficiently, especially if you can answer them briefly, e.g. “Yes, please!” (don’t shy from being brief in emails out of misunderstood courtesy). It is even better if you don’t have to answer the email as everything that needs to be said has already been said.
Emails with tasks
Tasks do not belong in emails, period. While the sender may initially find it convenient, thinking that they will simply write a quick email and their part of the task is done, but what actually happens is that queries about the task swiftly results in a confusing back and forth of emails. The task is not centrally documented, it has no visible processing progress, and it is not subject to a workflow.
Compared to working with a central task management system, tasks in emails are riddled with disadvantages, and the task priority and extent are unclear. It does not take much longer than writing an email to create and operate a task management process, and, in today’s world, scheduling, control, and transparency must be ensured when it comes to tasks.
Task management by email is not task management, but the digital equivalent of individual paperwork. In comparison, a system like JIRA has so many advantages that it could form its own series of articles.
Emails with attachments
This is a point which I have addressed in more detail in a previous article – that email attachments are a misapplication of technology. Firstly, an attachment makes things difficult for the recipients, as it means a context switch where the recipients must change from their browser to whichever program the attachment opens in. Local third-party software such as word processors or presentation software also need to be able to open the attachment, and may or may not be able to do so. This can be highly annoying.
A more serious consideration is the content aspect – an attachment is ‘dead’ and static. Teams can’t work together on it, which is what is important in today’s company. An attachment does not change, cannot be commented on, is not interactive, does not develop any further, cannot be found, and is not in a central place.
If this was not enough, attachments do not have automatic version control. If someone wants to add to it, they can only make changes manually if they are able to do so at all. This leads to different iterations of the same document in each mailbox of the parties involved (and some of whom are actually uninvolved), and no one knows which version is the current one. All of these problems are solved by a tool such as Confluence, which allows multiple users to work simultaneously on content pages without conflicts.
Emails with information that has to be entered and documented elsewhere
As an example, go back to the tasks in emails. The recipient of such an email might then try to direct things appropriately, by creating a task in the JIRA project of their team and assigning it to someone or implementing it themselves. This means double work, and is both annoying for the recipient and a waste of time.
The same is true for all kinds of content – meeting preparation, project information, ideas, reports, documentation, evaluations, etc. All of this information is generated and sent by email, and then a colleague enters it elsewhere.
Just lately I came back after a week’s absence to emails which would have almost all been better off in ‘team systems’, and I assume that someone has also documented the contents of these emails on the intranet or extranet. But that should have been the first step – the actual written communication should take place where the teams work, because email is not team-friendly.
The way it needs to be done is exactly the opposite to the way it is too often done – an employee should submit information in a central system, and then inform the parties who are intended to work together. These people then receive an automated notification, and we are back on the good side of emails. 😉
The fight against the misuse of emails has been going well on an internal level. My colleague Matthias wrote some time ago that he now only knows bad emails from his memories of them. Depending on the task area, different employees are in different stages, but we are on the right path. When working with external and customer organizations, these organizations also have good options for channeling their digital communications into centralized, automated, and transparent channels such as extranets, public JIRA instances, JIRA Service Desk, and messaging solutions such as Intercom. We continue to work on and experiment with this.
Imagine if there were no more direct personal emails, and the only emails received were notifications. If a customer wanted something, they would write it on a system. If a colleague wanted something from you, they would use tools like Confluence, JIRA, and HipChat. What do you think about this idea? Does it make you feel excited or frightened?