Humans seeking to gain control over their lives love to use time and dates as a planning mechanism.

Everyone is preoccupied with “When”.

But the only “when” is right now because you only have one “now” and “now” is the only time that you can take action.

The only question your prioritisation system should answer is “What will I work on now?” and it needs to do it quickly and effortlessly enough that you always have time to do it even when you’re REALLY REALLY BUSY.


When you add due dates to tasks (or put them in your calendar) you’re mostly just using them as a clumsy ranking system and diluting their effectiveness in the process.

Time is, after all, linear. Saying I will work on one task tomorrow and another task the day after that is identical to assigning them a number in a hierarchical list…

Except when you’re not.

Because some things have REAL due dates. When you’re adding due dates to things as a means of prioritisation, and sometimes adding due dates to indicate actual real life deadlines, you have 2 meanings for things being due, one that you can ignore, the other you can’t ignore.

The danger is that you might develop a “blind spot” for the important due dates because you become so used to ignoring the “fake” due dates.

You’re also going to run up against an interface problem.

Managing due dates is slow, it’s demoralising, and takes too long to answer the right question.

Most task management systems have some due date mechanism and/or calendar view, and in all cases adding a due date to a task is a means of increasing its priority.

When working with a calendar or other date based system, things that you planned to do yesterday but didn’t get done are now in the past (when nothing can possibly get done) and there will come a time when you forget to move something that you didn’t do. And then it won’t get done. This is called “slipping through the cracks,” and you want to minimise the potential for that to happen.

Most task systems emulate this “calendar-like” behaviour in that they will automatically de-prioritise overdue tasks or at least allow them to aggregate in the past (although some have a “due date rollover” feature”). The reasoning behind this seems logical: after all if you allow incomplete tasks from the past to distract your future tasks then those tasks, too will be late and so on.

The reality, though, is that you can’t just leave overdue tasks overdue assuming that whatever is scheduled to happen now is more important. There are many times when a task planned for, but not finished, yesterday needs to be completed today.

So in any due date based system what ends up happening is that you need to spend time moving tasks that you haven’t completed into the future.

But time is a finite box. You can’t just move them to tomorrow because you already had stuff planned for tomorrow, what will happen to tomorrow’s stuff? All that will happen is that you’ll not get everything done and end up moving all that stuff to the next day and so on, so you spend time shifting what you had on tomorrow to later on and so forth.

Due date and schedule based planning has a chronic problem of overestimation of your own capacity and the administrative overhead of moving these things around accumulates so that it takes longer and longer to manage, the longer you have been running the system, until the administration of the system takes up too much time.


I find the same thing to be true with the “scheduled review system” advocated by David Allen in Getting Things Done. You can schedule the review time all you like, but if it’s not a priority, it won’t get done and when that system starts to crumble, and your trust falters, you’re back to reacting to whatever interruption yells at you the loudest.

Blocking time off in your calendar is good for avoiding automatically scheduled meetings or telling your team when you’re busy doing something else, but lousy for scheduling your work because sometimes you just don’t feel like doing whatever it was you planned to do at the time you planned to do it.

The problem with all of these things is that they’re just different interfaces to achieve the same outcome.

What you really want to do most of the time is pick the 3 things that are most critical and sweep everything else (digitally) off your desk onto the floor so you can pick through it later. These things need to be “out of sight out of mind” until it’s time to pick something to work on again.

You don’t need due dates, but it just so happens that in most to-do list, task or project management systems using due dates is the most convenient way to create a series of to-do lists of decreasing priority.

This avoids the problem of having to “prioritise” a seemingly infinite list of 100s or 1000s of tasks in a big, single list. The task of prioritising this list is just as time consuming and depressing as moving overdue tasks around in a calendar or due date based scheduling system.

