Get Everything Done

Here's my opinion about the psychology of this problem, and what I've been exploring and succeeding with right now.

I think the significant difference in "efficiency" between executing a large task and a small task comes down to the caching overhead involved in taking a given "unit" of action on that task. Each time you choose to do a task, your brain has to bring in all of the necessary contextual information from long term storage into working memory to generate a plan of action that eventually reaches a point of granularity in your mind that a given motor program can execute on that action. The smaller the task "size", the less likelihood there is of a large amount of contextual information that has to be brought in. In essence, every time you choose to do a task, your brain has to load up and create a fresh plan of action starting from the "save point" that is represented by your task item. The caching overhead comes because certain larger tasks require significantly more "uploading" and "planning" in your mind to get to the action before you can take action. This slows down your mental efficiency and consumes literally more energy.

The problem with something like GTD with its horizons of focus and the like, as Mark H points out, is that if you a priori decide on a set "granularity" level, you're assuming a uniform overhead and cost mentally for every type of project and action that occurs, and assuming that an external organizational structure will eliminate those overheads, while introducing less external overhead. I don't think that this is the case. Your mind is very good at optimizing certain paths, particularly those that are routine or "well understood." In such cases, you are more mentally efficient at ramping up to action and the mental overhead involved in taking action on that thing is less. But this changes not only between people but it also changes throughout one's life from day or day or hour to hour in how mentally efficient you might be.

This is one of the advantages of Mark F's approach to listing tasks. Instead of forcing a strong external organizational hierarchy that incurs a constant amount of external overhead in the hopes that it will eliminate enough internal overheads to be efficient, you are given the freedom to list things at any granularity level, and you instead work whatever system you are using to guide you to more clarity about a given task, which will manifest in the list in one form or another.

As you train your intuition on this stuff, what I notice is that some projects or large tasks represent large overheads that are resistant to "routinization" and other large tasks naturally tend to routinize over time. The tasks that resist routinization are the same tasks that are likely to manifest reduced efficiency when entered at the larger level of granularity.

IMO, the trick here is that I think as you train your intuition, you can learn to "feel" this overhead hitting you with a given project. You can sort of feel when a project is taking more mental energy and work to spool up. When that happens, the "little and often" part of the workflow becomes externalizing that spooling, caching, and planning that your mind has to do back into your list in a way that will divide the project up into a set of actions that are usually more granular, clear, concrete, and, importantly for me, relatively independent from a "mental space" point of view.

The key insight for me is personally recognizing in my mind that you have already accomplished and done something by having broken this down. You have "worked" on that project by doing this. A lot of people will look at a big project and feel like they haven't taken action on it until they've "done" something visible. But in more complex projects, simply the act of separating out the various parts that you have to take action on and putting them down into steps or independent actions represents meaningful work if it removes the need for you to think about that process again each time you want to work on the project. You've applied little and often at that point.

My experience has been that if I do this, if I feel like I've completely broken down the entire project sufficiently, then I can just cross that project off the list and work from the smaller tasks. I find that then it's *much* easier and faster to take action on those tasks, and I work them "in system" rather than "out of system" like you might imagine is happening in your head when you just work off of a single large task in your list.

So, the thing I do, in principle, is to listen to my intuition and how I feel about a task as I'm working on it, and if I sense an ease or "boring" routinization about it, then I will leave it as a larger task and just do a little routine work on it and move forward (such as email or cleaning the office), whereas if I start to feel that my mind is working hard to think about a lot of interdependent requirements or the like in order to start taking action on a single piece (there's multiple levels or abstractions in the project), then I will stop trying to take immediate action on things (which might lead to procrastination/resistance) and instead take the time to write out all of the work that my mind has already done on the project to figure out what needs to be done, so that I've reified my mind's mental map and no longer need to recreate it on the fly each time I want to work on it.

I think this two prong approach is the key to dealing with resistance. I think in this case, there's resistance because of a lack of clarity and resistance because of a sense of tedium. By using this two pronged approach driven by intuition, you drive down in granularity as far as you need to gain enough clarity and concreteness to eliminate resistance, but you allow your feelings and intuition to stop you before you start going so far down the granularity chain that you end up reaching a point of mental tedium.

This balancing of tedium and clarity is very dynamic and flexible in Mark F's systems. As long as you are willing to cultivate the habit of introspecting on your feelings and intuition about tasks, you should be able to continue to ride that wave. Basically, that means that I don't feel that I need to over-specify my tasks, but as I start to feel more stuck on a task, I can let myself clarify and get into more detail to ease the pressure on my mind. This avoids the other source of overhead, which is how much organizational work you need to put into your external time management system. Using an intuitive approach like Mark's means that you can potentially be more efficient in your use of external as well as internal resources, but it does take a little more training since you don't have an externalized resource to rely on to decide when to do break something down or whether or not you are doing it right.

