How Software Engineers can reduce their Email Volume

email-overloaded-software-engineersAs a software engineer we receive a ton of emails.  It’s a plain hard truth.  In this post I want to share several smart ways (other than just filters) to lower the amount of e-mail you receive.  In short I want to help you reduce the volume of emails you receive rather than simply managing the volume of e-mail you receive.

First let’s look at the type of e-mails you may receive.  Some engineers may receive a lot more than others.  Keep in mind that these are generalized “types”.

  • Direct communication (1 to 1 conversations with other co-workers on a problem)
  • Group discussion threads (several people across the company discussing a problem or task)
  • Company status threads (news announcements, industry happenings, etc…)
  • Direct Team threads (scrum reports, deadline reminders, project announcements, etc…)
  • Partner Team threads (qa regression reports, cs customer feedback reports, etc…)
  • Product Release threads (release announcements from teams when new code is pushed to production)
  • Operations Alerts (notifications from operation tools such as Nagios alerting to a bad server or a bad metric)
  • Customer queries (feedback or help requests from customers)
  • Industry newsletters (maybe we signed up for them – maybe they are spam)
  • SOX compliance (communication from events happening around the company)
  • Bug Tracking Software (bug updates, assignments, conversation, etc…)
  • Build System Notices (Hudson/Jenkins/etc style communications, reports, failures, etc…)
  • Calendar software (meeting requests, reminders, etc…)
  • Code commit announcements (commit results, code diffs, etc…)

Wow – that’s a ton… and there are a lot more out there I am sure.

There are days when I will receive literally over ~400 emails a day.  I have gone on vacation and came back to over 3K+ emails sitting in my inbox for me.  I was tempted to use a “delete all” command.  In retrospect I probably should have.

The key to managing these e-mails is to understand what kind of action they require.  We will then place these e-mails into various buckets depending on the required actions.

  • Informational Only E-Mails : These are emails that are purely for my information only.  No response or feedback is required.
  • In-Direct Action E-Mails : These are generally emails that are sent to groups and you may be CC’d on them in case you wanted to weigh in.
  • Direct Action E-Mails : These are projects or items you are directly working on and need to be an active participant on.

I would be willing to bet that if you were to classify your email into those three groups you might get a disbursement ratio along the following line:

  • Informational Only E-Mails : ~60% of your e-mails
  • In-Direct Action E-Mails : ~25% of your e-mails
  • Direct Action E-Mails : ~15% of your e-mails

Let’s dive deep into the “Informational Only” e-mails.  These are the most dangerous.  They waste the most of your time and provide you with the least amount of benefit.  (Bad ROI).

Keep in mind that I am not saying that you should stop paying attention to these e-mails.  Rather I am saying that they should be handled differently.  Using filters in Outlook and Gmail is an ok solution — but I believe that this is just a mask that doesn’t actually solve the problem.

The purpose of these e-mails is to convey information.  Have you ever questioned why they need to be an e-mail?  Why not some other medium?  If you were to question this you will probably get an answer along the lines of “ease” or “convenience” for the sender.  What they ignore is the pain it causes for the recipients who now need to process and handle them.

Let’s look at several different types of e-mails:

  • Bug Tracking Software
  • Product Release Threads
  • Build Server Notifications
  • Partner Team Threads
  • Code Commit Announcements

SOLUTION 1 : Feed System

These examples are all items that in my opinion should live within a feed style communication system and not an e-mail distribution list.  Instead of sending an e-mail of the announcement or report, let’s put the information into an RSS or feed system.  This allows people to read the feeds at any time and from more locations.

To help illustrate this better let’s look at the code commit announcement emails.  Many SCM (source code management) tools have this already built in.  There is a feed that illustrates what the most recent check-ins were.  You can view diffs and so forth.

Let’s look at another example, one that doesn’t have the feed functionality built in.  Product Release threads generally are created by a Product Manager or Producer and include details of what was just released.  If this information is placed into a feed system the information is easily archived and available for browsing at a later date.  Once in the feed system the data is available for searching and filtering tools to find data relating to a particular item and or / date.

An RSS or Feed style system can easily be implemented with little to no effort – often for free.  Heck you could even make it be a WordPress blog site.  The point is to get it into a Feed system so that you get the benefits of that system.

Search, subscription preferences, filtering, archiving and flexibility in reading are all basic benefits of having this information in a feed system instead of an e-mail.

Once your communication is in the system, users can then take advantage of the system properties.  For example, some people may prefer to visit the site once a day and read all of the latest threads at once.  Some people may prefer to subscribe to the RSS feed and read it locally on their computer or smartphone via an aggregator.  Others may prefer to subscribe to a daily digest that e-mails them the summaries of the posts.  Others still may prefer to subscribe to every post and be alerted every time.  The point is that instead of blasting everyone with an e-mail and forcing a single email approach, you are now providing your users / co-workers with more options to receive their information.

SOLUTION 2 : Dedicated Distribution Lists

Now, you may be in an organization where you just simply can’t move people to adopt a feed style communication system.  Ok, whatever… we can move on from that.  Another idea is to help these teams and systems adopt dedicated distribution lists.

Again, let’s use the code commit announcement emails.  Odds are that you have a process in place to email your dev team every time someone makes a code commit in say SVN or GIT.  This can be very useful in many circumstances.  The problem is that not every single dev on the team may require this.  Or even if a dev should read it — they just simply might not do it.  You can’t force them to.

In this scenario you should have a dedicated announcement e-mail distribution list.  Then users can subscribe on a case by case basis to the dedicated distribution list.  Those that don’t want the communication don’t have to receive it.  This approach has worked really well for code commit emails, product releases and more.

There are a couple of specific things that I would do to this distribution list.

  1. I would adopt an “-announce@” to each of the addresses.  So instead of gitcommits@company.com I would use “gitcommits-announce@company.com”.  This creates a pattern that is easily understood by subscribers.  When users subscribe to the list they know that it is an informational style e-mail and so forth.

  2. I would make the list a “no-reply” distribution list.  Meaning that if someone replies to it, the reply will bounce back to them.  You can even get smart in the bounce back message and provide hints at the email addresses that the user may consider sending their reply to.  The reason for this is your subscribers may accidently start threads that should not be on the list.  There may be subscribers that don’t benefit from the thread – a lot of subscribers.  If it happens frequently it defeats the purpose of the list being an announcement style list.  Another reason is it forces the senders to rethink what they are sending and keep it more in tune with the lists designed purpose.

  3. Lock down who can send to the list.  This prevents a co-worker from accidently thinking that the list is for something different.  For example they may email the list thinking that it is a support or team based distribution list.

Conclusion

We could spend a lot more time diving into more details on managing e-mail, but this post has gotten long enough as is.  Hopefully I have provided some good ideas for what could work within your organization.  Sad to say that no solution works in every scenario.  Once solution may work great in one place and fail in another.

The key I think is to identify what emails are your informational e-mails.  Emails that do not require action and are for information only.  Then I would encourage you to take them out of standard e-mails and approach the information in a different manner.  Reduce the volume of email instead of managing the volume of email.

Let me know your thoughts – what percent of your e-mail is “Informational E-mail” vs actionable e-mail.

Comments

comments

Posted in , and tagged , .