In The Toolbox – Taming the Inbox


One of the things you get to deal with in “The Enterprise” is how to manage the ton of email you get every day. For some reason corporate culture loves it. And I hold my hand up too as being one of those people who has probably overused it. Your inbox is bombarded every day by emails from various sources, such as the company’s latest results or PR exercise, support notifications to keep you “in the loop”, location aware messages to find the owner of the dropped mobile phone, meeting invites, etc.


What I find confusing is the number of people who deal with this by burying their head in the sand, i.e. they just leave everything in their inbox and make no attempt to configure their email client to relieve (some) of the burden. When you do send them an email they seem surprised when you follow up in person and they say “sorry, I didn’t see that message”. In many cases these are developers who would never dream of sticking all their source files in a single source folder, and yet the same rules to manage complexity in software don’t seem to apply to email.


In one sense I envy their attitude towards email - I wish I could be so blasé about the whole affair and just grumble about how much it interrupts my day and is just another distraction from writing code. But the thing is, it isn’t and hasn’t been for a long time as I’ve learnt to manage it, just as I’ve learnt to manage the complexity of the code I work on. What follows below are the practices I’ve developed to manage my email load. Of course one size never fits all, but you may either find some solace in my habits or confirm my position as a slave to an anachronism.

Message Status

Given the environments I work in Microsoft Outlook is the email client of choice and it has one of the worst default settings I’ve ever come across: “mark item as read when selection changes”. This means that every time you click (or cursor up/down) to another message in your inbox the previous one will be marked as read – irrespective of whether you actually read it or not. Given that your focus is on the target email, not the ones along your journey, you probably won’t even notice the change in status of the ones you accidentally clicked on. If you are going to leave everything in your inbox, the read/unread status is probably the only way you’re going to know what you have and have not attended to, so you owe it to yourself to switch this off. I don’t leave emails in my inbox but I still turn it off as the “read status” is one of my indicators for what I’ve yet to attend to.


Our esteemed C Vu editor informs me that this is also the default setting on a number of other email clients. If anyone can enlighten me to why this is the choice of the masses please send a postcard to the usual address, i.e. accu-general.

Filtering Messages

My primary filter for what order to look at emails is not whether it’s been read or not, but which folder it’s in. After turning off the setting above I start to consider how I need to filter any incoming email so that stuff that is likely to demand my attention stays in the inbox (i.e. my highest priority mailbox) whilst the less exciting emails end up in some other folder. In either case it remains in an unread state as even the lowest priority of emails may have some redeeming content unless I know for sure I will have no false positives with a rule (e.g. I can match on an email address from an automated account).


As a general rule anything not addressed directly to me, or directly to my team’s email distribution list(s) goes into the bin (the Deleted Items folder in Outlook). So much email comes through on so many email lists that aggregate various other lists ad infinitum that it would be a chore to continue maintaining the default rule by adding each new corporate spam list as it shows up. Hence I prefer a white-list to a black-list, where the white-list is me and my team mates.


That simple rule often suffices for many organisations, but it depends on how entrenched you are in the company, or whether you have a support role as well. Support is often done through an email list that I may or may not be interested in depending on the support rota. As such I may create a custom folder, perhaps under the Inbox, for mail addressed to the support account.


I have known an organisation get wise to this “tactic” of filtering internal spam by using read receipts to monitor consumption. They then started addressing mail to everyone directly (or perhaps it was just me because they knew I was not only binning it, but marking it as read automatically too). For these occasions the other filtering rules can usually be effective, such as matching a text string like “Monthly Update from the CEO”. Hopefully by now we’ve reduced the burden so much that the odd false negative is not too onerous to deal with manually.

When to Read

I know many people find email a huge distraction and dislike being interrupted when in a state of “flow”. Personally it’s been so long since I’ve ever achieved a state of flow I’m not sure what it looks like. A large part of that is probably down to having 4 children - their constant need for attention means I’ve developed the ability to context switch at will. Whether I’m anywhere near as effective being this way is likely open to debate, but it does mean I can attend to trivial emails without really pausing for thought.


The little envelope that Outlook displays in the notification tray can either be a useful little reminder to catch up on your mail or a horrible nag depending on how distracting you find tray icons. Toast-style notifications at least answer the question that the little icon only teases at – who’s it from and could it be worth reading now? However their effectiveness even for someone like me depends on them being the exception rather than the norm. In an email heavy environment all these indicators, along with playing a sound when a new message arrives, can seem like you’re at a fireworks display.


One problem with being elevated from last-through-the-door to longest-serving-member means that you acquire an awful lot of knowledge and experience that others (unfortunately) start to rely on. Even if I’m not the only one that knows the answer, if I feel someone is blocked in their work and I have the ability to reply quickly and that would unblock them, then I feel the team wins. However this kind of helpfulness does nothing to improve your own productivity and can lead to awkward questions if your company measures value in lines of code.


As such my emails are dealt with in one of two ways. If the email is relatively short and can be answered within a couple of minutes I’ll just do it there and then. Rather than handle a single email, naturally I’ll handle all the quick ones in succession. Of course because I do it that way my inbox never accumulates and so it mostly stays empty. Any that are too long to read or reply to immediately stay marked as unread so that I know I still need to look at them properly later.


