Personal Choices Behind Email Flood

While there is a flood of email in my inbox, what bothers me most is not the volume, but the very fact that most of the volume needlessly filled with unimportant redundant and useless message.   Reflecting on this I find an interesting parallel to a problem with public address (PA) systems in the past.

I got started on this track reading an interesting post by Vinicius da Costa titled “Nostradamus predicted there is life after your inbox!” which talks about the culture around having too many emails or meetings.  I don’t feel the need to impress anyone with the amount of messages I am involved in.  I would love to cut the number of emails off substantially, but occasionally there is a very important one, and there seems to be no way to separate these automatically.  It is as if it is my job to sort and filter through all the email, organizing the information represented there into neat categories, and store away the (latest versions) of the documents.   Every day, there arises a situation where I desperately need some of that information, and I am glad I did that work of filtering it.  I don’t like being spammed with every little comment, but at the same time I occasionally find those very same messages critical to my work.  Isn’t there a better way?

What is Driving this?

There is an mismatch between the cost/benefit trade off for the person who makes the decision.  Sending email is one of those things that can be very easy for one person to do, and can result in dozens or hundreds of people doing work as a result.  The sender of the email does not feel the pain of the work being induced on others, and the recipient does not have a choice.

I suspect that most of the people who communicate to me do not consciously intend this burden. Some have simply not thought about very much, but most are as conscientious as they can be in the situation.  Unfortunately there are four barriers that get in their way, enumerated below, but first let me relate a similar anecdote.

The Public Address Story

I joined an organization in the 90’s which had a PA system built into the building.  The receptionists were instructed to use it liberally.  Someone from outside would call in to try and reach an employee.  If that employee did not pick up, the receptionist would come back online, and ask whether the person should be paged.  A majority of the time the caller would agree, and a message would blast through the building stating that “Person XXX has a call on line YYY”.

The PA system was fairly effectively wired through the building.  Every conference room had a speaker, and they all worked well.  When the announcement went out, it interrupted any conversation that was going on.  The announcements were short, only a few seconds, but even that stopped people mid sentence, paused, and then had to pick up again after the announcement.  Many times I noticed people would start back at the beginning of the sentence.  The total disruption in worst cases was loss of  around 30 seconds of work, and we would get 4 to 8 announcements per hour.

30 seconds of disruption might not sound like a lot, but 150 people were working in the building.  Each announcement amounted to more than 1 hour of lost productivity, but nobody looked at it that way.  Such interruptions were viewed as a cost of doing business, a cost keeping people connected.

For me, the logic was clear:  interrupting 150 people, even for a few seconds was a far greater cost than the benefit of sometimes connecting one person to the caller.  Many times the person did not pick up the original call because they were not in the building, and never heard the announcement.  There was no attempt to assure that the call was urgent, so many of the announcements were about casual calls. Occasionally people were connected with important calls, but that was quite rare.

Whenever I got the offer to have the person paged, I would often reply “no thank you, that is not necessary” but the receptionist would respond “Are you sure?  It is no problem, really.”  It was difficult to refuse.  This is a classic case of a mismatch between the person who benefits and the person who is burdened.  Imagine someone calling in to ask something trivial, like what brand of salad dressing to buy for dinner, and is asked whether to page or not.

Sure, if you insist, go ahead and interrupt 150 people from their work for a few moments.  That is certainly no cost to me, and it would be nice to know what brand of salad dressing to buy.  It is worth a try (to me) even if the person I am calling is not actually there.

Motivating Change

What I found interesting was the response that I got from the average person when I tried to change the announcement policy.  The first was: “it is only a 30 second interruption, that is such a trivial bother.”  Perhaps it was innumeracy, but there seemed to be no ability to realize that when multiplied by 150 this added up to a fairly significant cost to the company.  The probability of a benefit was small.

The second argument was emotional: “when my kid is in the hospital or some other trouble, I want to be 100% sure to get that call.”   My whole point was that the vast majority of the calls were not that urgent.  Extreme examples are not a good basis for any argument.  Still,  it was impossible to persuade the typical employee that the certain cost of a 30 second interruption to 150 people is a greater than the highly unlikely benefit.  (Doubtless in a poker game these people would have lost lots of money to me.)

The annoyance was bad enough that I ended up disconnecting the speakers my team’s area.  This required careful responses when the assistant offered to send a worker to “repair” the speaker.   Needless to say, in my current office building the PA system is used only for urgent medical emergencies.

What does this have to do with Email?

When working on a document, the sender has choices:  The document could be carefully placed in a document management system, with access control so that all the right people could access it, and send a link to that.   Or one could simply blast the document as an attachment to 150 people.

When that document is received by 150 people, every one of them must decide where they want to put it save it so they can find it later.  (eDiscovery rules and IT storage limitations prevent me from just letting them pile up in the inbox like I do with gmail.)  This decision requires thinking about how to categorize the document, and then what organization scheme is in use.  It clearly would be far more efficient for the sender to do the work of deciding where to store it, in order to save 150 people from this.

It is worse when the document is updated multiple times.  Some days I receive up to 10 versions of a document by email.  While I rarely save each version off to disk, I am faced with a different problem: if I encounter a message with an attachment, it is very hard to tell if this is the latest version of that document.  If I store a particular attachment, there is a very real possibility that I am storing an older version over a newer version.  Clearly a document management system would keep the versions straight.

  • Cause 1: you have once again a classic cost/value disconnect between the effort if the sender, and the effort of the recipient. Learning to store the document in a repository is extra effort for the sender.
  • Cause 2: the “just one more” effect.   If you only send one version, it is more convenient to send as an attachment.  The benefit of a repository exists only when there are going to be many versions.  But often, then sender believes that this is going to be the last version, so setting up a repository is unnecessary and would not pay back.  Then, someone else makes “one more change” and emails it around for the same reason.  Pretty soon you have 6 versions of the document, but nobody ever imagined that there would be six versions up front, so they did not prepare for it.
  • Cause 3: Setting up access control is a pain and significant bother to maintain.  At the COCOA workshop earlier this week, a researcher reported that people often resort to email simply because they can not reliably arrange access for everyone to the system they store the document in.
  • Cause 4: the “just send me the document” request without seeing the bigger picture.  Filtering email is a burden that most view as the cost of doing business, and retrieving the document from a repository is more work than just opening an attachment.  As a result, recipients don’t even appreciate the elimination of dozens of email messages, when the one email message they get forces them to do something unusual.

Conclusion

It is unfair to say that the email senders are inconsiderate.  In fact, in one group I work with, people were being so conscientious to reply “only to the sender” that we had to train everyone to use “reply all” so we are all up to date.  How ironic, I had to request that the group spam me. Still, a majority of the email in my inbox could be eliminated.

It is not really the fault of the users, but the fact that the systems and social norms are not in place to do anything better.  The technology is easy, but changing the social norms is the real challenge.

But, I still hope to do something about that….

Advertisements
This entry was posted in Social Network and tagged , , . Bookmark the permalink.

3 Responses to Personal Choices Behind Email Flood

  1. Pingback: Tweets that mention Personal Choices Behind Email Flood | On Collaborative Planning -- Topsy.com

  2. Pingback: Culture Trumps Technology | Collaborative Planning & Social Business

  3. Pingback: Post the Document on-line before Emailing it | Collaborative Planning & Social Business

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s