refactoring gtd for email [03/05/2008 00:27:47]

Here is a simplified version of David Allen's Getting Things Done Algorithm for email:

def actions(mailbox):
    result = list()
    for email in mailbox:
        next = nextAction(email)
        if next.estimate <= TWO_MINUTE:
           do(next)
        else:
           result.append(next)
    return result

for item in actions(MY_MAILBOX):
    do(item)

This is python code and it does something that I have come to believe is bad coding style in python: it appends data to a list.

There's nothing particularly wrong with list.append(), but for many programming tasks, your code becomes a lot more useful if you use a generator:

def actions(mailbox):
    for email in mailbox:
        next = nextAction(email)
        if next.estimate <= TWO_MINUTE:
           do(next)
        else:
           yield next

for item in actions(MY_MAILBOX):
    do(item)

This doesn't look like much of a change, but the two programs are completely different.

In the first version, all the TWO_MINUTE or less actions are performed up front, and then the larger actions are performed in a second sweep through the generated list.

In the second version, each item is handled exactly once, and done immediately after the next action is determined. In fact, the code can be further simplified to this:

for email in MY_MAILBOX:
    next = nextAction(email)
    do(next)

Or even simpler:

[do(nextAction(email) for email in MY_MAILBOX]

Python handles these last three versions a bit differently, but they all process the mailbox by selecting the next action and then doing it immediately.

I would assert that this is much better python than the original, but more importantly, I believe this algorithm is actually more productive in real life for answering real email.

There are several reasons for this:

First, no value is delivered to the customer until an email is actually answered. This is just basic Lean Thinking. In theory, passing through the mailbox up front and recording the next actions should maximize throughput: all the two-minute tasks are delivered immediately, and then you've already thought through the other tasks so you know which of those you can deliver quickly.

Unfortunately, there is a disconnect between the email box and the next action list. There are all sorts of reasons that this disconnect happens:

• a single issue is often broken up across multiple emails, mixed in with other emails about separate issues from the same customer
• a single email may require multiple independent actions before it can be answered
• in general, email clients do not allow you to arbitrarily re-arrange emails in a list or outline, so there is little tool support for grouping emails by issue - usually, the best you can do is sort by sender
• in general, email clients do not offer the ability to annotate email, so the action list has to be maintained in a separate system

The disconnect between the next action list and the email client creates a tremendous amount of waste. Everything I've tried requires a tremendous amount of cutting and pasting and cross referencing. I've personally spent quite a bit of time implementing my own email client to address these issues. Perhaps someday I or someone else will create a tool that successfully eliminates this disconnect, but in the meantime, it's a lot of wasted time and effort.

In my particular case, the wasted effort creates a cognitive burden that can dramatically slow down response time. Maybe I'm just an edge case. I have hundreds of clients with varying levels of technical knowledge, all attempting to do different things. When I try to track it all on a next actions list, I get overwhelmed and distracted, and by the time I'm halfway through, even more emails have come in, and hardly any have gone out. For me, in my business, applying the GTD algorithm to email slows things down even further, time and time again.

With the generator approach, things move much more quickly. The effort of tracking next actions is (mostly) eliminated, because I only have to define the next actions for the email directly in front of me.

With only one email to track, it's much easier to generate a complete step-by-step plan for how to answer the email (rather than just thinking through the first step). These plans can be reused to speed up future responses, used to train employees, or refined over time into automated solutions. These small plans can then be implemented and refined immediately.

But what happens if the oldest email in the stack requires hours of work? Won't that hold up the rest of the queue? Well, yeah. So the appropriate response is to answer the email, create an issue in a proper tracking system, along with a note to follow up later with the customer.

The above concept is similar in spirit to what the next action list is really supposed to be about. Allen's point is to get all your work into one tracking system for everything. I guess my point is that since email and actions don't have a one-to-one correspondence, it makes sense to get things out of email as quickly as possible and either deal with them immediately or move them into a real GTD-friendly tracker.

---

Endnote: You could get a similar effect in the original algorithm by increasing the two minute cutoff to a much higher value. It amounts to the same thing: answer as much email as possible immediately. Track everything else in one system outside of email.