Decreasing Granularity in GTD
Contexts are forever a sticking point for new adopters of Getting Things Done (GTD), but they are also an extremely popular discussion point for long-time practitioners, including myself. They are highly personal and dependent on your daily routines, hardware, software, lifestyle, personality, company policies, and hair color. And that means there are just as many variations on how to use them.
Just to prove my point, you can set up contexts following locations, time of day, software, energy levels, type of work (writing, development, etc...), urgency vs importance, duration required, difficulty of the task, priority, areas of life, Goals, and sometimes you see anti-contexts like @Do. And this is just the list that came out of my head on the first go. And, full disclosure, I've tried almost all of these at some point.
The trouble comes in choosing the context specific to the task. According to the book, you should be choosing a single context for a task. And I've done my best to follow that advice despite the massive backlash against the concept and the enormous support for multiple contexts (tags) in most mainstream software that is used for GTD. And that begs the question: why? Why do people want multiple contexts on each task?
From what I can tell, there are two aspects at play here. One is that we've become extremely mobile in our work and find ourselves untethered from the traditional office and desk, which means our work can be done wherever we please. The second aspect is that because work is so mobile, it is increasingly difficult to choose the one place or thing we need to do a given task. And that makes it hard to decide. We would rather not decide and put any/all possible contexts on a task. Then we can grab whichever one suits our fancy in the given moment.
But that creates a different problem, doesn't it? How do you know if you've captured all the possible contexts? Here's another: what if there are some contexts you don't like working in? Do you avoid them or put them off?
Let's ignore those questions for a minute. Let's say you're awesome at ticking boxes in all contexts and you don't worry about collecting all the possible contexts. You have a good handle on it. Does it help? And how much time and effort does it take to keep it all in working order? If the answer is a super small amount of time, maybe you're fine. But I'm willing to guess it's quite a bit. Remember, I've tried it and it took a while to tag a task and then continually review it at least weekly, if not daily. Is that worth it? What could you do elsewhere with the mental energy spent on managing these tasks? And what is the alternative? And, in reality, do you use all these tags?
Again, I've been a stickler for a single context on a task for a long time. But I have tried the multiple tags system several times with no success. I either spend inordinate amounts of time keeping up with them or ignore them altogether. Which is why I gave up on tagging and contexts entirely.
When you remove the context filtering of tasks you're left with either a single list of all available work to be done or you have to look at the to-dos on a project by project list. In other words, you have to look at t everything at once and be overwhelmed or you have to focus on a single project. Great! Now I'm being more intentional, right?
Not exactly. Most folks, myself included, have too many projects on their plate. So choosing a project to focus on and working from that list only pans out if you limit the number of projects in play and you can keep the tasks about that project accurate. The former is taken care of by saying "no" to too many commitments. Not an easy thing to do, but easy to understand and frequently promoted. The latter (accurate tasks on a project list) is a little less simple. What if your boss emails you with changes? What if you had an idea in the shower that changes things? What if there's a health crisis at home? That project can morph and change multiple times a day.
It's okay for a project to switch directions or grow or shrink over time. That's to be expected. The question is: should you continually review and update the list of tasks on a given project to coincide with these changes? And if you do a good job of keeping the list of projects small, do you even need a list of tasks for each project? You likely know the next steps intuitively anyway. Or depending on your role, you may need to review new inputs before you can accurately know the next action.
This is not to say you shouldn't keep a list of actions for a project. You should. I simply disagree with the assumption that every tiny piece should be spelled out in detail and regularly reviewed. That's an attempt to turn me into a robot that simply works off of a list.
Instead, I have found enormous benefit in minimizing the system entirely. By keeping a limited project list, breaking out massive projects into sub-projects (not tasks), and writing a daily list based on my long-term goals, I cover the core tenets of GTD without going into the extreme level of detail often found in GTD system all over the internet. And it allows me to continually pull my actions back into alignment daily without mindlessly ticking off boxes.
Are there routine tasks you should keep on a list? Absolutely. What about specific actions on a given project? Put it on the project list, but keep it broad. What about non-project tasks that come up? I write them on my projects list and knock them off quickly so the list can stay pruned. This sounds messy and haphazard, are you crazy? Very likely. And it probably is too loose for most. But in the fast-paced, quickly-changing arena of technology and support, plans change frequently.
This process is one I've been refining and altering for about a year now and I know it has shortcomings. But these shortfalls are worth it in exchange for the flexibility and freedom it gives me to trust my intuition and set intentions for each day I'm given.
