Tools & Technologies

Unresolved Issues in Email: It Creates Unnecessary Communication, Feb 27

Now that my professional life is coalescing around a new rhythm of thinking, writing and engaging, I want to pick up again the thread I began in January on the Unresolved Issues in Email. The first two pieces in this line of argument are:
1. Unresolved Issues with Email: Confusion in Conversation Flow (January 25, 2007)
2. Unresolved Issues with Email: Confusion in Conversation Context (January 31, 2007)

In this piece, I want to consider how email creates unnecessary communication in project teams. I’m looking forward to hearing about your experiences with this.

Email Creates Unnecessary Communication
Whenever we work on a project with others, a lot of the communication has to take place over some digital channel. It’s just not possible for all of us to be in the same room at the same time all of the time that we’re working with others. So in a real sense all of us work in “virtual teams” now … that is teams that are enabled by communications technology to cross boundaries of time, space and organization. One of the problems in the way we use email is that it creates unnecessary communication missives that all have apparent equal importance when viewed in an individual’s inbox.

If we were in a face-to-face (very traditional team model) environment and I was expecting something from you, I’d amble over to your desk and ask “how’s it going with your document?”. You’d answer, and get back to work. In an email-facilitated environment, I send you a message to request an update. Now let’s think through the difference: the in-person interaction is epheremal … that is it doesn’t create a piece of written communication like email does. It’s immediately given and immediately responded to … unlike email where it can hang around for days if one of us doesn’t respond quickly. And it is clearly of a different nature to other interactions … but in email it looks and feels exactly the same as everything else. And finally, it is clearly positioned and put in context of a current project that you’re working on when stated face-to-face … but in an email inbox it stands alone and has to be associated to a current project by intentional cognitive effort on your part. I’ve previously written about the poor contextualization of email messages within a project, but in this piece let’s look at how unnecessary communication is created in email-intensive environments.

Matthew and Sally Trade Email for a Document
Matthew and Sally are two of the members on a project team at their organization. Everyone on the project team has embraced a common project outcome, and various tasks and activities have been distributed among the members on the team. They are, however, using email to facilitate interaction. Let’s look at how Matthew and Sally use email to get their work done.

Matthew, Tuesday @5.18pm … Sally, hi. I’m working on my next deliverable for our project, and need the latest version of your document pls. Is it good to go, and if so, can you please send it to me? Thanks much, M.

Sally, Wednesday @8.32am … Matthew, here it is. There are still some areas to fix up and some finishing touches to apply, but the essence of the document won’t change. Please advise if you have any questions. All the best, Sally.

Matthew, Wednesday @9.14am … Sally, this is great. Thanks much. M.

Now let’s examine this interaction over email. First of all, if the project team had been using a project workspace, none of this interaction would have been required for Matthew to get the document. He would merely have gone to the project workspace, looked for Sally’s document, and opened it up. Two messages in Sally’s inbox and one in Matthew’s inbox would thus have been entirely eliminated.

Secondly, message three in the above thread adds nothing from a content perspective but is very helpful from a relational one. Matthew contributes nothing to the content of the document; what he’s giving is a relational affirmation to Sally for her work. Within email the only way to do this is through the sending of another message that shows in Sally’s inbox … he has no other way of doing it. Thus Sally must process his email just as she would any other message. There’s no differentiation for Sally between messages of content value and messages of relational value. In a project workspace, Matthew could have left his relational affirmation through a comment on the document for Sally to see the next time she happened to come by.

Thirdly, Matthew has to wait until the next business day to get on with his deliverable because Sally has either left for the day when he sends his message or alternatively just doesn’t get to his message before leaving. True, it is nearing the end of Matthew’s business day when he sends the message, but regardless, perhaps he only needs to get a couple of facts and figures from Sally’s document for him to be able to finish up what he’s working on. If the document was stored in the project workspace, he could get the information he needed immediately and continue on in the flow of his thoughts and productive focus on his current work, rather than having to come back the next day and try to re-create that flow and focus.

