Since this is an audio course I can appreciate concepts that aren't always easy to visualise. When you are able, do a google image search for ‘GTD workflow’. Perhaps even listen to this lesson once and then a second time with the chart in front of you. That will provide a reference diagram for what I’m about to describe.
I should point out this might sound convoluted to start with. But as you gain familiarity with the steps, they will only take you a few seconds each to do. And the payoff to your productivity will be huge, I promise.
Everything Starts with ‘Stuff’
Whether or not you have the diagram in front of you, the first step is ‘stuff’ appearing in your digital inbox. This is just like a physical inbox – something has been recognised as relevant to you, but it’s not been processed yet.
When you periodically scan your inbox, you look at an item in there and ask ‘what is it?’. Think of this part like a policeman directing traffic. There are two broad directions you can be sent. One direction if your item is actionable, the other if it is not. Let’s start with the material that is not actionable.
Non Actionable ‘Stuff’
When we determine there is not an action associated with the item, there are only 3 possibilities.
It’s not important, we can delete it. For arguments sake an email about a product I’m not interested in evaluating at work. Straight to the trash, thanks very much.
The next possibility is reference material. There’s no ‘action’ on configuration files or credentials that I’m sent, but I will need them later to carry something else. These get filed separately as supporting materials. They don't, however, introduce any work of their own.
Finally there is stuff that is not actionable right now. Maybe I’m interested in doing some certification courses, but the timing isn’t great right now. I don’t want to lose the idea altogether, but I don't want it distracting me from the day job. I classify this as ‘someday/maybe’ and review it some other time (maybe). It’s stored safely for retrieval whenever I want, but it’s filtered out of my ‘day to day’ view.
This last point is especially important. It’s a waste of effort to scan the same items again and again, when they’re not contributing to moving your work forwards. Developers are always time poor, so reduce cognitive load by filtering irrelevant tasks. You know where to find what you need if priorities change.
Now let’s say the traffic cop (sorry I’m going with this analogy) has sent you in the other direction. The item is actionable. We’ll deal with that next.
Dealing with Actionable Stuff
Once we’ve decided there is something to with this item, the alchemy begins! The magic question “What’s the next action?” will become part of your life from now on.
The first thing we do with an actionable item is looking at the bigger picture. Does this item belong to a larger piece of work? If yes, then it belongs to what is known as a project. This needs a little explanation so let’s dive in.
GTD Projects and Tasks
In GTD, a project is anything that takes more than one step to complete. It’s not like an IT project with budgets, people thrown at it, stakeholders, etc. It’s just something that relates to a bigger piece of work, that takes more than one step.
For example at work, I am assisting in the uplift of 40 assets into Docker containers. Each of those assets will require documentation, testing, uplifting, deploying, etc. That’s 40 different projects on my radar, with a series of tasks that moves each closer to completion. But I’m not overwhelmed because I don’t look at the details for any project I’m not interested in right now. The projects give me a broad landscape, but I only look at the details when I need to.
The counterpart to the GTD project is the task. When a task belongs to a project it can be sorted and ranked, but most importantly it’s one atomic unit. If you have 5 tasks to complete out of a project, you can say it’s 20,40,60,80 percent done. If something is one huge task, you can only say done or not done. Visibility is a great thing for your peace of mind.
If you’ve ever broken out a story on an Agile wall to show true progress, then understand the benefit here. If something is broken out, then each part has its own identifiable status.
Tasks can be standalone too, not belonging to any project. I have a weekly task to complete my timesheet, but it’s not contributing to anything larger (other than ensuring I get paid). The important thing to note is that ‘doing’ only relates to a task, regardless of whether it belongs to a project or not. The process of doing this is what we’ll cover next.
GTD ‘Doing’
Once you identify something as a task we have three choices:
- If it’s less than 2 minutes, do it now. If it is something for someone else to do, then you delegate it.
- Anything else, defer it, even if you’re going to do it today.
But wait, what? Defer something if you’re doing it today? Why?
Because we’re trying to batch our workflows. Context switching is the kryptonite to productivity. We want to have one sweep of categorizing, and others for doing. Let’s look at the flows in a little more detail.
Do It
The magic 2 minute rule is at play here. This one is from David Allen himself. It will take more time and effort to classify something in your system and come back to it later. I know I said the capture process should only take a few seconds per item, but you also have to get your ‘thread’ back when you pick up work. So if something is that easy, just do it now.
The only exception here would be something that I couldn't do now. It’s trivial to take something out of the freezer for defrosting, so I should just do that immediately. But if I get the idea when I’m at work, I can’t do anything until I get home. And I don’t want to lose the idea, so that would still get entered into my system.
Delegate It
When you rely on others to carry something out, you need to delegate the work. Delegation has nothing to do with your authority by the way. If I ask my boss when we should have our appraisal meeting, I can’t tell him when to do that. But I do need a way of flagging in my system that I have initiated some action that relies on him, and it’s out of my control for now.
The concept of ‘waiting for’ exists in GTD for precisely this reason. In OmniFocus, my tool of choice at work, I tag items that are waiting so I have one view of all my dependencies on other people. Periodically I scan these and chase them up where needed.
Defer It
We’re in the home stretch now! When we defer items we have one final decision to make. Is the item constrained to a specific date or time, or not? Anything that is locked to a date or time goes into your calendar. Anything that is not is simply a ‘next action’.
It’s really important to treat the calendar as your sacred territory. Something put in the calendar must have significance. If you start putting ‘intentions’ into your calendar, the lines get blurred between what ‘must’ and what ‘should’ happen today. Forget project deadlines, or what you intend to do for the day. Your calendar shapes your day's commitment, and everything else is a lesser priority to this.
If this is a bit confusing, think of it this way. For this_ specific task, _is it still possible to complete it outside of this time and date window? For a dentist appointment, the answer is obviously no. Likewise, if I do my timesheet on Thursday or Saturday, it’s either incomplete or too late. I can’t start before or after.
On the other hand, you might well have an action to complete by the end of the week. But theoretically, you can start that on Tuesday night or Friday morning. There’s a deadline sure, but you have given yourself flexibility when to start. This is just the next action. Optionally, the next action may be part of a larger project, as we’ve previously discussed.
There was a lot covered in these workflows and it might seem a bit confusing. That’s why in the next lesson we’ll flesh it out by walking through some real examples. With some context and specifics it will make a lot more sense.
I’ll talk you through a typical developer day using GTD in the next lesson.
