156: The State of GTD

I think this is a place where David Allen is just wrong. He actively discourages using priorities. You’re supposed to look at the appropriate context list, figure out the time available and then you will intuitively pick the most important task on the list in that moment.

I think it is better to make a plan seeing that on Thursday I have a day full of meetings, so I better work on project X on Monday and project Y Tuesday and Wednesday. My intuitive sense on Monday might have forgotten about the meeting logjam on Thursday and I work on the less important project Z instead of X because project Z has a task that is smaller and easier to do.

The other thing to note is that the original book was released in 2002, and thus the advice in the original book was obviously formulated before that.

In 2002, we didn’t have ubiquitous smartphones. “Phone” was something you had to be at, at least if you wanted a high-quality connection for anything that mattered. The possibility of seriously working on a Word doc on a device that we could conveniently throw in a jacket pocket was nonexistent. And categories like “home”, “office”, and “errands” (i.e. stuff you likely do while moving between home and office!) were incredibly useful ways to sort things.

Now, we have tons of devices that make everything possible everywhere. Which is cool.

But saying “contexts are dated” is kind of like saying “GTD talks about file folders, and everything is digital now - so GTD is dated”.

The underlying principles are still perfectly valid. File things in an alphabetical way that makes sense. Don’t over-think it. Purge periodically. If you can’t do something now, send it forward in time using your tickler system.

The fact that we’re doing that all digitally now doesn’t inherently mean the principles are dated - it just means that the implementation of this stuff is changing, so specific examples from the book might not apply.

And FWIW, there’s still an opportunity to question whether it’s wise to do any task from anywhere, or whether applying some compartmentalization to one’s life might be a Good Idea. :slight_smile:

Does he? I would believe that he discourages going through your entire task list and categorizing everything by priority, because those things can be constantly changing and thus trying to keep that updated creates a system that’s (a) incredibly time-intensive, and (b) less trustworthy. But I know he encourages people to look at the coming week during the weekly review, and I can’t believe he’d tell you (a) not to consider the landscape of the week during your planning time, or (b) not to schedule time for something that’s incredibly important to get done.

Emphatically, no. DA talks about how he frequently does things that aren’t even on his list. The list (and your calendar, and your tickler) is there to keep track of any open loops, so you can efficiently pick them up and refer to them when you need to. It’s an organized reference list of past commitments, so you can make intelligent decisions in the present.

There is nothing in GTD that says you have to do something off your list, nothing that says you can’t schedule a 2-hour block of time on Monday to do your task, and nothing that even says you need to work on your most important task.

For example, what if you get to work on Monday and realize that your brain is fogged to the point where you probably shouldn’t work on a given project - even though it’s the most important? You still have stuff to do, and you can make progress on that other stuff. Grab your list, look at what you can get accomplished in the state you’re in, and go.

That said, there IS something in GTD that says if you schedule a 2-hour block of time for something on Monday, you need to treat that as an actual appointment, not as a suggestion that you might want to consider doing something in that 2-hour block. Calendars are for things that are actually scheduled at their appropriate day/time, i.e. “hard landscape”. Everything else lives on your task list.

All of GTD is about the agreements you’re making with yourself, and trusting your systems.

3 Likes

But this is the point.
If project X is the most important task for you, David Allen encourages you, to work on that!
If you work on a less important project instead, it is not a fault of GTD, but of your way to determine the importance of your projects.
And you can set a timeline also within GTD, that is not “forbidden”.
If you have to be finished with a project by a certain time, you have to consider this also “within GTD”!
It just makes no sense (and that is David Allens point on that) to set a timeline on everything.

I haven’t read the book in many years, but I did get the impression from it that, at least when all all projects’ priorities are of the same order of magnitude, you should churn through your current context rather than switch contexts to continue pursuing your most important project. I also got the impression that he thought it was more important to immediately start into your context list to get more of it done, rather than trying to order it by priority.

I’m saying “impression” because I don’t remember the wording and I think the unintentional consequences of GTD (i.e. the magnification of David Allen’s assumptions and small preferences) are a legitimate aspect of its re-evaluation.

1 Like

Chapter 9 of Getting Things Done includes a subsection called “Priority” that includes this:

Given the context you’re in and the time and energy you have, the obvious next criterion for action choice is relative priority: “Out of all my remaining options, what is the most important thing for me to do?”