Finally, because Sally has something that Matthew needs to get his work done, she’s elevated into a position of power that she can use in good or bad ways. In this case, she’s apparently chosen to respond in a good way … the document is sent through fairly quickly along with an explanatory note as to its drafting status (ie, effective human practice). However, there’s no end to the number of ways she could use Matthew’s request in a power play: she could ignore Matthew’s email for a couple of days, she could send the wrong document and then follow up a day or two later with the correct version after he’s already submitted his document, she could say (wrongly) that the document isn’t yet available, and so on. If she chose option one of the power play approaches, we’d probably have an email thread like this:

Matthew, Tuesday @5.18pm … Sally, hi. I’m working on my next deliverable for our project, and need the latest version of your document pls. Is it good to go, and if so, can you please send it to me? Thanks much, M.

Matthew, Wednesday @4.00pm … Sally, did you get my message yesterday about the latest edition of your document? I really need it ASAP. Pls advise if it is available yet. Thanks, M.

Matthew, Thursday @8.53am … Sally, I’m getting desparate for your document. Is it available? Please reply ASAP. M.

Sally, Thursday @11.27am … Matthew, here it is. There are still some areas to fix up and some finishing touches to apply, but the essence of the document won’t change. Please advise if you have any questions. All the best, Sally.

Matthew, Thursday @11.29am … Thanks Sally.

What’s Matthew to think throughout this email exchange (where messages 2 and 3 are entirely unnecessary and message 5 is now very blunt)? Does he attribute good intentions or bad intentions to Sally’s silence? If challenged face-to-face, she could undoubtedly come up with a reasonably sounding explanation about having to get the document finished before sending it off, and she was indeed complying with Matthew’s request to get the document “ASAP” … it’s just that her definition of “ASAP” was that the document had to be finished first whereas Matthew just wanted whatever was done at the moment. Does Matthew have grounds to escalate Sally’s lack of responsiveness to a joint manager? And if he does, he runs the risk that the manager will view the complaint as an indication that Matthew is somehow at fault. More likely in this case, he suffers the frustration of poor communication on his own, leading to elevated blood pressure and stress.

Cover Your Backside with CC: and BCC:
Whether communication is necessary or not is only truly judged within the eyes of the receiver. If I’m telling you something that you already know, I’m not adding any content value to you. You may choose to suffer through hearing my latest and greatest thinking for the benefit of relational value, but in terms of the content … nah, you’re getting nothing out of this communication. Thus when you or I receive email messages via the CC: (carbon copy) or BCC: (blind carbon copy) lines, the value thereof is often minimal … and we’re often only receiving it because the sender wants to cover themselves in the case of a blow-up. Either we already know what’s being said, or we’re being dragged into a conversation that we’d rather someone else handled as part of their job responsibilities.

In a project situation, one team member CC:s or BCC:s everyone else on the project team on all of their communications to keep everyone “in the loop”. However, with all of the responsibilities others have, getting every piece of minutiae is more likely to drive them loopy than make them feel “in the loop”. Perhaps a better way to do this via email is to send a summary of the communication after the fact to those who have less of a direct interest in what’s being discussed, and to offer your availability if they want more detail or have questions. Alternatively, embrace a different way of communicating that gives others the option of when and where they want to be involved.

What’s the Perfect Technology Situation?
What would be ideal? We could do things smarter in email: how about some way of requesting updates on projects that doesn’t result in the generation of a separate, non-contextualized piece of communication. How about a feedback button, or a “Request Update” button on an original email … so that the sender can click it, type in their feedback or request, and then in the user’s inbox the message shows with a dancing icon of some description. When the person hovers over the message, they get a pop-up that displays the text of the request from the original sender, and they can respond there and then in the context of the update request. It’s like adding a series of speech bubbles to messages in the inbox.

Alternatively, we could embrace a different communication channel to facilitate the interactions and collaborations of the team, eg, a project workspace or even a simple wiki. Conversations, documents and more would be mediated through the workspace or wiki rather than email, and in conjunction with a team agreement on how to use the workspace or wiki effectively for the project, we could reduce much of the email volume. For example, when the MWW Group adopted a wiki for project coordination, it reported a reduction in email traffic of 30%. Although I have some questions about the true efficacy of that number, it’s a good indication of what’s possible.

What’s Your Take?
Do you have examples from your work where email has created unnecessary communications? I’d love to hear about. Equally, if you have examples of where and how teams you are involved with have shifted beyond email and the effects of that, I’d love to hear about it.

Categories: Tools & Technologies