Belacqua:

<<But what was disconcerting about my recent time tracking experiment is that *even when actions are routine* and could be entered as a big task, I seem to work faster when I enter small (granular) tasks.>>

I think this goes back to individual personality and mental aptitudes. You may *think* that what you are doing is routine, but is your brain already actually wired for them to be routine? Different people's personalities will exhibit more or less tolerance of uncertainty between action and goal.

Even if you might theoretically work faster with small tasks, there's a point at which the tasks are just going to be too small, and that theoretical efficiency gain will be overwhelmed by other costs, such as resistance to writing things down. Taking a holistic optimization strategy, you'd want to let yourself find that balance point, which is likely going to be different between different types of and even specific projects or tasks. It may be that there is something about, say, "War and Peace" that just imposes more mental burden on you than "War and Peace Ch. 3" and if that burden exceeds the burden of writing down Ch. 3, then it's better to just write down the latter.

There is never a perfect solution, and you'll never actually get the balance perfectly correct, but that's okay, because we all get better at that over time, hopefully.

Hrm, it strikes me that one of the confusing things here might actually be the use of the term "routine." What does "routine" actually mean? In this context, routine for me does *not* mean that the set of actions is a linear sequence of actions that you can describe and map out and say, this follows that. For example, just because reading a book is serial, going from one chapter to the next, for most people, does not mean it is routine. And even though it's easy to *say* what the next chapter is, that also doesn't mean it is routine.

When I think of routine, I would define it as an action that can be triggered efficiently at the level of sub-conscious motor program in the brain. This is often commonly coined "unconscious competence" but I think there are more precise terms used in cognitive science and sports science that map that concept onto the things like the amount of myelin in the brain around neural pathways associated with the execution of a specific motor program, and so forth.

The big difference between consciously knowing how to do something and having something at the level of routine is that a routine is something that is triggered atomically and can be thought of as a single symbolic unit in the brain (somewhat literally). You simply think "I want goal X" and if achieving goal X is a routine, then you just do it, without having to think about anything else. But, for instance, a lot of people consciously know how to read, but the idea of reading is not a routine. It takes a surprising amount of active mental effort to crack open a book and begin reading. For others, reading is such a routine that is just happens without any real conscious effort. Take a large project like War and Peace, and you might have quite a lot going on emotionally and psychologically even though you "know" the next step. The difference is whether you can trigger a motor program to automatically read War and Peace without significant conscious effort into the planning activity of executing that motor program.

Thus, for me at least, routine as a concept is not about the structure of the execution plan needed to do the task, but where that execution plan lives, the unconscious or conscious mind.

Belacqua:

Do you mind if I probe a little deeper into this issue? It seems that something interesting is going on, but I'm not sure what.

You said originally that you're struggling both with a lack of concentration, which I take to mean that your mind is wandering off to do other things, and also a sense that you are working too slowly on tasks when they are at a high level but if you write them at a low level you feel a lot of resistance to the act of writing the tasks down?

When you talk about resistance, can you describe that feeling in a little more detail? What is happening when you write it down, and can you give me an example of a task that is taking too long as the high level but that you are resisting writing down in more concrete steps?

Belacqua:

Thanks for sharing! I think a few things are making more sense. I certainly don't have the answers, but based on what you're saying, I'm personally drawn to what looks to me like an underdeveloped skill of operationalization and the awareness of "status" when it comes to knowledge work. It sounds like you've been trained at some point in your past to feel a sense of accomplishment around concrete task completion, but you perhaps haven't had as much practice in connecting a sense of completion and achievement to the more nebulous sort of knowledge work you are doing right now. That can make *everything* slow down because it can be very hard to tell if you are going in the right direction, and thus, each step you take can take longer than it would if you were just following the path that was laid out ahead of time.

Here's a few things that I can think of that might help this:

1. Let yourself be slow. Seriously. I think expecting yourself to have the efficiency you did with the sort of "menial" work you had before is expecting more than anybody can reasonably expect of themselves. Knowledge work is inherently slower, especially any *valuable* knowledge work. Knowledge work that is already routine isn't very valuable knowledge work. What makes knowledge work valuable is that it is delivering new knowledge of some kind, which ideally shouldn't be already known knowledge. The more routine knowledge work becomes, the less valuable it is and the more it is just inefficient automation. So, of course, you shouldn't expect efficiency like you had before. If you're doing good work, then the work should be inherently more challenging and/or difficult.

Along with this, knowledge work of any good sort involves mapping out into unstructured and unknown areas, which means you won't have a plan, and you have to create it. You shouldn't expect yourself to be as fast as both developing a plan and executing that plan as when all you have is a predefined plan someone else gives you to execute.

