April 2nd, 2008 by Andre
During the month of April I’m going to publish a series of posts of individual best practices for streamlining workflow. I’ll refer to these practices as “patterns,” an allusion to Christopher Alexander’s seminal book, A Pattern Language.
Alexander’s book weaved a rubric of 253 timeless, almost anthropological principles for architectural, urban and community design, in which each of its named and numbered patterns could be implemented individually or in combination with others. An example would be a pattern like Six-Foot Balcony, in which Alexander observed that balconies less than six feet deep went unused, aside from hanging plants. People would not occupy them, since the space was inadequate to install a table and chairs.
Alexander referred to the rubric — the collection of patterns — as a pattern language. Later, the concept was adapted to software engineering by Erich Gamma in his book Design Patterns. The practice of pattern classification spread to other disciplines, from web design to political activism. I’m adapting it to productivity here in order to separate more fundamental issues of methodology from the details of implementation. A term like “lifehack” risks conflating fundementals, like project lists, with particular solutions, like Remember the Milk.
The first pattern in this series, and many of the ones that will follow, are drawn from the everblogged Getting Things Done (GTD) methodology. Because so many posts on Tools for Thought make reference to GTD, I’ll be writing my own review of David Allen’s Getting Things Done later in the month. While it’s true that the internet is saturated with GTD discourse, I’ll review it here to provide my outlook on the book and the system for readers to compare and contrast with that of other pundits and bloggers.
Pattern #1: Outcome and Action
Issues, concerns, intentions, ideas and ambitions tend to weigh on the mind in an abstract way. We need a way to think about them more concretely. An item that consumes our attention is an open loop in GTD parlance. It has our attention because we still need to define precisely what successful outcome is needed to realize or resolve it — what will bring the open loop to closure.
Write down one or more issues that are currently on your mind. They might be things like, “I need to submit my application to Stanford,” “I still need to arrange our vacation to Bora Bora this year,” or “My bookshelf stereo is broken.” For each of these items, ask yourself the following question: What is the successful outcome? Exactly what result would have to happen in order for you to feel as though you could confidently mark it as done?
Notice that successful outcomes are implicit in many of the items. Some are even explicit. “Submit application to Stanford” is an explicit answer to What is the successful outcome? On the other hand, “My bookshelf stereo is broken” is a good example of an open loop whose outcome clearly needs to be defined. If the stereo has been idle for the last seven months, and you haven’t missed it, the successful outcome might be “Discard bookshelf stereo.” You may decide that you’d like a newer stereo, in which case the successful outcome might be “Replace bookshelf stereo.” The first goal with each open loop is to process it into a successful outcome.
Now take each of your successful outcomes, one at a time, and ask: What is the next action? A next action is the very next physical, visible action step needed to achieve the outcome. As a technical term in GTD, a Next Action (NA) sometimes coincides with the types of tasks that most people would put on a To Do list. But not necessarily, since the criteria for next actions are physical and visible, not abstractions.
Tasks like “Download application from Standford.edu,” “List ‘Bookshelf stereo, needs repair’ on Freecycle,” or “Submit vacation request to HR” qualify as bona fide next actions. On the other hand, an item like “Submit application to Stanford” is not a next action — unless the application has already been downloaded and filled out. Similarly, “Write research paper” would not be a next action prior to having done the research. Next actions have no dependencies. They are only those tasks that can be executed immediately, since the actions or resources required to perform the tasks have already been fulfilled. If they haven’t, there’s a good chance that the preliminary step is what you should be writing down is the next action, such as “Call Oakville High to request transcript.”
In GTD, any outcome that requires more than one action step to accomplish is called a “Project.” Projects can range from very simple outcomes, like purchasing a book, to complex outcomes, like building a bridge. The common denominator is that they require more than one action step. Keeping these projects listed separately from next actions allows the projects to remain identified as open loops when their respective next actions have been completed. If I call to request a transcript, then cross that off of my NA list, the separate project heading, “Submit application to Stanford” remains as an open item, compelling me to either define another next action, or recognize that any subsequent action to move the project forward will depend on receipt of the transcript. Dependencies like the latter are called “Waiting For” items, which are often as important to track as next actions.
To recap, the fundamental thought process for getting things off your mind consists of two questions that need to be asked and answered for each item:
- What is the successful outcome?
- What is the next action