Apr
21
2008
There’s a flurry of articles today about email overload, and I read a few prompted by a tweet from ChiefTech. I fancied a break so I thought I would jot down my strategies for dealing with Email, which right now mean I DON’T suffer from Email overload.
Setting the scene:
- First off, I don’t find Email to be the root problem, instead I lay the blame more on email clients. I find that the RSS post scanning, reading, flagging, sharing, and actioning experience in FeedDemon to be far superior to the equivalent in Lotus Notes.
- If anything I find I suffer much more from RSS overload than Email overload, but RSS readers are designed from the get go to help people cope
Getting back to email:
- I scan read every email that arrives each day
- By the end of the day I always trim my inbox to about 15 emails, these are all emails that require an action, essentially these 15 emails are my to do list for the next day or so. 15 emails fit on my laptop screen with the preview pane open, so I can scan them all with a single glance to choose my next action
- I email myself to do items, often from my Blackberry so I have only one place for to do items. If I have more than 15 to do items I know from experience that I will never get around to them, so I tend to be pretty ruthless. I keep a list of future projects that I’m not currently actioning separately
- I colour code emails from key people and key customers so I can see at a glance things that need special attention
- I create rules which move large volume email into folders so that they don’t clutter the inbox, and can be easily scanned and block deleted. These tend to be subscriptions to lists or automated notifications. I sometimes prefer this to RSS feeds, depending on the follow on action required.
- I redirect emails to RSS where I can, however for RSS feeds that must be read or that have a high importance, but low traffic I prefer to get the update as an email
- For anything I need to read while mobile, I like it as email on my Blackberry
- I don’t use many folders. Most emails get filed under admin, long term file, short term file and projects. For projects with high levels of email I sometimes create a folder, but it’s rare that I access it.
- I almost always find emails by going into “all documents” and sorting by the name of the person who emailed me, or who I emailed. My Brain works better by associating with people than projects.
- I often turn emails into calendar items, but almost never into to do items
- I do most of my email processing, deleting, filing, forwarding etc on my Blackberry.
- Once I have replied to or forwarded an email, I delete it. I find it much easier to find it again in my sent folder, which I keep a full archive of.
Dec
11
2007
This article has a good comment thread on this topic. In my case I don’t really have an option I work offline too often and when I’m online I only have a GPRS connection so its desktop email and Blackberry email for me.
Nov
19
2007
It seems that everyone now days wants to eliminate the poor old email attachment, and yet people still cling to this tried and trusted way of passing around files. For example Adam recently posted:
Several people we’re not happy that in Notes 8.0, the ability to instantly email an attachment from the new document, presentation, and spreadsheet tools was missing. We’ve listened, and in the upcoming release of Notes 8.0.1 there is a new “Send To” toolbar
But although IBM has listened Adam closes by saying:
Now of course you should not be emailing around attachments anyway, you should be storing files in Quickr!
I’m still a fan of attachments even though I have four choices for sharing files within the enterprise:
- I can publish to a web portal (hardly ever use this, way too inefficient)
- I can publish in a Notes database (use this for frequently changing documents, because I can update offline and synch in the background)
- I can post on a blog or wiki (less efficient than Notes database, no offline publishing, slow to publish, but has comments)
and I find that I still use email a lot, mainly for the following situations:
- I email attachments when I know the recipient wants to take a document and extract some parts of it or evolve it for a new purpose. It’s much easier for them to receive the notification and the attachment at the same time and I’m not interested in them updating my original. I also like that I can provide comments and context in the email
- I email attachments when I want to create a one time access control list for a document, although I know (because we don’t use rights management in CSC) that people can send the attachment to others easily enough
- I email attachments when I want comments on a document, rather than changes to the original. This is a very common situation for me, I rarely want people to edit my original it’s comments I want, and the best way to get comments from busy people who travel a lot is email because it provides asynchronous delivery of the email and the attachment, integrates well with most peoples task management, provides both the context and the document in one place, makes responding easy.
- I email attachments when I’m working across enterprise boundaries. Expecting employees of other companies to remember user names and password for my systems and how to navigate them is just too much
- I email attachments to very busy people, regardless of the scenario, because I want to optimise their time not mine (or the IT resource costs) and the receive email, wait till they are online, click link, login, download document, open document workflow is way too inefficient
- I email attachments when I want to send slightly different versions or subsets of a document to different people, which happens quite often.
I avoid using attachments when:
- Documents are changing frequently and I want people to use the latest version
- I am doing a communication to a large number of people many of whom I don’t expect to ever take a look at the document
I avoid using documents at all (I use a wiki, blog, discussion database etc):
- When I want a small number of people to work collaboratively on the content of a document
- Gather information from many people especially where people will benefit from seeing other peoples information
- Encourage comments ad comments on comments