I don’t know where the idea that David Allen actively discourages using priorities came from. But my guess would be that maybe it came in response to the idea of assigning a fixed priority to each action or project as it enters the system? I can imagine him discouraging that.

I think he would say that prioritizing your work should happen more intuitively in the moment rather than by using any kind of fixed ranking. But that intuition is informed by a lot of other types of preparation, including the work you do during reviews and the overall values, goals, and vision you’ve defined for yourself.

2 Likes

Interesting - I didn’t get this impression at all. I think a context switch is the sort of thing that should be intentional, and DA would likely agree that sensible batching is good, but consider a hypothetical…

I have an @Work context. So I go to work, I pop open my context, and I decide to start working on the Davis project. I do some work, realize I’m blocked, and need info from Davis.

I could now make a call to Davis, or I could drop “call Davis” in my system as a Next Action for the Davis project and continue churning through @Work.

If I know Davis isn’t in the office, I might do the latter. If I know Davis is in the office, I give him a call and switch to my @Davis context. In that context, I have seven pieces of info I need to get from Davis, so I address my immediate concern first, and then churn through the context list if possible, because I have Davis on the phone.

And then I hang up the phone, switch back to @Work, and either continue the Davis project (if I have enough time to do it before my next meeting, let’s say) or pick something else (water plants) if I only have 10 minutes until my next meeting.

In that scenario I’m flexible regarding batching for @Work, but I’m more rigid batching @Davis.

Put simply, context list batching either makes sense or doesn’t depending on the nature of the work and the efficiency realized by the batching. In certain contexts it makes sense to batch everything, but in others it doesn’t.

Ultimately, your batching behavior is dependent on your needs at the time, with the goal of being maximally efficient and productive.

Maybe a useful way of stating that could be, “whenever you’re in a context, looking at the actions that apply to that context will help you maximize efficiency and make sure nothing falls through the cracks.”

2 Likes

This is what I do, I have a Time Blocks calendar where I put these commitments and it is integrated with the actual appointments for the day.

The point I’m trying to get across is that for me, the best time to prioritize and schedule work is during the weekend when I do my weekly review. During this time I don’t have any other pressures or distractions, I’m thinking about the bigger picture and what do I want to accomplish in the next 3 months, not just the next 30 or 60 minutes. If David Allen recommend this approach somewhere, then I guess I missed it.

In the GTD book DA does talk about looking over the next couple of weeks during the Weekly Review, and doing front-end thinking about the coming week. Of course the GTD book is explicitly oriented toward Runway and 10,000 feet horizons, because that’s where most people are stuck - but planning some dedicated time for your most important project is definitely “front-end thinking about the coming week”, and it’s definitely not inconsistent with GTD at all.

1 Like

I think the different memories of the book are interesting, too. For me, the idea that David Allen discourages priorities comes from his idea that complete lists of next actions, in the right context, for projects that correspond to internalized goals and visions, can be intuitively processed. I misremembered that as working in any order when it’s really supposed to be a lightning-fast jump to the best next action. I think he would say that if you are looking at your list and needing the A, B and C notation to see which are the most important actions, you don’t understand what you want to do well enough yet.

I pulled some quotes from the book that jumped out to me–fun to go through. Please excuse the length…

This is where you need to access your intuition and begin to rely on your judgment call in the moment.

[Horizons] can provide a useful framework, however, to remind you of the multilayered nature of your commitments and tasks.[…]Minute-to-minute and day-to-day you don’t have time to think. You need to have already thought.

“Setting priorities” in the traditional sense of focusing on your long-term goals and values, though obviously a necessary core focus, does not provide a practical framework for a vast majority of the decisions and tasks you must engage in day to day. Mastering the flow of your work at all the levels you experience that work provides a much more holistic way to get things done and feel good about it.

Another productivity factor that this kind of organization supports is leveraging your energy when you’re in a certain mode. When you’re in “phone mode,” it helps to make a lot of phone calls—just crank down your Calls list.[…]Having a discrete Calls category makes it much easier to focus and intuitively pick the best one to make in the moment.

