Getting Things Done

“Getting Things Done” or GTD is a productivity framework introduced by David Allen. Since his book was first published in 2001, the paradigm has achieved something of a cult status, especially among Emacs users.

The framework consists of multiple systems, such as a system for “capturing” incoming ideas or tasks, and a flow diagram for actioning off of them. The framework does not dictate any particular software; anyone who adopts the framework must decide for themselves how to implement it. Consequently, pretty much everyone who uses this framework does so in their own way. In this post I will describe my very-much-in-progress implementation of these systems.

Overview

The GTD framework consists of:

• Project List
  • A project is any category of work where you expect to take action in the next year.
  • A project is characterized by a “desired outcome” and one or more actions.
• Capture System: an “inbox” for collecting ideas or tasks as they come in.
• Inbox Clearing Ritual: migrating items from the Capture System to the Project List.
• Next Actions List: next actions for each project.
  • A project without next actions is not a project.
  • Each action should specify a context in which the action can occur such as “at work”
• Waiting For List: actions blocked in some way.
• Someday/Maybe List: projects you’re not planning on working on any time soon.
• Calendar: for time-specific or day-specific actions or information.
• Tickler System: for periodically reminding yourself of something.
• Reference System: for gathering information.
• Weekly Review

Project List

Each project is defined by a desired outcome and a list of actions. One action is denoted as the “Next Action” and should be highlighted as such.

Projects are hierarchical. Some projects are fairly limited in scope like “Get groceries”, while others stretch on for months like “Develop fancy AI platform”. Projects can be broken down into milestones or sub-projects, each of which should have its own desired outcome and list of actions. In Jira, we can arrange things into epics, stories, and subtasks. In Trello, we can arrange things into boards, lists, cards, and checklist items. In Emacs, we can use org-mode to have as many layers in the hierarchy as we want, and that’s what seems best to me for managing the Project List. But anything that allows you to keep track of desired outcomes and lists of actions will work.

Capture System

Allen writes about the negative impact of “open loops” on productivity. An open loop is anything pulling on your attention, such as an unfinished task. If there is one central idea to the GTD framework, it is that eliminating open loops improves productivity.

The way to eliminate an open loop is to “capture” it in a trusted system, and “clarify” the desired outcome and next actions. Once your subconscious trusts that the item is safely stored and won’t be forgotten, it can let go of the open loop.

Open loops can form at any time in any context, not just at work. For example, open loops often form during your daily commute or at the gym. The sooner this open loop is captured, the more effectively you will be able to “be present”. Thus, an effective capture system must be accessible at all times.

That insight led me to leverage Google Home, Siri, and Trello as parts of my capture system. I created a Capture board in Trello specifically to act as an inbox. Once items have been processed they are moved elsewhere, so the Capture board is strictly a staging area that should be emptied frequently.

I created a Siri shortcut so I can just say, “Hey Siri, Capture Task”. Then whatever I dictate is turned into a Trello card on the Capture board. I can also say, “Hey Siri, Capture Image”, and the camera app will open, allowing me to take a picture that gets saved to the Capture board. That way I can capture pretty much anything. Similarly, if I’m at home but don’t have my phone for whatever reason, I can say, “Hey Google, Add Task” and do the same, but I can’t capture images that way.

Most people need more than one “capture bucket”, but the fewer buckets the easier it is to manage them. Your email inbox is another bucket, as is Slack and other communication channels. Many Emacs users use org-capture as their primary capture bucket, but I’m not always at my computer, so org-capture is not sufficient. I would love to leverage that more for capturing articles I want to read and other miscellaneous items that come up while at my computer. This is a work in progress for me!

Inbox Clearing Ritual

Your capture buckets should be reviewed frequently, perhaps daily or twice-daily, to process items. (This should certainly be done at the end of each work day to avoid the Ovsiankina effect, whereby unfinished tasks become intrusive thoughts.) For each item, document the desired outcome and ask “Is this actionable?”

If it’s not actionable, there are three possibilities. If the item can be discarded, then do so. If it’s not actionable now, but will be actionable at some point in the future, it gets added either to the Someday/Maybe list, or to a “Tickler System” that will remind you of the action at the appropriate time. This could be as simple as an email you have scheduled to have delivered to yourself in the future. More on this below. Finally, if the item is informational in nature, it will never be actionable but you want to hold onto it. These items go in the Reference System.

If the item is actionable, we identify the next action. If that next action can be completed in less than 2 minutes, we do so immediately. Otherwise, we decide whether to delegate it or defer it. If it makes more sense for someone else to do it, we delegate it and add it to our “Waiting For” list. If we defer it but it has a hard deadline, we schedule it on our Calendar. Otherwise, we add it to our Next Actions list. Allen recommends adding most items to the Next Actions list, even if they seem time-sensitive. (Most things do not actually have hard deadlines, but rather should be done as soon as possible.)

At the end of the Inbox Clearing process, all capture buckets should be empty, and all items migrated to another list or system.

Next Actions List

Each project or sub-project should have a defined “Next Action”. It should be easy to scan “horizontally” across all projects and examine the next actions to decide what to work on next, taking into account context, time availability, energy availability, and priority. With org-agenda, we can generate this list filtered to the current context.

Update 2020/08/02: I have written more about my Next Actions list here.

Waiting For List

An action may be blocked in some way. For example, we might be waiting for information from someone else. Such actions should be marked as such and should be easily reviewable. This can also be done with org-agenda, but I haven’t set that up yet.

Someday/Maybe List

This is a list of projects you’d like to work on eventually, but no Next Actions have been defined, at least not to be worked on in the next year. For example, “learn to play guitar”. It is important to document these and review the list occasionally to prevent them from being a distracting open loop. But this list should not be mixed in with the project list. I keep my list as a separate “Personal Goals and Objectives” Trello board with categories like “Math”, “Technology”, “Leadership”.

Calendar

The calendar should consist only of those items which really do have hard deadlines. Meaning, if the task is not completed by that time it should be discarded. Most tasks are not this way! Meetings and appointments fall in this category, as would things like “buy Coachella tickets the second they go on sale”. The other thing that goes into the calendar is information that is useful on a particular day, like birthdays, and meeting-specific reference material. I just use Google Calendar for this purpose.

Tickler System

With a Tickler System, you should be able to insert an item and receive it back at some particular time. Boomerang provides this functionality for email, but the free tier only permits 10 messages per month. Instead, I will use org-schedule.

While Allen describes the Tickler System relative to specific times, I think it would be interesting to have a system that sends you a reminder in response to arbitrary triggers like “Stock X dipped below $Y” or “Stephen Boyd published a new paper”. That system would need to be able to monitor such things, but perhaps IFTTT could be an effective Tickler System.

Reference System

We need a way of accumulating reference materials, such as papers to read, meeting notes, etc. Org Mode is great for this when I’m at my computer, but I often need to be able to access reference materials on the go. I save papers to my DropBox which gets synced to the GoodReader app on my phone. That way papers are accessible wherever I am. I also use Anki to help memorize useful information. And I often write blog posts (like this one) to help me synthesize information and have something to refer back to later.

Weekly Review

Periodically, perhaps once a week, we review each project to make sure it is still relevant, perhaps moving to the Someday/Maybe list if not. We also review the Someday/Maybe list to see if we want to move an item to the Projects list. This process should be done frequently enough to keep on top of everything. Like cleaning house, the less frequently you do it, the more arduous it is!