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.) And, I 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:
- What does the organization pay me to do?
- What work helps me fulfill that mission?
- What work is important to the organization, but should not be done by me?
- What work is not needed by the organization?
Your first responsibility is to perform the work the company pays you to do—your mission. In the case of the CTO, filling in as the acting manager for a week or two, or maybe even a month, while recruiting for the open positions may have been a great idea. But as the CTO, his mission was to make sure the management work was accomplished, not do it himself. He would have been better off determining another way to manage the work without attempting to act as the development and test managers for three months.
The previously mentioned, beleaguered test manager was initially confused with his mission. He originally thought his mission was to “fully test all the software.” But that's an impossible mission. He revised his mission to “test the riskiest products in restricted time.” That mission allowed him to assign staff to the products with the highest risk, and to time-box their testing work, so people were available when they were needed for the next project.
Once you know your mission, you can look at all the work on your to-do list and determine if the work on your list helps you fulfill that mission. It's all too easy to keep parts of older roles (before a promotion or a move in the organization), or to help a colleague around the company. But your first job, especially if you have too much work to do, is to ask yourself if each and every item on your to-do list helps you add value to the organization in your current role.
The CTO adds more value by acting as the CTO rather than as the development and testing managers. The test manager adds value by determining which projects to staff and which projects not to staff.
If you're like many people, you have work on your to-do list that needs to be done. But if it's tangential to your mission, someone else should do it. You may have started performing this work because someone needed it and you were the “go-to” person. Early in my career, before the days of reliable FTP, I babysat large file transfers to remote sites at particular times of the week. After a few months of doing this, I told my boss I couldn't attend a meeting he wanted me to attend because of the file transfer. He explained to me that although this work was necessary, I was not the person to do it. That work didn't require my skills and attention. The work was necessary, but I wasn't the one to do it. If you still own work that doesn't fit anymore, work with your manager to transition that work to someone else.
When I perform assessments, I inevitably find someone accomplishing work that is no longer needed. Sometimes the work is generating reports. Other times the work is a standing meeting. But whatever the work may be, the organization no longer requires that work. Once you recognize no-longer-valuable work, you can cross it off your list without worrying about who will pick it up.
Planning, organizing, prioritizing, and performing your work is not trivial. Take a few moments to think about the value you provide to the organization, and how to reflect that value in your to-do and not-to-do lists.
© 2005 Johanna Rothman. This column was originally published on Stickyminds.com
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.