it becomes much easier to trust your judgment calls about the dance of what to do, what to stop doing, and what to do instead.[…]At a master level, you can shift like lightning from one foot to the other and back again.[…]The challenge is to feel confident about what you have decided to do. So how do you decide? This again will involve your intuitive judgments…

I have learned over the years that the most important thing to deal with is whatever is most on your mind. The fact that you think it shouldn’t be on your mind is irrelevant. It’s there, and it’s there for a reason. “Buy cat food” may certainly not rank high on some theoretical prioritizing inventory, but if that’s what’s pulling on you the most, in the moment, then handling it in some way would be Job One. Once you handle what has your attention, it frees you up to notice what really has your attention.

The first thing to do is make sure your action lists are complete.[…]When you’ve finished getting this level of control current, you’ll automatically have a more grounded sense of immediate priorities, which is almost impossible to achieve otherwise.

If, however, you are able to bring [the mind’s] attention to bear appropriately and efficiently to create the optimal triggers for later thinking and action (such as reading an e-mail, then setting a meeting on your calendar to deal with its issue or opportunity), then it gets to relax and rely on the automatic and elegant thinking it can do when presented specific things on which to focus, in the proper context.

6 Likes

Well put. That’s certainly how I’ve always understood it.

1 Like

It might be coming from a couple of other guys, taking over GTD, and spinning around that their “own system”.
And to sell those “system” as well, you have to put certain points up, where the original is “not working”.

2 Likes

This is an important base of GTD, so yes, I think you might have missed it… :thinking:

