Shopping lists seem intuitive enough. It’s not common for people to include the items they need to pick up at the grocery store in their To Do list. Keeping a separate shopping list prevents having to sort through related procurement tasks — “Get lettuce” (or just “Lettuce”) — and unrelated tasks like “Replace washer in faucet.” The logic of keeping these lists separate seems self-evident, but extending the principle to multiple batched lists, called context lists, can be problematic.
I’m still pretty averse to context thinking, to be honest. I used to be all over it, but I noticed how much time I spent in metaproductivity when having more simple lists with well-specified action phrases helped me along just as well if not better.
Context lists are popular within GTD, but some users are like Charlie: having multiple lists like @Computer, @Home, @Errands, @Calls and @Office seems to create more work than it saves.
I’ve always found that position curious, since context lists were one of the first things I latched onto when reading Getting Things Done. It made logical and intuitive sense that looking at a list of 13 next actions is easier than looking at a list of 130.
Where is the complexity?
This isn’t a rhetorical question. I’d like to know from those who resist context lists what makes the more time or labor intensive than a single-threaded action list. If I’m at work, and I suddenly think of something I need to do at home, it takes just as long to write it down on my @Home list as it would to put it on a congealed To Do list.
But when I get home, instead of looking through an entire To Do list to figure out which ones I can do and which ones I can’t, the @Home context list has done the work for me. My decision load is reduced to thinking about the best thing to do without first having to work out which ones I can do.
Here are some possible reasons people might opt for non-contexual lists:
- They’re writing To Do lists rather than Next Action lists
- They work in a situation, like a home office, where contexts overlap
- They continually reorganized their contexts before abandoning them altogether
- They felt the need to review all contexts instead of the current one
Let’s take a closer look at each of these.
To Do lists rather than Next Actions. As a rule, Next Action lists only contain physical, visible actions with no dependencies. “Email Anne” is a next action because you can actually visualize being at the computer typing the email. “Contact Anne” would not be a next action, since it requires the further thinking step of determining how to contact Anne. The next action of “Email Anne” has been “intelligently dumbed down” to a mechanical activity, whereas “Contact Anne” is a cognitive activity.
When it’s time to do, you don’t have to think about when to do next because you’ve already thought about it. Assigning each task to a physical context provides a reality check against writing down unspecific tasks that require another iteration of thinking when they’re reviewed.
If an outcome requires more than one action step, the next action is entered on the appropriate context list and the outcome (project) is listed on a separate Project list. Listing projects separately allows you to delete the next action when completed but still have an identifier that a new next action needs to be defined. If a To Do list item actually represents more than one individual action step, it’s possible to delete a partially completed multiaction task without realizing that further action is required to close the loop.
Overlapping contexts. Most offices have a phone and computer, so why have separate @Calls, @Computer and @Office lists? To identify the dependent variable. Calls on the @Calls lists are for ones that can be made from any phone, like making hotel reservations. If a call has to be made from the office because you need access to files that are only there, then the call would go on the @Office list, not the @Calls list. If a call requires being at home to answer a repairman’s questions, the call is an @Home next action. But the vast majority of calls aren’t location-dependent, so it’s more efficient to batch them for handling as a group than hunt for them individually a monolithic To Do list.
Perpetual reorganization. This usually starts by trying to adapt someone else’s contexts without determining if they really apply. For instance, I don’t use Agendas, since I work at home and don’t answer to any one individual regularly enough to require batching topics. Sometimes it happens from a change in working situations. I no longer have an @Office context, so most “@Work” tasks are now @Computer items.
I don’t think constant system tweaking comes from re-deciding categories, but from never having concretely decided them in the first place. Assuming that’s true, the best practice is to sit down for a few minutes and write out a concrete checklist of all of your work sites (“work” meaning all tasks, personal and professional), then ask, “Where do I need to do this?” of each next action as it comes up.
Reviewing more than one list at a time
There’s a difference between having all your context lists available and reviewing them. The point of having them all available is so that you can add to them as needed. We often think of things in places where we can’t act on them. Instead of orphaning those thoughts and hoping they’ll resurface when you’re in the right context, it’s easier to simply write them down in an appropriately categorized list.
Except for the weekly review, there’s no need to review any list other than the one that matches the context you’re currently in. It’s actually a waste of time and mental effort to do so, unless you’re just about to change contexts (reviewing your @Errands list right before leaving work). Keep the other drawers in the wardrobe closed, and stay focused on the present moment by only pulling out what’s needed.
(Photo credit: cesarastudillo)