How I manage my email

By -

A colleague was noting that he was wanting a better approach to manage his email so I thought I should document what I have been doing for several years now and has been (mostly) working for me.

The general concept is that I aim to have nothing in my Inbox at the end of each day. 

The approach I have been using builds on top of Getting Things Done (GTD), Inbox Zero and the Eisenhower Matrix to prioritise it.

Ideally as soon as an email arrives and I get around to looking at, I move it to an appropriate folder to action later, respond straight away, file it away in my archive folders or delete it. In reality I often end up going through what is still lingering in my Inbox at the end of the day and do this. 

I have some key folders setup:

  • 1. Action - Urgent and Important
  • 2. Action - Urgent but not Important 
  • 3. Action - Not Urgent but Important
  • 4. Action - Not Urgent and Not Important
  • Casual Reading 

These are the key folders I use for determining the priority of actioning an incoming email. Of these 1 & 2 are the key ones for me; 4 I often don't get to for a long time. Casual Reading and 4 are used a bit interchangeably and the reality is I rarely put things in those folders. Once I have dealt with emails from these folders I put them into my standard folder structure. I also keep a list of things I am working on (or plan to get to) and sometimes the contents of emails will be added there. 

I used to have a "Waiting for others to respond" folder but found I rarely used it so now days tend to keep the email sitting in the various action folders so I am regularly reminded about it and may then deprioritise it from there.

With some email clients (such as the Outlook fat client) I have found that folders can be configured to show the number of items in a folder (as opposed to the number unread). I have found this useful as a reminder that there are emails requiring an action.

It is not a perfect system but I have found that having nothing in my Inbox at the end of each day useful to have a clearer frame of mind and to not miss something that may be buried in my Inbox. 

Comments

Post a Comment

Popular posts from this blog

Considerations when responding to an RFI or RFP (a view from the receiving end)

By -
Having been on the receiving end of Request for Information (RFI) and Request for Proposal (RFP) responses, from an evaluation perspective there are ways respondents can make it easier for the evaluation panel to assess what it is being proposed and ultimately have greater success on getting through to the next round. These considerations are from my experiences with Software package selection and with Delivery partner selection, but should be applicable to many other selections. 1. First impressions count. Even before the RFI/RFP response is opened, an evaluator can be swayed by the presentation of the response and the level of engagement getting there. Key considerations: Ask questions during the response period to validate any areas lacking clarity, but don’t go overboard. Make sure you meet the response times. Use good quality paper and colour (if required to present a  paper copy). Binding can make a document look classier. If the response requests that all questions a
Read more

IT & Enterprise Architecture Conference 2015 - Day 2

By -
Today was the second and final day of the IT & Enterprise Architecture Conference 2015. Below is a summary of my key notes. Going beyond IT. What EA can really mean for your organisation John Pearson, Business Architect, IAG Consider the Demand vs Supply side of architecture IAG is using traditional TOGAF domains (Information, Application, Technology Infrastructure and Security) with business architecture being used to better align with the demand from the business Enterprise Business Motivation Model (EBMM) - Accenture, Nick Malik ( http://www.motivationmodel.com/ ) anchor diagram for business architecture using to understand change impact Bake business architecture approaches in early in the architecture journey Understand the business, its priorities and where value can be added Understand architecture capabilities in service to the business Understand key stakeholder needs and communication preferences Become involved in the strategy conversation Technol
Read more

"Site Reliability Engineering: How Google Runs Production Systems"; my key take-aways

By -
Image
" Site Reliability Engineering: How Google Runs Production Systems " edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy contains a number of insights into Google's SRE practice. It is a bit repetitive at times but this assists in drilling in some of the key points. My key take aways were: Google places a 50% cap on all aggregate "ops" work for all SREs - tickets, on-call, manual tasks, etc. The remaining 50% is to do development. If consistently less than 50% development then often some of the burden is pushed back to the development team, or staff are added to the team. An error budget is set that is one minus the availability target (e.g. a 99.99% availability target will have a 0.01% error budget). This budget cannot be overspent and assists in the balance of reliability and the pace of innovation. Cost is often a key factor in determining the proposed availability target for a service. if we were to build an operate
Read more