What's wrong with the to-do list?
I tend to think I'm a somewhat organized person - I like lists, I like planning out my day, and I like the motivation of a clear set of to-dos. Because of that, I am constantly surprised by my inability to stick to one to-do list system. I've tried a gamut of tools - RememberTheMilk, Asana, Todoist, Wunderlist, etc. - and recently I just switched from one low-tech solution (Gmail tasks) to another (pen and notepad, one page each day).
This problem is compounded by the fact that at work, we have tried out a number of tools for project management, which to me feel like to-do lists on a coordinated, group level. After a trial period (aka not much time after we finally imported all of our existing tasks), use of the collective tool inevitably declined quickly over the span of just a couple of weeks.
All of the tools we've tried are established and somewhat popular - tools like Asana, Trello, Pivotal, and even Github's issue system. None have really caught on, and after some reflection I think there are some common reasons why it's hard to adopt a consistent project management or to-do system for the working groups I've been in and for my personal life.
Fundamentally, the success of a task management system comes down to a tradeoff. On one hand, you have the benefits of reducing cognitive load on an individual or a group, because the list takes care of some "remembering" functions and some "coordinating" functions. Counterbalancing that is the cost of using and maintaining the list. If the benefits outweigh the costs for a specific use case, a task management system is more likely to be used for a longer period of time.
A shopping list is an example of a task management system at one end of the cost-benefit spectrum. Shopping lists are effective at reducing the cognitive load of remembering what you need to buy at a store, and they have a very low cost to use. A large part of the low cost is due to the very homogeneous nature of the tasks - each item on the list is something to be located in the store, and as a user you complete each "task" in a similar way, namely by locating the item.
Personal to-do lists, however, are rarely this tidy, and group-level tasks are even more diverse in size and scope. Having tasks of different sizes, complexities, and levels of abstractedness makes it more difficult to stick to one system. With heterogeneous tasks on a list, you have to approach the list in slightly different mindsets and contexts with different kinds of items, and the response for each item is different. This is mental overhang that increases the cost of using the system.
Most task management systems attempt to reduce the cost of heterogeneous tasks by allowing for flexible project or task structuring. Sometimes this takes the form of "tagging" tasks with your own labels; other times this might involve "nesting" smaller tasks under bigger ones. These help the user to cognitively differentiate between different items on the list, which makes it slightly less costly to have different kinds of items on the list.
The cost of this flexibility is, of course, the cost of using and maintaining it. Using nested lists to help break down larger tasks is great, but it requires more time upfront when creating the tasks. Tagging helps organize the tasks, but then you have to remember which tags you have, and stick to your tagging system in the future (or risk having to spend a lot of time migrating everything ot a new tagging system).
Focusing again on the cost of maintaining a to-do list over time, there's another kind of cost that I think is often overlooked: the cost of dealing with tasks not yet done. My sense is that users rarely consciously think about what to do with incomplete tasks; they just use some kind of default. Most of the time, if the to-do list is date-oriented, the undone tasks are just rolled over to the next day. However, in my own experience, any task that gets rolled over once has a pretty high chance of getting rolled over again and again, until one day it kind of just falls off the priority list and joins the list of "things I should have done but which now aren't important".
In to-do lists that aren't date-oriented, incomplete items seem to either slowly lose importance over time, or enter the realm of "bigger" projects that are being worked on but with a more nebulous timeline. Both of these aren't terrific states to have, since they introduce uncertainty and heterogeneity into your task management system.
The problems in groups
On top of all those problems, which are common to different kinds of task management systems, there are additional problems stemming from having one task management system for a group of people.
One problem is synchronization in terms of usage habits. Everyone in the group must understand and use the task management system in the same way, which distributes the cost across all members, or somebody has to bear all the cost of being the one in charge of creating, maintaining, and checking off tasks.
Another problem is synchronization for a given team member between the group's to-do list and her own to-do list. It's possible that she uses the group's system as her own system as well; she might own a "card" on Trello for example, and create sub-tasks on each task as her own, more detailed to-do list. However, this obviously forces her to adopt her group's task management systme, which is not necessarily the most comfortable one for her. A team member might create his own task management system, but in that case he bears the cost of syncing up with the group.
In tech firms, I've noticed an additional problem with group to-do lists: diversity in terms of tech skills. This may seem trivial, but if you have a team with a diversity of functions represented, it probably means that the members use completely different tools for work. The engineers might be comfortable with Github issues, but then the business people who never touch code will need to overcome the large hurdle of learning how to use Github, which is not as intuitive or feature-laden as a tool like Asana. The developers, on the other hand, might not like using Asana because there's no way for them to close tickets from the command line.
Addressing these problems
There are surely different optimal solutions to the best task management system depending on who's using it and what they're trying to achieve. In general, though, for individual to-do lists, I'm trying the following principles out:
- Tasks at the "lowest level" (i.e. the ones with no further tasks nested under them) should all be concrete tasks. Instead of "Finish Feature X", I'll break it out into "Finish initial pull request", "Address comments from pull request", and "Merge in pull request", for example.
- Tasks on a list (or those at the lowest level of nesting) should be of roughly the same "size". I try to avoid individual items that will take more than around two hours to complete, while also not breaking down tasks into miniscule chunks unless I'm afraid I'm going to forget something.
- Every morning, I start off the day by creating a new to-do list for that day. Nothing gets rolled over from yesterday automatically, but I do consider every incomplete item from the day before to see if it's still relevant. I don't consciously have a system to keep track of the irrelevant ones.
- I update any group task management lists I'm a member of only upon the completion of a major set of to-dos, or at the end of the day or week, depending on how urgent the projects are.
I've also dealt with a few different situations involving group projects. In these cases, the following points seem to have worked well:
- Unless the group consists only of people who interact with code on a day-to-day basis, I avoid systems requiring slightly more tech knowledge (e.g. Github issues)
- Tasks on the system are generally of the same size and are higher-level features (i.e. they can all be split into smaller subtasks); individuals working on the features can work out their own to-do processes
- There should be clearly separate lists for "reactive" vs. "proactive" tasks. Reactive tasks are usually bugs, whereas proactive tasks might be a new feature. The team should understand the prioritization between these two lists.
- Update meetings to go over outstanding tickets should occur about once a week.
And finally, here's something that I wished existed: APIs that existed between all the different task management tools, that would allow:
- Complete and accurate vision of other people's tasks (so that everyone on a team could see everyone else's to-dos, for example)
- The ability for everyone to use their own choice of task management system (so some people can use Asana, others Trello, others Gmail Tasks, and everything would "Just Work")
- The ability to interact with your to-do items from the command line regardless of which tool you're using (kind of like the ability to close Github issues with commit messages from the command line, but souped-up and workable with any task management tool)
comments powered by Disqus