A New Paradigm for Time Demands

Those of us who are older (over 40) have a hard time escaping the To-Do-on-paper mentality in favor of time-demand-in-the-cloud thinking.

In the old days, when you had something to do you added it to a list using a pen or pencil.  That piece of paper/list was the point of storage for what we now call “time demands” here at 2Time Labs.

Nowadays, that same item might be stored in any number of places instead of a paper list, such as:

  • a tweet
  • a comment on Pinterest
  • an email message
  • an instant message
  • a voicemail
  • a page on Facebook
  • a text message
  • a recommendation request on Linkedin
  • an attachment sent to your iPhone
…plus many others.

On the upside, the increasing number of electronic storage locations means that some stuff will be backed up and safe from being lost.  The downside is that we often get confused if we don’t make the jump to understand the nature of time demands, and why we need to think of them as residing in the cloud.

To start off, a time demand is an individual commitment to complete an action in the future.  It’s a mental creation, and it ceases to exist once the action is completed.  Also, like physical objects in space, time demands accumulate in the mind, and create problems when their number exceeds a certain threshold.

An email that arrives in your Inbox may contain several time demands, depending on its nature.  Once that email is read for the first time, it’s disposed of in a number of ways based on your methods.  It can be:

  • stored in your Inbox, while the time demands are committed to memory
  • deleted after the time demands can be placed on a list or schedule
  • placed in an email folder for later view
  • printed on paper and added to a To-Do manila folder

We make the mistake of focusing on the object, like an email message, instead of the time demands which it includes.  Email messages, text messages, meeting minutes, tweets, etc. are all variations of the same thing:  containers or transmitters for time demands, much in the way that a mango skin is the the container for its pulp.  (It’s mango season here in Jamaica as you can probably tell!)

When we try to “reduce the number of emails” we get each day we are barking up the wrong tree.  5000 email messages per day are not a problem if 4999 are spam.  One email can contain 150 time demands.

Once we focus on time demands, it’s not hard to think of them as being stored in the cloud, and all we need is access to the handful we need at any time in order to do our jobs and make decisions.  If the number is quite small, we can even manage them in their entirety, as a group.

Once the number grows, however, we get overwhelmed, and try to find ways to cut down the need to be looking at too many all at once.

The first attempt people make is to migrate from one single list to many lists.  This helps a bit, and the technique works as long as the number of time demands remains below a threshold.  What’s important to note is that a list or sub-list is just a particular view of all the time demands that exist.  It might be a view of the tasks to do in the office, those that are urgent, those that require big commitments of time, etc.

When a user upgrades to a schedule, it’s an attempt to shield oneself from the onslaught of all the time demands at once, as they are spaced out over time.  Once again, the schedule is just a particular way of looking at all the time demands that are in the cloud.  It’s a more robust tool than a simple list; the fact is, a schedule is just a list enhanced with dates and durations, and sorted by the former.

In other words, it’s also a view of all the time demands that you need to complete. It requires more time to set it up, and more time to maintain, but much less time to review than simple lists when the number of time demands is below a certain threshold.

No single approach is better than others but it’s important that professionals understand that they have a choice, and that there is likely to be stress if their approach is not a sufficiently robust one.