Why IT Professionals Need to Pay Attention to Time Management

A recent series of 2 articles by Peter Denning in the Communications of the Association for Computing Machinery included many ideas covered by us here at 2Time Labs.

He starts off in Part 1 by saying that many computing professionals have a great challenge with time management and shares their “laments about information overload, about a relentlessly increasing rate of input from Internet and other sources, and about feelings of overwhelm, data drowning, inadequacy and even victimization.”

He argues that we have demanded increased data from our surroundings, but have become no better at using it to make decisions.

In a move familiar with time management fans, he defines “commitment management” as the starting point in a way that’s similar to the definition of “time demand management” here at 2Time Labs.

He goes on to talk about practices that are needed:
1. How to track commitments to their completion.
2. How to choose what commitments to make or decline.
3. How to organize the conversations that lead to the completion of commitments.
4. How to manageme mood and capacity.

From his point of view, the most recent time management books focus on the first practice, but not on the last three.

Some books, like those written by Stephen Covey, talk about the need to make commitments based on one’s personal mission statement. While this works to some degree, I believe that this thinking scratches the surface of what needs to be done by busy professionals who simply won’t pull out a card with a written statement every time they need to make a decision. (In general, Covey’s ideas badly need someone to show people how to convert them into credible, daily action.)

Then, his article takes an interesting tack, as he brings in the Conversations for Action thinking pioneered by Weinograd and Flores in their book, “Understanding Computers and Cognition.” While their ideas are beyond the scope of this article, they are powerful and I have been using them since the mid-1990’s in my daily life and in the odd seminar.

They define commitments as promises that are created between people in conversation – a particular kind of dialog. They are created only after the right context/relationship has been established and an exploratory, visionary conversation has been conducted. The author rightly argues that these activities take time, and are themselves commitments to be managed.

Here at 2Time Labs I define “time demands” a bit differently – to include commitments that aren’t necessarily made to other people, but are made only to oneself. An example is “the need to spend time alone to prepare for a conversation for action.” Also, I would go a step further and assert that all commitments to other people begin in the same place – with a private commitment. Only then can a public request or promise be made.

In his followup paper written with Ritu Raj, the author goes on to define the main problem behind information overload. It’s not the the spam and informational messages that we should be concerned with, but email messages that have commitments / time demands embedded in them, in the form of requests and promises. These are the nuggets of gold that require our greatest attention.

In particular, Dennings singles out the time demands that make up coordination loops – those cycles of promises and requests that Flores and Weinograd explain in their book. Managing these loops is of utmost importance, as they are the essential elements of communication in team environments that drive result production. There are few email programs that are designed to manage these cycles, and none of them are widely used. Most of us are stuck having to imagine these loops, and manage them using our memory.

This is an unsatisfactory state of affairs.

In complex team environments, the author reminds us that setting up a single conference call is an activity that can take dozens of emails. Completing subtasks that involve multiple team members can take even more. New tools are needed to manage coordination loops, and they need to exist inside our email and time management programs. Some do exist, as the author notes, but apparently they aren’t very well known or widely implemented.

One system that I have trialed that takes a step in this direction is called Promisystem, a web app that provides a solid method for managing promises. Unfortunately, it lacks Outlook, Lotus Notes or Apple Mail integration. <Only after writing this article I did I discover OrchestratorMail, created by by Raj’s company.>

The author makes an interesting point in passing: “The conclusion is that, for most of us, most of our time management is really not ‘personal’.”

I take this to mean that when you accept a role in a project team, you are essentially agreeing to undertake certain speech acts (a la John Searle) and to play a specific part in pre-designated commitment loops. The requirements of this role don’t depend on you – your time management skill, your personality, your choices – the individual, but are defined by the team and the requirements of the project.

Obviously, some are more highly skilled than others in this respect, a fact that Dennings alludes to in his claim that people need to be aware of their capacity to undertake commitments. Many people are not aware, nor are they interested in understanding it until they have an acute problem and start failing. At that point, a few do take the course that I advocate here at 2Time Labs – to implement an upgrade to their existing habits, practies and rituals.

Most engage in some combination of complaining about needing an extra hour in the day, or attempts to reduce time demands. Some take extreme action and quit their teams and/or their jobs.

