Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Software Development

Shaking

Raul has a big problem—too much work. He can't hire more people; his budget is fixed. He knows that if he maintains this pace, he won't be good for much. However, he's not at all sure how to stop the craziness. If you, like Raul, are too busy or stressed to think, make sure you're doing work the company pays you to do, not just work you "should" do.

Instead of shouldering the "shoulds," ask some "shoulds" yourself—and use the answers to dig yourself out of the avalanche.

Dump the Lead Weights
Question 1: Should this work be done at all? Too often, we have make-work, such as meetings we've "always had," or work that's no longer necessary. If you have an opportunity to cancel a meeting or stop doing some form of work, take it! Not only will you benefit yourself, you'll help your team.

Steve, a first-line manager, was excited by his promotion. Now that he was a development manager, he attended the weekly meeting in which the product manager discussed the product lines and their planned evolutions. At his first two-hour meeting, he realized that all of the product managers, all of the service managers and all of the development managers attended—a total of 24 people. Because Steve was new to the meeting and new to management, no one listened to him. Then Steve realized that the product evolution didn't even occur in that meeting—it took place when the senior architects had lunch and then worked with the manager of business development.

Steve stopped attending the weekly meetings. Not only did he feel as if he'd rescued two hours each week, he was able to talk to the people who did make the product decisions, and discuss those decisions with his team.

Though it may be easy to divest yourself of unnecessary meetings, it's usually more difficult to stop working on a product or project. Marie, a group manager responsible for six projects, was trying to reallocate re-sources when her company chose to stop supporting two products. Marie and her engineers wanted to do the "right thing for the customers" and respond to their requests. Six months after the products were supposed to be resting in peace, she and four of her people were still devoting about two person-weeks per month to them. After realizing that the company wasn't paying her to support those two products, Marie chose to stop working on them, taking the following actions:

• She called each of the remaining customers and told them that she and her group were no longer supporting the products.
• She spoke one-on-one with each engineer, explaining that she was no longer assigning them to these products, and that they were not to work on them.
• She and her engineers turned over the source code and associated documentation to the service group.
• Finally, she and her team had a celebratory dinner to mark the end of the products.

After the product turnover to service, Marie said, "I wish I'd killed those projects earlier. They were draining my energy and the energy of my group. When the company decided to pull the plug, we should have pulled the plug, too, no matter what the customers said. We spend way too much time and energy on products that don't move the company ahead. We placated the customers instead of moving them to a product that would fit their needs better. Now, we all have more time to do the work we need to do, rather than the work we think we should do."

Differentiate Between Your Work and Others'
Question 2. Should this task be on my personal to-do list? When you think about your to-do list, remember that if you're a manager, you have a group of people who work with you. If this task is part of your group's mission, take the task into your group. However, consider whether it's part of what you personally do, or if it's something you can delegate to a staff member.

Zoe was about six months into her first management job as a test manager. Previously, she'd generated the defect trend graphs. She still had that responsibility, but now she was two weeks late with the graphs, due to her new management duties. Zoe's project manager explained that without the defect trend graphs, he couldn't manage the project properly: Was she or wasn't she going to help him?

That's when Zoe realized that even though the graphs were part of her management work, she didn't have to generate them herself, so she passed them on to the capable staff member who had taken over her testing role when she was promoted.
Voilà! Zoe didn't have to worry about getting the graphs done, and the rest of the project team received the data they needed.

Push Out Work That Doesn't Belong To You
Question 3. Should someone else do this? Sometimes, other people think you "should" do work that belongs to another group. Like most "shoulds," this one deserves some serious examination.

Max, the director of engineering for a startup, agreed to help the sales group with presales support and the service people with installation support. Max pestered the Sales VP and the Service VP with requests to train their staff to do the sales support and installation, but when they told him that their people were too busy, Max continued supporting the sales and installation work himself.

One day, Max arrived at work with a full-fledged product crisis. One customer had used the software in an unintended scenario, and of course, it didn't work at all. Max's group saw the value of this scenario and decided to create a workaround for the customer and then plan how to add the feature to the product. Unfortunately, two of Max's 12 staff members were on presales calls and four were on installation calls, leaving him only half-staffed for this crucial workaround and new feature integration. That's when Max decided it was time for sales and service to do their own work. He scheduled training days for the other groups over the following two weeks, explaining that his team was not going to do presales support or installations after that time.

In Max's case, his initial reasonable accommodation of help requests turned into Engineering taking responsibility for Sales and Service's work. But not all "should" work is a transformation of help gone on too long. Sometimes, the work you're doing or "should" do is a consequence of other people not doing their own work.

This often happens when developers don't carefully check or test their code before handing it off to the testers. When managers don't take responsibility for their group's ability to perform their work, they dump that work on someone else's group. If the task doesn't belong to you or your group, ask who else should do it—then work with that group to help them tackle the necessary tasks.

Drawing the Line
By asking yourself these questions, you can draw the line between work that you must do and work that you "should" do. Shaking off the "shoulds" will help to restore sanity in the workplace—and boost your team's output.

Next month in part 2, we'll examine the final three questions that can help you pare your workload down to fighting trim.

---

Johanna Rothman is a consultant in high-technology product development management, working with companies to increase their effectiveness as organizations and managers. Contact her at jr@jrothman.com or visit www.jrothman.com.

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.