What computers know about GTD

Artificial intelligence has made impressive gains in our time. That said, I am still more excited by the possibilities of the human mind.

In particular, I am interested in how our vast collective investment in thinking about how to train computers to adapt and solve problems can be applied to helping our own selves adapt and improve. In fact, part of why I think the Getting Things Done (GTD) methodology has been revolutionary in helping so many people to work smarter with less stress can be explained by some very simple computer science concepts.

Don’t worry – I promise not to geek out too hard here. You should also instantly recognise these concepts when we look at how they apply to the workplace.

So, if you’re still with me, imagine a big beautiful tree. It travels upward into many branches, getting higher and wider as it goes. Computers often arrange data into trees as well, such as family trees or questions whose possible answers branch off into other questions. Sometimes, the trees exist, but we don’t know what’s there yet, and so the question becomes – how best to navigate the tree and discover what’s there?

The flow of our life and work is a bit of an ‘undiscovered tree’ as well, with each tip representing the successful completion of some project we want to get done. The path along the branches isn’t totally clear, and even when we think we know how it will go, life often has a way of adding knots and kinks along the way.

Many people don’t have any inventory of even the lowest branches of the tree. Instead, actions show up, and they do them, responding from crisis to crisis and whim to whim. It looks a little something like this:

(Note: our tree will be branching downward in these diagrams, as is the convention in computer science, not upward like actual living trees.)

I call this somewhat random approach ‘firefighting’, and it is not only inefficient, but leads to burnout pretty quickly.

Another way computers inventory trees is called ‘depth first‘. This simply means travelling up one branch all the way to the tip, then going back and travelling the next branch all the way up, and so on.

The problem with a depth-first approach is that you are becoming fixated on a single branch to the exclusion of all the others. In the workplace, people likewise sometimes get ‘fixated’ on a single project to the exclusion of all else. It can look like this:

As you can see, there are still a lot of question marks here that could potentially blow up and create stress – both project outcomes and next actions that remain undefined for as long as our little worker program is marching along that single branch. And what if at some point the very next action is to wait for someone to get back to them? If this were a computer program, and we told it that its top priority were to complete this one branch, it might just sit there waiting. Not terribly efficient.

Another approach is ‘breadth first‘. Here, we travel up the trunk only far enough to get an inventory of all the lowest-level branches. Once we’ve done that, we travel up each of those branches until their next junction, getting an inventory of each as we go, and so on.

Taking just the first level of the ‘breadth first’ approach gives us a little more definition we can use to make good choices:

Here we at least have a complete inventory of options by way of very next actions that we could do, but it still might not be terribly clear which one to do next. Projects are not defined at all. It’s better than ‘firefighting’, but we can do better still.

The Getting Things Done methodology essentially combines the best of both worlds – breadth-first and depth-first – into an approach that allows you to be neither fixated nor firefighting, but taking best advantage of both approaches at once.

It looks like this:

As you can see, the first level branches, the next actions, are clearly defined, so we know our options for immediate action. Adding to this, we have also defined the very tips of the branches – those projects and outcomes we are heading toward.

Armed with both, it becomes easier to see that the best next action may be to send this email, then record the ‘waiting-for’ state and move on to the next most important action while waiting for a reply. It allows the little worker in our simulation to move lots of things forward in parallel, eventually reaching all those branch tips and ticking off the project outcomes in an efficient manner. There is no unnecessary waiting, no roll of the dice to pick what’s next, and no ‘hoping it’s right’ while you march down a single path.

So, how about you? Have you ever ‘put the blinders on’ and found yourself racing down one branch of successive actions toward the completion of a project, only to discover that several other avoidable disasters had blown up in the meanwhile? Or have you ever made a to-do list of actions without considering the end state as well, only to find yourself at the end of the day feeling tired, but wondering what you actually accomplished?

Programmers working to make computers perform multiple tasks efficiently know that you need to represent not only what can be worked right away, but what completion looks like as well. One without the other leads to inefficiency and strain.

You need a list of projects. You need a list of next actions. Get both together, get them complete and current, and you’ll be an unstoppable machine.