David Allen not even has a 3 month horizon, but also one for (roughly) one year, for a longer period of time, and even about your meaning of life!
He calls it the 6 Horizons of focus (sometimes also referred to as “FlightLevels”.

And to be honest, what I don’t get about your post:
You posted the same link within post #38, so are you reading the links you post by yourself?

Yes, of course I read it, webwalrus makes a lot of good points above, Especially this:

I’ve definitely blocked off time and felt not up to the task in that moment!

So I feel like I’m still using elements of GTD, but the time block planning piece is outside the system described in the book.

I can see that way of thinking. To me it’s a little bit different. I look of it as whether something is essential, an addon, or an outright contradiction.

Let’s say I sit down to make a pot of chili. At some point in the process, chili powder and other spices need to go in the kettle. That’s an “essential”. And you need something to be applying that spice to, typically a meat - although meat substitutes are fine too. That’s another “essential”. Tomatoes, beans, diced onions, bell peppers, etc. are all good addons, and food with them in it would validly be called “chili” to most people.

But now let’s say I sit down to make another pot of chili, and I throw in the meat, just like in chili. I throw in some tomatoes and onions, just like in chili. But then I dump in some wine, some milk, and a carrot. And I boil up a kettle of pasta. I’m not “making chili” anymore - I’m making bolognese. And if I served that dish as “chili”, people would think I was crazy.

To me, reasonably-complete lists are an “essential” for GTD. The concepts about what goes on a list, what goes on the calendar, etc. are “essential” too. And thus time blocking is an “addon” to GTD in the way you’re using it, because it’s no different than scheduling a meeting with yourself. I mean…heck…DA actively encourages people to time block their Weekly Review - it can’t be too far outside the system. :slight_smile:

But if somebody says “don’t keep lists - just schedule everything in blocks on the calendar”, that’s not GTD anymore - it’s an outright contradiction. :slight_smile:

5 Likes

I have no problem considering it an add on to GTD. I’ve learned a lot from David Allen over the years.

I’m certainly not an expert, but believe GTD is about deciding what to do.
The way you implement what you decided on (time blocking, pomodoro, etc.) is part of execution, which I think is outside GTD. As Allen says in Making it All Work (which I recommend if you haven’t read it. h/t @OogieM for the recommendation.):

GTD is also system-independent, which means that almost any kind of personal organizing structure or software can be used to implement its principles. Because what I teach is actually not a system but a systematic approach, it can be adapted to take advantage of many of the features of software applications that have seldom been used before.

Allen, David. Making It All Work (p. 25). Penguin Publishing Group. Kindle Edition.

(emphasis mine)

I like this diagram from MiAW too:

It converges at the lower right corner, from there, you’re free to implement as you see fit - or faff around :slight_smile:

6 Likes

Late to the party as usual. (With few kids activities for the summer and one child home from university all of a sudden I drive less).

I know David and Mike’s comments about task breakdown sparked controversy. It may not be what David Allen intended. It is what many people implement. (Which isn’t Allen’s fault). Even the next actions strategy can be flawed if the problem in question is far enough up the complexity spectrum (see below). If a problem is Complex - we should ask have I done enough on this item. If it is Chaotic the question might be have I stabilized the system. I wonder how many mis-applied GTD implementations boil down to enough thought about problem type.

Warning - partly in response to @MacSparky and @mikeschmitz comments I wrote an article on a sensemaking framework with an impossible name. This is a bit long for Discourse. Sorry:

Without knowing it, we encounter complexity whenever we’re asked to estimate how long it will take to fix a bug. Or we’re asked how long will take to bring a novel product to market. We don’t know we can’t know.

This is where Cynefin helps. Unfortunately, this theory has a complicated description. Cynefin is a poorly named mental model to help us see that different kinds of problems need different approaches. The word Cynefin is the Welsh word for habitat and is pronounced: kuh-NEV-in. (It took me several years to learn to say it, so you’re in good company if you’re confused.)

Its creator David Snowden calls it a Sensemaking tool, i.e. a tool to help you understand which domain your current problem lies in and what actions to take based on that fact.

That’s a fancy picture with a lot of words.

Clear Domain: (this was formerly called Simple/Obvious). In the world of software development implementing an algorithm that has an existing recipe is an example. Outside of software, it is any activity that is well understood or that you can find a recipe for.

It was Clear what the outcome would be from the start, implementation is a matter of execution. If asked you could have written down the steps involved in the work beforehand. With a high degree of predictability, Estimation is practical and the approach of estimating in terms of hours/days will be more effective.

In the Clear Domain write down the plan and execute it, things will probably go according to plan

Complicated Domain: In the world of software implementing a new feature with at least some acceptance criteria. Or building a new product in an area where the rough needs have already been understood. Outside of software, it is something that someone has done before, you know the problem is solvable, but you don’t necessarily know what the solution is.

From the starting point, you can see the rough end state. You couldn’t write the steps it would take to get to the destination, because they weren’t all known and the destination moved a few times along the way. As the destination and the individual work items aren’t as well understood, the work is less predictable. Relative Estimation, i.e. Planning Poker can be used as a tool to help people sense the volume of work and get a rough idea of which items are bigger or smaller. We often get requests to teams with more accurate estimation, in this domain that is simply impossible.

In the Complicated Domain, create a rough plan, start executing and adapt. In Product Development this is the classical use of Scrum.

Complex Domain: Both our bug and creating a novel product are in the complex domain. When we start they’re ill-understood. No one has solved this bug before. No one has built this type of product before. Outside of software, writing a book in an area that we don’t know well is an example. We don’t know if we can find enough information to describe the area well or even if the area is well understood.

From the starting point, we don’t see anything with clarity. Complexity can stem from the number of variables that affect our problem, the number of sources of information, or worse the number of completely unknown things. In this environment, we have very little predictability. Estimation in this domain is a waste, more useful is to time box an activity, saying “We will for some number of hours or days and see how far we get or what we learned.”

In a Complex Domain: run an experiment, and see what it tells you. When working on a bug, it may now be Clear or Complicated. When doing Product Development work, the experiment will tell us what problem our audience wants to be solved. As the problem is narrowed we can shift to normal Product Development work (i.e. the Complicated Domain). Effectively this describes some of the ideas behind Lean Startup and Lean U/X.

Chaotic Domain: The system we’re part of is off the rails. In the world of software development, this might be a key service that is offline. In the world outside of software, examples might include an oil pipeline that has burst and is leaking.

In a Chaotic Domain: take action and contain the problem. Chaos requires novel solutions and is typically transitory. Once the problem is contained, we want to move the problem to another domain i.e. Complex or Complicated.

Confused Domain: (Formerly called Disordered) We don’t know where we are.

Our job in this domain is to gather just enough information to sense which domain our problem is actually in and then act from there.

Cynefin doesn’t solve any problem for you, it is instead a “lens” to look at the world through. It helps you sense where you’re at with a problem and then make better decisions.

The version of this in our glossary: Complexity and the Cynefin Framework | Agile Pain Relief Consulting has links out to other sources on Cynefin.

4 Likes