What Do They Pay You to Do?

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 us assess whether our company’s expectations are a match with the personal missions that motivate us.

Let’s take a look at several personal missions I’ve known people to embrace:

Test this beast until they pry it from my unwilling fingers. Are you automatically suspicious of your product, and do you enjoy tracking down and excising every last defect? If so, you may be convinced that the only thing you know from your testing is that you haven’t found all the defects. Your mission is to keep testing until you find more defects, which may fit with an organization that values that kind of search-and-destroy mission—a producer of mission-critical, life-or-death medical applications, for example.

Test the software and improve the process as we go. This mission is fraught with personal risk. Many organizations, such as Jill’s, don’t necessarily want everyone working on improving the process. Some organizations’ main concern is shipping something—anything. They’re less concerned about how easy the product is to create, or how good the product is—and in some circumstances their strategy can be correct.

Assess the risk of catastrophic product failure. If you’re working on desktop shrink-wrap software, working to prevent catastrophic product failure is probably not an appropriate mission. In a commercial organization, you’d be better off—in terms of your ability to get things done in the organization—with a mission that’s closer to “assessing and reporting product state or to testing until the product ships.”

Be responsible for product quality and decide when the product is ready to release. As I said in another Last Word column (“No More Whining” September/October 2000), releasing product is a business decision—and when you try to take that business decision out of Senior Management’s hands, you’re expanding your mission beyond test/quality assurance/quality engineering, and taking on corporate responsibility. Being responsible for the quality of the product makes sense only if you have the responsibility for planning and estimating the project, for planning and managing the developers and how they work, and for planning and managing the testing work. If you’re not responsible for the entire project, you can’t possibly be responsible for the quality of the product. And if you try to approve/disapprove the software release without being responsible for the entire project, you are attempting to do more than your company pays you to do. There’s a chance your company will take your recommendation—but more often I’ve seen companies stop listening to the testing group after a recommendation the company doesn’t like. Better to offer risk assessments and options, and let Management do what they’re paid to do.

Assess the state of the product under development at any time and report on that state. This mission covers most of the other possible missions, and is the one I’ve adopted as my own. My mission demands that I define what quality means for each project, and helps me recognize that I need to be involved in “testing” the product at the very beginning of the project. I’ll test the project schedule when there isn’t anything else in the project to test.

How do these five missions fit with what your company really wants you to do? What can you do if there’s a misfit, and you don’t want to redefine your personal mission? If finding a new job isn’t an option you want to choose, then maybe a reframe of your personal mission is in order.

If, for example, your organization believes the testers are responsible for customer-found problems, then here’s a reframe: The developers create the defects when they create the code. Of course developers, like testers or quality engineers, want to do the best job they know how. They don’t go to work every day muttering under their breaths, “How can I make the test manager’s job miserable today? How many defects can I put into the code?” but sometimes they have bad code days, bad spec days, bad architecture days, or bad requirements days. Developers make mistakes, just as the rest of us do, and their mistakes cause software defects. No matter what your mission is, your job is not to judge the goodness of any given developer, but to test the code (and, with my mission, to also assess the state of the product).

And if you’re trying to reframe the “blame the testers for customer-found defects” mindset, you can use my “assess the product at any time” mission, and treat each customer-found defect as a way to improve your testing process.

Maybe you don’t have Senior Management actively working against process improvement as Jill did. Maybe you have reluctant peers, and no backing from Management. If so, then your company probably doesn’t want to pay you to do process improvement as part of your job. Can you change the situation? If not, it’s time to find another job, or change your mission while you work at your current job.

I want to do my best for my employer, as I’m sure you do. Sometimes, I want to do more than what they pay me to do. When that happens, I check out the difference with my manager, to make sure the extra work I want to do is valued, and will benefit the company.

If, like Jill, you have a title but aren’t allowed to do the work that goes with the title, then see if you can do small things, preferably just in the test group, and discuss how to increase your sphere of influence with your peers and manager.

Be clear on your personal mission, and how that aligns with what the company wants to accomplish. If there’s a mismatch, see if you can reframe your mission to better align with your organization. Don’t assume that you’ll be able to convince other people that your mission is The Right Mission for the company…because you won’t. Instead, make an effort to be clear on what the company wants you to do, and then do it, or go out there and find a better fit for your mission.

Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

What can we do for you? Go to: Writings and Presentations, Chronological Listing

What Do They Pay You to Do?

ROTHMAN CONSULTING GROUP, INC. Johanna Rothman, President

ROTHMAN CONSULTING GROUP, INC.
Johanna Rothman, President