What's on Your Not-to-Do List?


Drawing up a to-do list sounds like a logical starting point when you want to prioritize your workload. But if you have an extra-long list of tasks, the list you should start with is the not-to-do list. Doing so forces you to take an extra hard look at what you're doing and if you should be doing it. Learn more about Johanna Rothman's not-to-do list, how it helps you stay focused on the most important tasks, and how it inevitably helps you maintain your value to the organization.

I'll bet you're one of those people who have too much to do. I haven't met anyone in the past few years who didn't have too much to do, so it's not much of a bet. I also suspect that you're so busy with what you're doing, that you haven't yet thought of what you should not be doing.

A not-to-do list is as important—if not more so-than a to-do list. When you make a to-do list, you're listing, categorizing, and prioritizing all the work you need to accomplish. But with a not-to-do list, you're first thinking about why you are working, and ensuring that you're accomplishing the strategically important work.

I recently worked with a chief technology officer (CTO) who, aside from his CTO role was also acting as the development and testing managers, until he could hire people for those positions. As a short-term tactic, that may have been ok. But while he was acting as the manager of both groups, he was unable to perform his job as CTO. After three months of attempting to act as all three managers, he realized that he was not working well enough in any of the three roles. Because he was trying to perform all the work himself, he'd made it impossible to take the time to hire the people he needed to help the organization run smoothly.

Taking on too much work isn't limited to senior managers; it's just as much a problem for other managers. One test manager prided himself in his ability to be a team player-by taking on each project, regardless of whether he had the testers or time to do the testing. He assigned testers to every project, even if he wasn't able to plan for staffing the project in advance—and whether or not his staff had enough time to devote to each project. He soon found himself in the position of assigning each tester to at least three or four projects. Because each tester was always context switching, the testers were unable to make progress on their projects. Soon, testing was a bottleneck, and the testers were assigned to each project later and later.

Technical contributors are just as susceptible to the problems of too much work to do and not enough time to do it. One developer I know somehow hadn't managed to take long weekends or a week of vacation in three years. He was always too busy, adding a feature here, fixing something there, and developing a tool for someone. Sure, all of his work was valuable, but it wasn't necessary at the time he performed the work. A month ago, his wife discovered he was about to lose all his vacation time. So she packed a suitcase, dropped the kids off at the grandparents, and "kidnapped" him from work. On the way to the airport, she locked the cell phone and pager in the glove compartment and told him he'd better relax and enjoy the vacation!

There is always more work you could do. And there will never be enough time to do it all. The key to successful work is to pick and choose which work to do and when.
When you're planning your work, ask yourself these questions:

  1. What does the organization pay me to do?
  2. What work helps me fulfill that mission?
  3. What work is important to the organization, but should not be done by me?
  4. What work is not needed by the organization?

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.