Email sucks and should be replaced with a combined task queue and instant messaging system. But these systems also lend themselves to management predation by encouraging more metrics and more tracking. Whatever replaces email must solve its usability problem while protecting workers from tracking. What follows are some thoughts on how a task queuing system could work, plus a few ideas for where the system needs work to protect workers.
Users may compose and send task requests. Each request consists of:
- Type. Read, edit, research, calculate, etc. Precise types of tasks can be specified by an organization.
- Content. The task being requested, written in plain text by the sender. The possibility to auto-generate routine content for repeated tasks should be available. May want to see about including some form of hyperlinks/tags to common documents, projects, etc–maintain a dictionary of common references used within the organization that can be auto-detected and tagged in the content boxes.
- Deadline. Date and time by which the task should be complete.
- Priority. An urgency level set by the sender.
- Project. A project this request is associated with, if any.
- Time estimate. Amount of time likely needed to complete the task. This is open to abuse, as it removes quite a bit of worker agency and is susceptible to management gaming through reducing time estimates to get employees fired for performance issues.
Priority may be:
- Hierarchical. The more levels above a given worker the sender is, the higher the priority the sender may attach to the request. Request priority from subordinates may be altered by their bosses.
- Egalitarian. Everyone has the same priority options available to them, and everyone is allocated a certain number of priority modifications per unit of time.
- Deadline-based, possibly combined with the optional time estimate information.
Note that the above priority discussion could be extended into other aspects of the system, such as who gets to accept/decline task requests. Hierarchical is most open to abuse, and deadline-based may be as well if management is willing to cook the numbers.
When a task is sent, it goes into the queue of the acceptor(s). The acceptor(s) may choose to take on the task, may request a modification, or may reject it–all based on the rules established within the organization. Once a task is accepted, it is added to the task hierarchy of the given project, with the acceptor listed as the responsible party. An organization may choose to keep a complete history of all tasks associated with a given project, or they may disappear into the ether after completion. Possibly both, depending on the nature of the tasks/project.
Some tasks are purely self-completed, with the task owner checking them off as complete. Others may require management check-off. Status of tasks include “awaiting acceptance,” “accepted,” “amendment proposed,” “delegated,” “rejected,” and “enqueued.”
Tasks may be delegated, either intact or broken into pieces. If broken into pieces, the onus is on the delegator to break the original task up into appropriate pieces and assign them to others correctly. Some interpretation may be necessary in the case of broader directives from upper management. When a “parent” task is broken, the “child” tasks that it is translated into have links back to the parent, establishing a clear tree of accountability and interpretation.
One can imagine a whole project descending from a single task at the top, with various branches and twigs of sub-components trailing off.
For such a system to succeed, it needs to provide an interface with common email systems. Exactly how to translate external emails into tasks in this system without enormous amounts of labor is an unsolved problem.
This system must also include an instant messaging system, since more detailed discussions obviously must take place in the course of completing tasks. The instant messaging software should not provide information on worker idle time, etc. Video chat and in person meetings would also be necessary, but do not have to form a part of this particular system–there are other options out there.
The option for detailed time monitoring of task completion should be made available to teams that desire it. Note that I said “teams,” not organizations or managers. Every single instance of the application will have the ability to turn on/off time tracking as a user-only (non-admin) privilege. This does not get around the threat to fire an employee for turning off her tracking, though perhaps a single installation could spoof the time reporting by averaging that of other employees on similar/identical tasks and submitting that.
In-built worker protection from management predation and metrics obsession is another unsolved problem.