That generally leaves the longer emails addressed to me and any others that were filtered automatically into the lower priority folders. These I can tackle at a time when a natural break occurs, such as running the clean + build + tests after integration and before checking in, or after one story is finished and I’m ready to pick up the next, or before resuming a story after having coffee/lunch, etc. This kind of email tends to be pretty rare these days as it can often be converted to a formal project task if the answer would be better served as a wiki page, or by teeing up a face-to-face chat to explore a problem directly (high-bandwidth communication).


If I’m on support then the priorities change so that I scan the support folder first and will probably interrupt my flow to handle a potentially lengthy support email as that is usually far more important.


Finally that just leaves the stuff that goes straight in the bin, but still marked unread, which I’m pretty sure is just junk. Most of the time I won’t even go passed the subject line and will either block select and mark as read or use the folder option “mark all items read” for ease. Very occasionally something interesting gets filtered by mistake and so I might dealt with it then or move it back to my inbox to peruse later.


You might have noticed I’ve not mentioned the message priority anywhere. That’s because I completely ignore it. Putting the word “URGENT” in the subject line in capital letters does not make me feel the need to respond any quicker either. The priority flag is usually just an indication of their work priorities, not mine.

Message Archives

Back when disk space was measured in MB it was not possible to keep every email sent, especially when they contained attachments. These days it’s entirely possible to never delete anything ever again. The problem now is searching a vast email archive for the answer to that question you’ve just been asked… once again.


Rather than leave all my mail in the Inbox or “soft-deleting” by moving it to the Deleted Items folder I developed a habit of creating a top-level archive folder with a set of suitably named sub-folders used to group emails into more manageable chunks. For example on my current project, which I’ve only been in for a few weeks, I already have the following folders: Build, Design, Infrastructure, Releases, Security and Tools. In essence I group emails just like I group code into namespaces.


Once I joined the corporate circle I found this technique to be very valuable. It has proved to be a good defence mechanism to remind both team insiders and outsiders about a prior conversation when amnesia appears to have set in. One manager I worked for asked the same question time-and-again and so I used to dig out the last copy of the email I forwarded him and prefixed it once more with “Here it is, again”. This kind of passive-aggressive behaviour changed nothing of their behaviour but at least I got to chuckle as the email grew longer and longer with each new occurrence.


Earlier I mentioned that I can often answer an email very quickly and this easily searchable archive is one reason why that becomes possible. Even with years of accumulated emails it becomes relatively easy to find stuff. Naturally the tool’s search feature is a good start, and narrowing to just one folder speeds things up immensely. Sometimes though I can’t remember a distinct enough term to search on and so a manual search is required. This might seem like the proverbial “needle in a haystack” but with a good folder structure you’ll be surprised how quickly you can hone in on something just by flicking down the subject lines.


So, what do I archive? I keep every non-trivial, team-relevant conversation that passes by my inbox. Although in some cases I have kept even the replies that just say “thanks” as proof that the email must have been read by the recipient (in case they plead ignorance). That might seem like a lot of mail but once you have a good archive structure it only takes moments to read it and file it away. In the past I tried to keep only the most recent message in any conversation but I found that became more of a burden and if the thread diverged it became hard to know which to keep.


One other reason for not just leaving everything in the bin or the inbox (if you want a record kept somewhere) is that some companies have a policy of deleting mail older than, say, 3 months in either of these two folders. Ironically, rather than attempt to reduce its dependency on the tool they prefer to recycle the storage more quickly.


Occasionally one archive topic’s folder might get too general and so I then split it or create subfolders. I leave the existing pile in place and then start afresh which creates a sort of multi-level cache when searching. However these days I’ve done it so many times that I generally adopt the same structure each time and have a feel for what sort of breakdown is likely to work.


My original goal for all this hoarding was to allow me to dump the entire contents of my mailbox into a .pst file on some file share when I left so that any knowledge acquired was still accessible to others after my departure. While I have done this on later contracts I didn’t in the early days because I was fearful that an email with a sensitive conversation in it might leak out. Consequently my desire to be able to just dump my mailbox on exit has helped keep me a little more honest too.

Handling Request Timeouts

Most replies will either be part of an ongoing conversation, in which case the original email can be archived, or will involve me firing off a request to which I will eventually expect a reply. I like to manage my Sent Items folder in a manner similar to my inbox (it is a mirror image after all) so I archive sent emails too alongside the ones received.


I used to use a special archive folder called “_pending” (the leading underscore sorts the mailbox at the top) to act as a reminder of how far the conversation has gone. However I eventually realised that by emptying the Sent Items folder in the same way as my Inbox I could leave pending items in there instead.

Treat the Disease

By now I suspect many of you are screaming at this article telling me to treat the disease, not the symptoms. And you would be right. In some cases the burden of team communication by email has lessened over the years as common uses have been replaced by the daily stand-up, pair programming, code reviews, IRC style chat [1], wikis, feature trackers, etc. Convincing your own team to make better use of face-to-face communication or other tools is usually within your own control.


The question is how to convince those outside your control that you don’t want the deluge of spam directed at you. Where’s the link at the bottom of the weekly timesheet reminder that allows me to unsubscribe? Perhaps corporate email software will one day evolve to a point where all email lists become opt-in, not impossible to opt-out of. Until that day comes I’ll continue to opt-out where possible using automatic filtering rules and opt-in for stuff that actually has some value for me and my team.


[1] In The Toolbox – Team Chat, C Vu 25-2, August 2013


Chris Oldwood

02 October 2014



Chris is a freelance developer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros; these days it’s C++ and C#. He also commentates on the Godmanchester duck race and can be contacted via or @chrisoldwood.