In general, I highly discourage putting information or things you need to act on into piles. Filing is more organized and easier, if done right. But there are some exceptions. Here is a breakdown on when to file and when to pile.

When to Pile

Create piles for things that you are working on at the moment or will be working through in the next few hours. Used in this sense, piling becomes a fairly simple and effective a way of organizing your workflow.

Here is an example. I was just going through my inbox at home yesterday. It included some ideas I had written down on paper (normally I try to put ideas I want to do something about directly into OmniFocus as inbox items electronically, but sometimes it works best to jot them down on paper), receipts that needed to be entered into Quicken, some bank statements to reconcile, various small 4-minute-or-so actions, and various things to file.

I could have deferred most of these actions and put them into the set of pending files that I have for my routine actions. But there was quite a bit of stuff, and I wanted to do all these actions right away to get them over with. So I created a pile for each type of action and sorted the items into those piles as I processed my inbox.

Here are the piles I created: Receipts to enter, notes to process, bank statements to reconcile, bills to pay, things to file, and “other small actions” to take. Then I went through the piles one by one and took care of everything in them (entered all the receipts into Quicken, paid any bills and set up auto payment for the ones I could [we just moved], processed the ideas into projects and actions, and so forth).

Piles are effective in situations like these because they are temporary. It is helpful to have your work laid out and visible before you. Then you go from one pile to the next until you are done.

But piles are ineffective if you keep them longer than a few hours. The key is to get through them right away, not let them sit for days. If you do that, the actions get stale — unless you turn to filing.

When to File

If you are going to defer working on a group of items, then they should go into a file, and the action to complete those items should go on your next action list. I’ve noticed some routine types of actions that recur every time I go through my inbox: receipts to enter, ideas to process, and so forth — basically the piles I listed above. So I have created a set of files that correspond to these types of actions.

I call these “pending files.” They are holding tanks for work I am going to be attending to shortly. In the example above, I wanted to deal with all the actions coming from the processing of my inbox right away. So I created piles and worked through them immediately. But if I had wanted to defer those actions, I would have just put them into the appropriate pending files. To make sure I wouldn’t forget to actually deal with the items in those files, I have a weekly task to empty each of them completely (every Saturday morning).

For stuff that doesn’t fall into a routine pending file, I have a “catch-all” pending file called (creatively), “general.” Whenever there is support material I need for any action not covered by one of my routine pending files, I put the support material into the “general pending” file and then put the action on my next action list (and make note that the support material is in pending).

For example, if I get a long contract I need to review at work before signing, and I don’t have the time to review it right away, I’ll put the contract in my “general pending” file and then create a next action to review the contract. I would not, on the other hand, just leave the contract on my desk as a “reminder.”

It is an important principle that you should manage your actions from a list (with any needed support material in a file), not from piles — with the one exception being when you are going to work through the piles right away.

This discussion has focused on filing vs. piling when it comes to actionable documents. When it comes to storing reference material and project documents, filing without question is the way to go. There is a whole system that can be applied to filing in this sense which I’ll be talking about soon.

A few years ago I was waiting in line for my order at Taco Bell, and I thought to myself “these guys have a better productivity system than I do.”

I had been doing GTD for a while, but things still weren’t clicking. What stood out to me was how simple of a system they had at Taco Bell for processing orders: it just listed the items they had to make for each order.

Very simple. Very, very simple. Here’s what’s intriguing: In the GTD methodology, each of those items in an order is technically a “project” because it involves more than one step. But obviously if the order system had broken those items down into their actual “next actions” (“now grab a handful of cheese, then a cup of chicken and put it in the tortilla”), you would have chaos and confusion.

The problem is that that is exactly the way I had been handling my next actions list. I was dividing tasks up into pieces that were way too granular. Since in GTD your “next actions” are on a different list from your “projects,” this was really confusing — I couldn’t keep track of which actions pertained to which projects. Further, after completing an action, the natural thing would be to do the next “action” on the project — but my system didn’t facilitate this, because each project only had one action on my next action list. So instead of moving ahead on the same project after completing an action, I’d move on to a different project — highly inefficient and scattering to your efforts.

This was a mess. I don’t blame GTD for this — nothing in it says that you need to get this granular. But it sure sounds that way at first. It is easy to implement GTD wrongly by making your actions too granular.

There are a lot of solutions here that make GTD much more effective, even if you haven’t been taking things to the granularity that I was. Sometime soon I plan on writing something fairly comprehensive on this.

But in the meantime, the most significant solution is what I took away from the cooks at Taco Bell: I started defining my next actions not according to real specific steps (highly literal “next actions”), but according to what I can accomplish in one sitting.

In other words, I don’t always ask literally “what’s the next physical action I can take here,” because that can really make things overly-specific. Rather, I ask “what is the outcome I can accomplish here in one sitting.” The result is that many things that would have otherwise been projects actually become straight next actions, thus de-cluttering my projects list. Projects become more the multi-step things that need to be done over the course of several days.

So there has been a shift in my thinking, in part, from defining projects as “multi-step outcomes” to “multi-step outcomes that I won’t do in one sitting.” And when defining a next action for a project, I try to actually create an action that will trigger a series of steps, not just one, by asking “what can I do in one sitting,” rather than “what’s the next specific, literal thing this project requires.”

This is like Taco Bell: You see “make steak taco” and you make the taco. Very simple. But if your next action list is at the level of “put in the cheese, add the meat, etc.,” that’s just tough.

(BTW: The folks at Taco Bell on Franklin Ave in Minneapolis are some of the fastest I’ve ever seen. Way to go!)