Notes on Productivity Home Page

Should we really use the delegated task feature to delegate actions to others?

While many people are usually excited to learn that their action management system will allow them to delegate actions to someone else, I find that many who have actually worked with such a system do not often share the same enthusiasm.

I usually recommend that my clients avoid using the task delegation feature of their action management system-- at least until I can confirm that everyone is on the same page in terms of how they will use it.

In order for delegated tasks to work, a high level of trust and an "action delegation protocol" must exist between all parties.

The person doing the delegating needs to trust that when he delegates something to another, it will be seen and actually treated as an action by the assignee. Likewise, the person who receives the delegated action must have a way to become aware of, internalize, and "accept" the action as their own. Successful delegation requires trust and commitment. If either is not present (as is often the case) then delegated tasks won't work.

This is not a new problem, it's as old as paper, at least. Technology has just made it easier to quickly dispatch a barrage of computer-delegated actions to unsuspecting (and possibly unwilling) people.

Delegated tasks create a situation in which the technology of productivity is likely to clash with the methodology of productivity.

The technology allows for tasks to be created and assigned to other individuals; however, without a sound methodology  and clear agreement on how these will be processed, (the action delegation protocol), it can quickly become a recipe for lost or missed actions, frustration, and incompletion.

I recommend that my clients use David Allen's GTD methodology. In of my years of consulting on technology, I've not found a better system for thinking about your work than GTD. In his book, Getting Things Done, David emphasizes the importance of accountability in all aspects of delegating and accepting actions; he also makes it clear that the system used to track actions - be it paper or digital - must be absolutely leak-proof. These are two areas where delegated actions, if not used properly, can fall apart as a tool for organizational action management.

Microsoft Outlook, Lotus Notes, and even my eProductivity software all allow for tasks to be delegated to others simply by selecting the assignee from a directory. The beauty of this - at least from the perspective of the one doing the delegating - is that it is easy to create a project and then delegate actions to others.

One of my first action management systems, which I designed for the US Navy, did just this. The manager could initiate a project and then define and delegate specific actions to others in succession. Next actions could be queued so that as one action was completed the next would be delegated out in sequence. The system was a success, but I suspect that a large measure of this success was because the actions were effectively "orders" on the part of the manager and it was clearly understood that they were to be followed as assigned. The trust and protocol that I mentioned earlier were part of the environment. In a closed-system, with a clear chain of command, action management can, and indeed in some cases must work this way. That was almost 20 years ago. Today, a person is as likely to collaborate with someone in their own office as they are with someone  around the world. The relationship is less likely to be superior/subordinate, as with my Navy client, and more likely to be peer to peer. In this situation trust and protocol are essential.

The benefits of a delegated-tasks system can be significant. For the one doing the delegating, as tasks are entered into the system, they can delegate an action to someone else simply by indicating their name in the "assigned to" field. They can also can provide optional information such as a due date, status and alert notification request.

Outlook task delegation fields:


Lotus Notes task delegation fields:



For the assignee, they do not have to enter anything into their action tracking system - it's all done for them. Depending upon how their system is configured, they may have the ability to accept or reject assigned tasks first or the new tasks may simply appear on their to do list. Both Microsoft Outlook and Lotus Notes will display a list of delegated tasks, the responsible party, due date, and status.  For these reasons it is often quite tempting to use delegated tasks in the hopes of having a system of "total control and accountability."

Key things to consider when using delegated tasks:

1. Discuss delegated actions with your collaboration partners:
Will you use computer-delegated tasks at all? Will you allow others to add actions directly to your action support lists (risky) or will you use the propose/accept model (better) for delegated actions? What kind of feedback will be exchanged about the actions? What should be done when changes are required on either side?

2. Make sure that you understand how delegated tasks work:
Who "owns" the task? Will your system automatically place an action item on the assignee's to do list? How will they become aware of the new action? Do they have to accept it to make it their own? What is the process for delegating a task to someone and what happens when you (or they) cancel or change a task? Can a delegated task be delegated to someone else? How will you track these delegated items?

3. Make sure that everyone else understands this as well:
Simply having good technology in place will not necessarily make a team more productive. Sometimes it even leads to just the opposite. It is important, therefore, to have procedures and protocols in place for putting technology to work. My clients have found that training and coaching can make a big difference in the productive benefits they receive from their technology investment.

4. Have everyone practice delegating/accepting/declining actions:
Practice, practice, practice. As I've said before, in order for delegated actions to work at all, there must be a high level of trust - not only among the people but in their support systems as well.


Are delegated tasks simply a bad idea?

I don't think so, but I do think they can be very dangerous if not used properly. When used correctly, by a group of people, who have agreed upon a specific task delegation protocol, delegated tasks can be a powerful productivity tool. Unfortunately, more often than not, this agreement is not in place, and for this group of people, computer delegated-tasks can quickly lead to a lack of trust in systems and turn into a digital nightmare.

As I show clients how to use technology in support of the GTD methodology I find that few are really ready or need to use delegated actions. I usually coach these people to avoid using computer delegated actions and to use traditional  means, such as e-mail, phone or even paper as a way of exchanging information about tasks without entering actions directly into someone else' system. This way, each party can internalize the next action and their commitment to it, placing it on their own list as appropriate.

Is your organization using computer-delegated tasks? If so, how has it worked (or not worked) out?

I would like to hear about your experience.

Please post a comment (or send me an email) and let me know what you think!


This blog post is a transcript from last week's podcast on delegated tasks management.

Note:  For purposes of this discussion, when I refer to delegated tasks, I am specifically referring to the ability to create a task (an action) in a digital system such as Outlook or Lotus Notes, and to assign it to another individual, so that it will automatically end up on their action list.  

(c) Eric Mack 2005