One confusing aspect of Bit Literacy is a contradiction that I found in the discussion around ToDo’s: the book calls for scalable solutions, while in the same chapter it describes 2 solutions that seem to ignore that sound advice, because they scale well.
The author makes the point that many emails create the need to engage in future action, and make future commitments. In Bit Literacy, these are called “Todos” and they seem to be equivalent to what we call “time demands” here in the 2Time system.
Bit Literacy advocates assigning Todo’s to future days, and offers a software service to help get this done. For example, an action item such as “call purchasing department” would be designated for Friday, and added to a list of actions for that day.
Neither the software, nor this approach scale well, but for quite different reasons.
First the software.
As a web-based service, it allows a user to send him/herself an email which the program converts into a todo that will be displayed only on a particular day.
It’s a neat idea, but for people who don’t have access to portable email devices, it’s hardly one that can be used unless the user has a desk job.
The good news is in a few years I can imagine that the software will be available to use all, and that we’ll enjoy access to email through devices as small as a watch. While it’s easy to see this happening in the future, it’s not something that is very widespread today, as only a few million people worldwide own these devices.
The bigger issue is that time demands, or todo’s, (especially in a setting like a meeting) tend to arrive faster than they can be converted into email in the average group conversation. The same applies to ideas being generated from a brainstorming session.
The use of an electronic device as a Capture Point is a neat trick, but it doesn’t scale well as the number of items increases. In my experience, I have sometimes have difficulty writing down all the action items from a meeting, even when I am using only a pad and pen.
More important is the critical decision that must be made in the heat of the moment — “What day should I assign the item to?” That is a decision that requires some reflection, especially for those who have busy days with little slack time.
As an example of where this system doesn’t scale well, let’s look at a typical todo assignment that’s made in the heat of the moment.
Imagine for a minute a typical meeting of 5 people; the kind that occurs every day in the corporate world.
At the beginning of the meeting, the convenor might announce that there will be a follow-up meeting on a day that is convenient for all attendees for one hour. Using the Bit Literacy system, users must go to their mental calendar to determine whether or not there is time on Friday the 17th to attend the meeting, given the todos they have assigned to that day.
However, whether they consult a mental list or electronic list is not the most difficult part. They must make a spur of the moment estimate of the time it takes to do each todo, and then they must calculate the available time. They must take into account the amount of time each item takes, and consult their mental schedule to see if they have any spare time.
This is not a problem when there are only 2 small todos assigned to Friday the 17th. On a small scale, this can work well.
However, when I have 9 or 20 or 50 todos for that day, I have a problem.
The calculations about whether or not I can meet on that day for 60 minutes are, at some point, going to give me a headache. The level of headache depends on the number of todo’s, the nature of the items and our own idiosyncrasies.
Bouncing Todo’s from one day to another only works if there are days that are relatively free of todo’s in the required time frame.
At the end of it, we all have our individual level of tolerance, and the approach described by Bit Literacy becomes a problem once that level is attained.
Bit Literacy implies that the answer is not to hide from odo’s, but instead to employ a system that will allow for a greater capacity to deal with these todo’s.
This very much echoes the approach taken in this blog, in which the the answer might be given in this form: move from a Yellow to Orange Belt in the practice of scheduling.
[email_link]