I suspect that it’s September because I notice that a number of people on my blog roll have been posting about Getting Things Done; a fun little book.
Getting Things Done, or GTD as it’s sometimes referred to, is one of a class of business self help books. Boots designed to sell the consulting services (and related paraphernalia) of it’s author. Selling is easier if you understanding the demand your filling. For GTD the demand it not “I need to get things done!” it’s “I’m suspect I’m not getting the right things done. My life is out of control. The stress is driving me crazy. Excuse me while I scream. Damn that didn’t help either.” People are, of course, interested in getting things done; but they are far more interested in getting control over their anxieties.
The GTD solution to the anxiety problem is Zen like. Empty mind = low stress. This isn’t a bad plan, but it is a very good target market!
The GTD means to that end is to move the the pile of anxiety producing stuff out of your noodle and into his system. Clever, he just happens to have the tools for that for sale.
I love his system, because it reminds me of the design of software I’ve written; in particular a real time control system’s master scheduling module. I enjoy mapping all the elements in his system to the elements in such software systems.
For example he has an interrupt queue. New information is queued up; he calls that the inbox. With reasonable regularity our automaton comes around and drains the interrupt queue. In a software context interrupt processing is very high priority, which means it locks out all kinds of other presumably useful work. To avoid the risk inherent in that lock-out you make a rule that time limits the interrupt queue processing. N units of time per item say.
In the GTD system you shuttle them off into other data structures: the trash, the do soon list, the someday maybe list, etc. etc. Limiting the time/resources devoted to the input queue is a big help in staying sane. Presumably once things move into the other piles they will get dealt with more rationally than they can at interrupt.
There are behavioral reasons why a human is not well suited to this plan. The input queue is the source of positive and negative reenforcement. For that reason we tend to pay it close attention. Each time the mail drops thru the slot it creates the a bit of fisson. A letter from a long lost love? A card from the IRS? One reason we all hate spam with such a passion is that it abuses and degrades all this. Oh joy! A credit card offer!
It took me a while to turn this model around and realize that my correspondents all have similar N-second processing rules on their input queues. If I wanted to affect their behavior I had to fit my inputs inside that envelope. Some correspondents can only handle a one sentence email; others can swallow an whole paragraph!
I notice that some of my acquaintances have compiled this insight so deeply into their behavior that they tend to only generate very very short missives.
One of the ways I remain confident that my blog is for my pleasure and not customized to the pleasure of my readers is how I totally ignore this insight when writing it.
There is a risk with the GTD system. While it is a very good idea to move the anxiety producing stuff out of one’s head, sadly this just results in creating anxiety around the maintenance of the piles. People adopt the system with great optimism. Later they discover that the meta-work of keeping it up and running, well, isn’t something they actually do. In software systems I’ve seen failures of like that were the master scheduling loop fails because it doesn’t actually get any cycles, but then I’ve also seen cases where it fails because it gets most of the cycles. One of the ways that GTD fails is pile management: too many piles, too much anxiety about the piles or too little.
My current manifestation of GTD is a private Wiki. I have a half dozen input queues (email, phone, a wiki page, a physical inbox, etc.) and I try to shift things out of them and into the Wiki. Wiki pages become the piles. I then try to at least occasionally review the higher priority piles.
Another place where I see strong analogies between the GTD and software is in the object oriented elements. In software we have processes and in his system there are projects. He has physical folders that capture the supporting materials for that project; I have a page in the Wiki and sometimes I also have a physical folder. Piles, folders, etc – all in my wiki.
This is another place where the GTD system breaks down for people. It’s very hard to figure out how granular things should be. For example I have a page for my glasses and an associated folder with my prescription in it. Is that too fine? Probably not, because at least I haven’t lost the damn prescription. But then should I have a folder for that 12% off coupon from Staples or should it go in the folder of all coupons – or possibly coupons are just too much anxiety.
I tend to create objects in my system for things and for relationships. This is another lesson I learned from software – i.e. that the most critical data structures are often the links between objects and not the objects themselves. So for example there is one for entry for the car, and one for each of the credit card relationships, etc. It’s hard to think of those as projects, but they certainly do a great job of generating things to do. If you don’t find a way to tame the list they are generating your reward is more head clutter. “Did the car get inspected?” “Did that charge-back show up on the next bill?” etc.
I have one more trick. I love this trick. I learned this years and years ago from the original version of Hypercard. One of the example stacks in the original Hypercard was for something called a lateral file. I have one. Each time something comes in that needs to be filed I grab a folder and stuff it into the folder. I then write an number on the folder and put it into the lateral file in numeric order. I then add an entry describing it to a page in the wiki that tells me what’s in the lateral file. When I want to find my glasses prescription I go to the Wiki, I do a search for glasses. That finds the number and I pull it from the lateral file. This works because it lowers to nearly zero the cost of “get this filed.” It raises slightly the cost of “find this.” But most importantly it avoids the tar pit of “maintain appropriate ontology for the problem domain.”
Almost all of GTD is about finding the sweet spot of where one is organized at a reasonable costs. For example he spends a surprising amount of time in the book talking about the physicality of his system. What kind of folders to use, how to label them, etc. My perception is that these bits of advise come out of his observation of his clients and what rituals cause their coordination costs to rise for no benefit. Some of his advice of this kind seems wierd – for example he’s a huge fan of having a label maker for your folders. I don’t know why, maybe his clients have horrible hand writing or maybe it raises the perceived value of the folders and helps assure their long-term maintenance/survival.
Of course Kieran Healy pointed out the key to getting lots of stuff done. Prioritize your work! Recognize what the absolutely most important thing to do is! Then leverage the anxiety that produces so you keep you focused on other less important work. This will help to assure that lots get done. Works for me! Works so well that it makes me suspicious that the guild of project managers spends all that time creating anxiety just to tap into this powerful secret.
If my system worked then my tickler file or calendar would have reminded me that this was talk like a Pirate day. Instead my honey told me. The GTD system has no mention of the role of one’s honey! That can’t be right.