Project managers need to be careful who they appoint to certain roles in terms of their ability to manage time demands and commitment loops. In my training, I give people tools to assess their personal time management skills, awarding them a White, Yellow, Orange or Green Belt depending on their personal assessment.

A team of White Belts (the lowest skill level) would operate very differently from a team of Green Belts. Most project maangers end up with a blend, and can be helped with a certain knowledge of what skill levels potential team members possess before they are added to the team.

It’s a great series of articles, and Part 1 is available here: http://denninginstitute.com/pjd/PUBS/CACMcols/cacmMar11.pdf (Thanks Tom M. for the link.)

Part 2 is available here – ttp://www.cs.gmu.edu/cne/pjd/PUBS/CACMcols/cacmSep11.pdf

Denning, P., Communications of the ACM 543. (Mar 2011) DOI: 10.1145/1897852.1897865
Denning, P., Raj, R. Communications of the ACM 549. (Sep 2011) DOI: 10.1145/1995376.1995388
Winograd, T., and Flores, F. Understanding Computers and Cognition. Addison-Wesley. Reading, MA, 1987.


How a Green Belt Delegates

Delegating is a critical practice for all working professionals, and I’m sometimes asked how a Green Belt should undertake this critical task.

It’s a tricky topic, because Green Belts delegate differently depending on the person to whom the task is being delegated, and the nature of the task.

To illustrate, imagine for a moment that you have two employees, and two tasks.  Task A is a critical item while Task B is not.  Wally White and Greta Green are your two employees, and as their names imply, they are White and Green Belts respectively.

Delegating Task B to Greta Green might not require any action other than the initial conversation, due to the nature of the task and Gret’s reliability.

However, delegating Task A to Wally is a risky business. Like most White Belts, he may decide to commit the item to memory in the hope that he’ll remember to undertake the action at a later time.   The chances are high that he’ll simply forget and the item will fall through the cracks of Wally’s system.

A Green Belt manager who is delegating the item won’t sweat it.  He’ll simply place a segment in his schedule to follow-up with Wally.  It might be the day after the item it delegated, or perhaps a week.  Also, the manager who notices that Wally has not written the item down may also send him an email summarizing the action to be taken.  He’s simply upping the odds that Wally will get the task completed.

The manager understands who he’s dealing with in these two cases, and spends no time lamenting the fact that Wally isn’t more like Greta.  Instead, he works with each person at their current level of skill, and changes his actions accordingly.

This tactic clearly involves a judgment call, as life almost never delivers clear-cut examples like the ones I described above.

Promises – A Productivity Hole

hole-normal_p1010044.jpgI am working on a project that involves multiple promises being made in every direction, and I am struck by an area of my own system for productivity that is underdeveloped.  While it’s not a time management issue, per se, it does appear to be a problem that results in wasted time.

What do you do when someone makes you a promise that you need to make sure they fulfill?

Here are some options I have seen or tried in the past, none of which I am altogether happy with.


Once the initial promise is made, what exactly happens next?  Is it committed to memory, with a hope that things won’t get so crazy that it then gets forgotten?

Or do you send an email to the person (if you can) as a way of putting the promise in writing?

Is it written onto a capture point like a paper pad?

Do the above actions depend on the person who is making the promise and your prior experience?  I have used good Promise Management software to help me in this regard, but it requires proximity to a computer and the intranet.  There may be PDA-based promise management software, but I haven’t found any yet.


Whatever enters a capture point must at some point be removed, in keeping with good time management habits.  A promise is a bit difficult to work with, however, as I can’t see a perfect place to out this particular time demand.

Option A:  After Emptying, add it to a list (Listing)

A user could maintain a list of items that have been promised by others, and track the list frequently to ensure that  no promises are being forgotten.  This action of checking the list would have to be placed in a schedule to ensure that it actually gets reviewed, also.

Option B: After Emptying, place a reminder in a schedule (Scheduling)

Place an item in the schedule that acts as a reminder to expect the item by a particular due date.  The item would also need a reminder for this to work, so that it pops up and interrupts the action at the right moment in time.

Neither of these options are elegant, in my opinion, and I’d love to learn some other alternatives.

This strikes me as a hole in my productivity system, and it’s one that I think many share, and would love to solve.