In fact, knowledge work usually involves three things: 1. Identifying what the actual end goal looks like. 2. Mapping some idea of how to get there (usually incrementally while executing). 3. Executing the mapping that you have so far. And importantly, you may need to cycle through all three of these stages repeatedly before you are done, revising all of them. That's a lot more work than just stacking shelves.

People can get really good at this, but it can be hard to see how much skill is involved in getting good at this kind of stuff, so you should let yourself be slower than you might think you ought to be, that might really be okay. You're only going to slow yourself down if you keep worrying about how slow you are going.

2. A key skill to develop is operationalization. That is, the skill of taking an end goal and identifying multiple layers of sub-goals that eventually bottom out into concrete actionable tasks. This is *not* an easy skill that many people have. It takes time and effort to develop that skill. And moreover, a lot of people don't take a very structured approach to honing this skill, so they can be working in knowledge work for a while without ever really making much progress in this skill.

I think one of the things that you might be suffering from is that when you are forced to explicitly operationalize, you are confronted with the challenging aspects of a problem. There are all sorts of unknowns there that you need to resolve, especially if you are trying to actually write something out. You can often fool yourself into thinking that you have a much better map in your head than you really do if you aren't forced to write things down.

I think some of the frustration you might encounter here is that if you think something should be relatively easy, but you've not developed a truly coherent idea of what it means to complete the task that you have, when you ask yourself to write things down more concretely, your mind is saying, "This is a trivial thing, I already know how to do this," but your unconscious mind might be at odds with that, saying, "We really *don't* know how to do this," and you might find encounter resistance at that point, both in terms of writing things down and also figuring out whether you've actually written down the right things or not.

Thus, the points of resistance you encounter to operationalizing your work might be great focal points for you to explore, rather than to remove from your work. Those points of resistance could be highlighting exactly the areas you want to think about or that you're weaker in than you would like to think, and playing in that space might give you the opportunity to level up in those areas.

3. In addition to operationalization, I think one of the more valuable things you might do with these tasks is to take the time to ask yourself why you're doing this, why it matters, and what it would actually look like to deliver a minimal valuable solution. Get the idea in your head what the resolution would ideally look like, and then actually write it out. Have a true idea of what "done" looks like to you. If you're precise about this, and write it out (I don't think you can be concrete and precise here at this point without writing it down until you have *much* more practice), then your mind will be *much* better equipped to figure out the most efficient path forward, as well as to hit you with "stop points" that trigger anxiety around unknowns that you need to home in on and solve. It can lead you to the right sort of questioning.

I think with both #2 and #3 you might encounter resistance to this idea because you might say, "Do I really need to do this?" as well as, "This is a waste of time." But I think that very often, both of these things are lies that our minds tell us to try to leave us in the dark. It's a defense mechanism. If we don't have to write things out and if we don't have to operationalize and define what success looks like, then we aren't forced to confront the parts of the problem or space that we don't know, can't answer, or that might present a significant problem to us. If we avoid concretizing or writing things out, then we can mentally "brush over" those things in our head without feeling too bad. As long as the "dangers are kept in the mists" then we might feel better than if we revealed them to ourselves.

At least, I find that this is very often the root cause of people's reluctance to write things out, especially around knowledge work. If it were routine, then they could write a checklist out once and then refer to it repeatedly. If it's knowledge work, then it requires new paths every time you work through the tasks. I have met many people who implicitly avoid writing things out because they don't want to confront what would happen if they did write things out, such as having to say, "I don't know...."

I think once you get really, really good at writing this stuff out, you'll have internalized the process enough that you "write things out" in your head, and this enables you to avoid needing to write things down on paper. However, that can take a very long time to get good at.

An extreme example of this is in my field of Computer Science, where many people come into this degree and are used to writing papers that aren't clear on an idea. Then, they are asked to write software code on a topic, and they *think* they understand it, and they can even write a paper that they think explains what is going on, but when they are asked to *actually* write out the program code in a way that mechanically tests whether they have understood the concept or not, their code doesn't work, and they struggle to write code that does work. This is an extreme example of thinking you understand the details when you really don't. Not every field requires that level of rigor, but I think the principle tends to stand up regardless of your domain.

Only the *really really really* good programmers are able to write out a piece of code from start to finish without erasing and without making any corrections to their algorithms. Those people are so rare that stories of such feats are a matter of lore and legend in the field. And even those people can only do that with some problems and some domains within programming.

4. I think timing might be a good thing to try, like Mark has mentioned. Another thing you can do is to classify tasks into how "big" you think they are, and then track your average time to completion for each class of task. Then you can start playing with different techniques and see which ones drive down this time from start to finish.