What’s on Your Not-to-do List?

Summary: 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. In this week’s column, 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.) 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...

Make Your Mission Possible

Janice strode down the hall and made a sharp right at a cubicle decorated with dragons. “Hey, Steve, got a minute? I need your help with a problem.” “Janice, the last time you asked me for my help, I got stuck in that installation mess. I appreciate being one of your team leads, but I get worried when you ask for help with problems. What’s going on now?” “We have a problem with customizations for Big Customer2. The good news is that we do these customizations, right? But the bad news is that we have to port them from release to release.” “We did that last month.” “Well, you did. Then tech support decided to add the extra piece of the reports we discussed last month.” “What? Why did they do that? Not to this product—they can’t.” “Well, Big Customer2 paid us a pile of money for not too much work. And that’s where you come in. I need you to add that new report to the point release you’re working on now.” “How much money? I bet tech support has no idea how much this piece of the report will cost us to support or how much time it will take away from our next release. We can’t just think of this report as a pile of money; it’s a headache. We were never going to put that functionality into the product. We were going to put it in the new reporting system, remember? Now we’re going to have to support that report forever. Big Customer2 is never going to want to change.” Steve put his head in...

What’s on Your Not-to-do List?

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...

Successful Software Management: 14 Lessons Learned

© 2003 Johanna Rothman. This article was originally published in Crosstalk, Dec 2003. This article is the outgrowth of my original talk/article, Successful Engineering Management: 7 Lessons Learned Successful managers realize that they need to balance the needs of the business, the employees, and the work environment to be effective. In this article, the author summarizes her experiences in determining the work to accomplish and planning it, managing successful relationships with the group, and managing reactions to typical management mistakes. Shortly after becoming a manager, I dragged myself home from work, flopped on the couch, and said to my husband, “This management stuff is hard. Nothing I learned in school prepared me for this people stuff. And that management training, that was just form-filling-out nonsense. The soft skills – dealing with people – are the hardest.” My husband chuckled and commiserated. If you are like me, and you started your professional career as a technical person, this management stuff is difficult to do. Not the forms, although the forms can be irritating, but the difficult part is knowing how to deal with people, and completing the work your organization expects of you. I have now had more than 15 years of management experience, and have learned a number of lessons about managing people. Define the Manager’s Role When you become a manager, your role is to organize purposefully [1]. For me, that means creating an environment where people can perform their best work. As a software manager, that means I work to create business value by balancing the needs of the business, the employees, and the environment. There is...

What Do They Pay You to Do?

© 2001 Johanna Rothman. This article was originally published in STQE, September/October 2001 issue, as the Last Word column. One of my colleagues recently took a job as a software quality assurance manager at a commercial software company. Jill had always been determined to improve the product development process wherever she’d worked, and seeing “process improvement” in her job description made her feel this new job was going to be a good match. Jill started by moving the testing group from doing only manual black box testing to performing a combination of exploratory and defined black box testing, and then she developed some regression tests. She started to gather a number of metrics about the product development process, getting information from a number of projects. When she realized the metrics showed that their project estimation techniques were inadequate, she wrote a memo to her boss, including her metrics and a series of recommendations. When Jill arrived at work the next day, her boss summoned her into a senior management meeting. After a lengthy interrogation, the managers demanded that she remove all traces of the memo from her system, delete the metrics, and never talk about this again. Jill was stunned. “Why?” she asked. “We’re in charge of process improvement here, not you,” answered her boss. “When we decide it’s time to improve the process, we will. Until then, butt out.” Don’t assume that because you have a title or a job description that you can take either one as literal truth. Do you really know what your company pays you to do? Understanding why we were hired can help...