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.