In one of the recent podcast interviews I did with David Allen, we talked about procrastination and how he tries to get people -- especially knowledge workers -- back to just "cranking widgets."

I love this term, because, in his humorous way, David captures how any thing we want to accomplish in this world eventually has to manifest itself in an intentional physical activity. Seemingly over-huge super-projects like "World Peace," "Cancer Cure," or "Find Mutually Satisfying Vehicle for Jim Belushi" all still come down to physical actions, such as picking up a phone or typing an email.

And David is wise, in that interview, also to highlight the importance of what he refers to as a "'look-into' project," which just means that even deciding if a project is interesting and useful to undertake can be a project in itself. It also means that, even with an outcome of "deciding," that meta-project still consists solely of physical actions. In this case, it's the physical actions that help you locate the additional information you'll need to make a timely and wise decision about whether to proceed at all. In sum, no matter what, it all still should come back to widgets and how they get cranked.

Like a lot of you, I've struggled with how you turn "thinky work" into physical action widgets, but here are a few of my favorite task-verbs to get you started in the right direction. They're presented here in a rough approximation of the order in which I use them in my own "look-into" projects:

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:

Herewith for your approval, a few handy tricks I've been discovering for getting the most out of the peerless Omni Outliner Pro/kGTD combo.

And don't forget -- as noted last week -- through the end of this month, when you buy any OmniOutliner product from the OmniGroup site, you can use the checkout code 43FOLDERS to get 25% off your order. Disco!

1. "Hiding" fallow projects

In last Thursday's podcast, "Fallow Projects and the Bread Crumb Trail", I mentioned how I like to move stalled or clinically-dead projects off my immediate radar screen; it makes it so much easier to focus when only actionable stuff is being tracked actively. Anyhow, lots of people asked for more details on that, so here you go.

In kGTD, you want to create a holding pen for these sick animals by generating a new top-level Project and calling it, say, "Fallow Projects #" (or whatever you prefer, but do include the "pound") then scooting all those moribund projects thereunder. Cool enough, but, here comes the nifty.

Putting Geeks in Context

43folders.com - One way around the geek's problem with GTD contexts? Step away from the computer. (4:37)

More at Odeo.com...

Not all tasks are created equal. Our to-dos all differ in priority, complexity, time requirement, and context, so it’s probably daft to always capture and expose them in an identical way. I have a little trick for dealing with this that’s been working really well for me.

Back in the day, my to-do list was an egalitarian nightmare of inefficiency — verb-centric “next actions” through they all were, I commonly faced a task list that looked something like this:

• call Alice about Foo project
• fix line 125 of bar.php
• fix line 349 of bat.php
• take out kitchen recycling
• buy milk
• buy index cards
• sweep the decks

Now, the problem here might be self-evident to you smarter people, but I was missing an important concept: there is such a thing as too granular a task to track as its own event. In this instance, I was cruftifying my landscape with items that were way too detailed or tiny and, consequently, I’d turned my task list into an undoable roller coaster of un-focus. Just as “projects” are composed of “tasks,” I like to think that “tasks” themselves can often be collected into silos of small “mosquito tasks.” And my solution, as ever: text files and alarms.

What context do I put my Next Actions in? :: MarkTAW.com

Mark Taw consistently provides some of the most lucid and realistic productivity advice I’ve come across. Today he eloquently addresses a common question of beginning Getting Things Done nerds.

If you have 15 lists, but they’re all full of things that you can do from the same starting point, you have 14 too many lists. It doesn’t matter if it’s a phone call, email, or going to the printers to pick up your business cards, your lists should contain no more detail than that. And don’t complain to me that your list would be too long that way, breaking it up into more lists doesn’t give you any fewer Next Actions, it just lets you procrastinate some of them more by putting them on a list you’ll ignore entirely.

Productivity programs like Getting Things Done obviously have been developed around the needs of managers, sales people, and entrepreneurs. This makes sense given that those are largely the people who are buying the books, listening to the CDs, and attending the seminars (or certainly represent the largest market share of potential customers).

But, one of my main goals with this site was to discuss the way that productivity plans and methods designed for the business world can be reframed in a context that's useful for developers, programmers, and garden-variety geeks. This is not to say that geeks don't fill many or all of these managerial roles in their work, but they also tend to have work styles, deliverables, and skillsets that are markedly different from the average, notional GTD user.

The prime example: "@computer." Man, geeks don't just use a computer for occasional work or to "look something up on 'The Interweb.'" They live on their laptop and take it anywhere they'd bring their wallet. They eat wireless like potato chips and crank out code for a living. They have an IM window and an IRC channel running all day. They're streaming conferences in and live-blogging conferences out. In short, if they follow the stock GTD setup, they will have a very, very long "@computer" list.

So I wanted to start a conversation about how geeks handle their lists, their projects, and their agendas--not so much in terms of the tool they use to store the information, although that's fair game--as with how they segment the information and decide when to break it into pieces. I'll start by providing the setup used by a San Francisco web developer who spends a lot of time on his PowerBook: me.

(Please note: since I'd love to see a lot of discussion about this, please post your response on your own site and just send a single trackback ping to this post (hit: http://www.typepad.com/t/trackback/1128456). Comments below are ok for short responses or for posting links to your non-tracback-able site, but please try to limit yourself to a paragraph or so. Thanks.)