What usually ensues after all this tangled mess of due dates and priorities and ordering and tagging as high priority or low priority or next actions or whatever system you care to implement is that the overhead of managing that system builds up so much that you end up having to declare “task bankruptcy” (a paraphrase of Sherry Turkle’s “email bankruptcy”), or worse still that you leave the system in its broken, messy state and just start operating in some parallel way working around it.


The problem with both a monolithic, prioritisable list of tasks and due dates is that they force us to figure things out that are not relevant to the question “What should I work on now?”.

You can only work on one thing, so the order in which subsequent tasks are prioritised is irrelevant, just as the task on which you will work next Friday is irrelevant.

Most of us aren’t dealing with 100s of tasks, maybe even 1000s of tasks if you take into account all those things we’d just love to do if we had the time.

So really we don’t want a way to “prioritise” a list of 1000 things. We don’t care which task ranks 680th out of 1000, we just want a way to pick the one thing out of those 1000 tasks that we should work on now.

The mechanism for selecting one option out of a list of many is called a “shortlist”.

Everyone is familiar with the concept of a shortlist. If you were asked to pick 1 person to hire from a list of 500 applicants, or 1 person to marry out of 400 potential partners, or which movie you would like to watch on family movie night, you would follow the process of assembling a shortlist of your favourites and excluding everything you didn’t want until you ended up with your decision.

What we need is a system that allows us to reliably answer the question “What should I work on now?” with the minimum of administrative overhead whilst ensuring we never let anything slip through the cracks.


The system that allows us to create a shortlist of potential tasks with the minimum amount of administrative overhead is one that allows us to manage the frequency with which each task might be considered for the shortlist.

If you imagine a list of 1000 potential tasks, it might take you 30 minutes to go through and pick out a shortlist of 100 that you might like to work on, then it might take you another 5 minutes to pick the top 10 out of that 100, then a couple of seconds to choose from those 10 and so on.

The obvious choice would be to pick from the 10 you already shortlisted UNLESS that task took you all day. What if your priorities have changed? What if there is new context, new communication, or your emotional or mental state has changed?

If you were only going to choose one task out of 1000 to work on for the entire year, it would be acceptable to go through the entire list of 1000 again next year. The 30 minutes of time it takes to go through the list is a negligible component of the total task time.

Some tasks on our lists, though, only take minutes to complete. If you were to go through the entire list of 1000 after each and every task you completed every day, the process of creating your shortlist would dominate your work time.

This indicates that our shortlists have a shelf life.

There must, therefore, be a time component to your shortlists. This isn’t the same as “due dates” or “start dates”, but rather a notion that everything on a given shortlist will be reviewed again at some time in the future, with an equal opportunity to take priority.

If you went through a list of 1000 tasks that you might work on, and chose 100 for a shortlist, you might want to put the remaining 900 into a list that will be considered again in 2 months’ time.

This means that the overhead of sifting through those 900 tasks won’t take up an appreciable amount of your total operational time because the number of hours/minutes/days in 2 months is much more than the 30 minutes it takes you to run through a list this size and create a new shortlist.

Now you have your shortlist of 100 tasks. You might pick out a shortlist of 10 that you might work on and leave the remaining 90 in a list to be considered again next week.

Then you pick your most important and leave the remaining 9 in a list for immediate consideration after you have finished the current task.

But you don’t need to place those 9 tasks in order. It doesn’t matter which task is 6th most important, because once you finish your current task things may have changed anyway and picking your priority out of a list of 9 things just isn’t that difficult. If you really found it difficult you could create another shortlist of 3 things and stick the remaining 6 into a list to be considered again tomorrow.

As new tasks arrive, they need to either take priority or be put into the list for consideration at some point in the future.


The system of shortlisting tasks I’ve just described is what I call “BenkoZero”, an evolution of GTD/Inbox Zero.

But what might an implementation of this look like?

Trello is, hands down, the best tool for sorting out a massive list of competing priorities into a series of shortlists.

The most important thing is that your “shortlisting” process should result in a list that is so short you can easily pick the thing you should work on now.