43 Folders

Back to Work

Merlin’s weekly podcast with Dan Benjamin. We talk about creativity, independence, and making things you love.

Join us via RSS, iTunes, or at 5by5.tv.

”What’s 43 Folders?”
43Folders.com is Merlin Mann’s website about finding the time and attention to do your best creative work.

Back to GTD: Simplify your contexts

This post is part of the periodic “Back to GTD” series, designed to help you improve your implementation of David Allen’s Getting Things Done.

As we've noted before, GTD contexts lose a lot of their focusing power when either a) most of your work takes place at one context (e.g. "@computer"), or b) you start using contexts more for taxonomical labeling than to reflect functional limitations and opportunities. As you may have discovered, these problems can collide catastrophically for many knowledge workers, artists, and geeks.

Part of what makes the Natural Planning Model so attractive are the decisions that can be guided by contextual limitations ("I'm near a phone" vs. "I'm at the grocery store" vs. "I'm at my computer"). While it's definitely a kind of "first world problem" to have, facing the unlimited freedom to chose from any of a bajillion similar tasks from similar projects with similar outcomes is not nearly as fun as it first sounds. Consider the contextual hairballs of certain jobs and tasks:

  • Developer - Much of the work is writing new code, fixing old code, or testing code. All of these require essentially the same tools and environment, so how do you apply real contexts?
  • Writer - Needs to research, draft, revise, and edit manuscripts. While the "Write book" project will break down nicely into multiple sub-projects and tasks, how do you satisfactorily "context-ize" this physically identical work?
  • Designer - Whether coming up with a print layout, web design, or what will become a physical artifact, how do you segment the work further than "@photoshop" and "@illustrator"?

This causes many of us to fashion more or less phoney-baloney "sub-contexts" that reflect some facet of the parent (e.g. "@computer" might contain "@email," "@web," "@code," "@print," and so on). While this makes terrific sense from a logical standpoint (and it can certainly have its uses), it doesn't reflect the true meaning of a context, at least in my own mind: "what tools, resources, opportunities, and limitations are unique to this situation?" or put slightly differently from the perspective of choosing tasks at a given time, "what are the things I can't work on now given where I am and the tools to which I have access?"

More and more, I think the solution may be to toss out or consolidate any contexts that don't have unique functional attributes. I mean, by all means, keep them if they're working for you, but if you find yourself spending more time deciding where to file tasks than actually completing them, you might consider dialing your contexts back as far as you can stand. For the geeks in particular, consider having two and only two computer-related contexts: "@online" and "@computer-anywhere." If you have other contextual needs, add them in with care, then periodically revisit to make sure you aren't maintaining superfluous parts.

If you feel a gnaw about the loss of your old contexts, try to shunt some of the mental load into sub-projects and better verb choices in your tasks. Where you once had (as I did) an "@print" context, consider whether an "@computer" task of "Print Jim's email" might be sufficient for the job. Remember, maintaining fewer buckets is always a good thing.

As you doubtless have learned, this is ultimately all about choosing valuable work and then tracking it as simply as possible via carefully-worded task reminders. No amount of meta-crap can magically transform junk tasks into stuff you really want or need to do. Contexts can help shape your day, but they're less than useful if they don't track realistically to the demands of your work.

Brent's picture

This is the hard part...

This is the hard part of contexts. They are so open that sometimes can be a problem to decide. At work I usually use only 3 and Im not so happy about it: @Action, @Waiting and @Calls Maybe thats the beauty of it!

One of the things that I've found hard about implementing GTD has been to actually focus on what IS a context, and what is a bucket.

This person has confused the two.

@Action isn't a context... it's a thing you can do when you're in a context. Same thing for @waiting. @Calls is ostensibly a context, although I'd prefer it to read @Phone...

what is a context? a context is a thing where it fits into the sentence "When I'm at ________ I'm going to want to be able to do these things."

Having @action and @context is kind of like saying "I'm going to be able to do these things when I'm ACTING, and these things when I'm WAITING." That makes no sense.

Your contexts are physical realities - @home is differnet to @work. @shops is different again. @online is different to @PC. @waiting-for doesn't mean anything. What is this 'waiting-for' place? how do you know you're in the context of 'waiting-for'? what limits your physical capabilitiies that you're 'waitingfor'?

my contexts are: home work shops pc

(I don't need the @ because handyshopper is clever enough to label this tag as STORES - a very neat and easily conceptualisation of CONTEXT)

My buckets are: next-action project someday/maybe waiting for

That's it. Everything in my life is a project, an action, something I might one day do, or something I'm waiting for: at work, at home, at (any internet) pc, or at the shops. Then I cross reference them all and forget about it.




An Oblique Strategy:
Honor thy error as a hidden intention


Subscribe with Google Reader

Subscribe on Netvibes

Add to Technorati Favorites

Subscribe on Pageflakes

Add RSS feed

The Podcast Feed


Merlin used to crank. He’s not cranking any more.

This is an essay about family, priorities, and Shakey’s Pizza, and it’s probably the best thing he’s written. »

Scared Shitless

Merlin’s scared. You’re scared. Everybody is scared.

This is the video of Merlin’s keynote at Webstock 2011. The one where he cried. You should watch it. »