Many of us have worked in test groups in which we felt as if we didn't have enough time, hardware, or staff to do the work. In those situations, it's hard to escape the feeling that while somebody might be in control, we are certainly not. As a test manager, you don't have to work this way. There are other, more effective, ways to develop and use your influence within your organization to help your test group--and project--succeed.
Influence is not about control, nor is it about taking away other people's choices. Influence is about coming to a mutually valuable decision about a problem-redirecting your organization's power and focus. As a test manager, you may want to influence others in the organization when:
These are examples of tactical problems in obtaining specific objectives. You can also exercise influence more broadly-strategically-to change how the organization perceives itself, or to change how it does business.
As test managers, we can be valuable agents of change. We have a different perspective on these problems than other managers in our organizations because of our
role in planning and measuring testing to obtain and share information about the product under test. If testers, as James Bach says, "hold the flashlight," then test managers figure out at least some of the places to shine that flashlight, and how long to spend flashing-a specific form of risk management. Because we illuminate risk from a different perspective than anyone else on the project, we often have a unique approach to problem solving.
We can influence other people to see our perspective and agree to it, or to come up with an even better solution to our problem.
What Is Influence?
A dictionary definition of influence is:
"The act or power of producing an effect without apparent exertion of force or direct exercise of command"
"The power or capacity of causing an effect in indirect or
intangible ways: sway."
To sway people, you get them to change what they're doing. Sometimes you give them something they want-their WIIFM (What's In It For Me). Sometimes, you get them to reconsider their WIIFM, to enlarge their wants to include more of the organization. To be truly influential, first you must become fully aware of your problem context-the setting or environment where the problem exists, including all those who might be affected by it. Once you've surmised the problem context, you can decide how to influence the other person. (You might even change your perspective, based on your understanding of the problem context.)
Consider how you can provide value, and finally, what your "influencee" wants. Then, you can choose how to provide that value and what to ask for in return. This value exchange is the essence of influence.
Note that I'm not talking about a strictly monetary exchange. Sometimes you loan your credibility to some proj-ect your influencee wants to succeed. Sometimes you give your time to some other group, or perform some other service to the organization. Sometimes you get a budget increase to give more value to the organization. View your problem within the context of your organization, so you can see what you want and what you're willing to give.
Share the "Problem Context"
Many test managers don't have the staff they need to do an effective job, nor do they have the budget to hire the staff. One way to define that problem is:
I don't have enough testing staff.
That problem statement is a good start, but is limited in scope and shows no way for you to provide value to more of the organization. An alternative problem statement is:
I don't have enough people to execute my mission.
That's vague as it stands, because it depends on what your mission is. Your mission could be: "Find and report defects, especially Big Bad Bugs." Or your mission could be: "Test this software beast until they pry it from my unwilling fingers, finding and reporting on all defects." There are many possible test manager missions-maybe as many as there are test managers! I choose to define the test
anager's mission as:
To assess the state of the product under development at any time and report on that state.
With this mission statement, I can describe the problem context as:
Without more people to do the testing, I am unable to sufficiently assess and eport on the state of the product as well as I would like. I can't give you,
Project Manager or Senior Management, the picture I think you need to see. That means you, the management team, will make decisions with sketchy information. You can still make the decisions, but you are assuming risk. I don't know how to give you better information without more people. If you want to take the risk of operating with very incomplete information, that's okay. But I recommend we get more staff so you don't have to make blind
This problem context statement brings the problem's significance to the rest of the organization. It shows that the problem is bigger than the test manager whining about not enough people. It makes inadequate test staffing an organizational issue, not a testing issue. Now that you've shared the problem context, consider what you have of value to the rest of the organization.
What Do You Have of Value?
You provide value both as a person and as a test manager. Your perceived credibility, fairness, track record, and capabilities as a manager have value not just to the test group, but to your peers, your managers, and the rest of the organization.
Your own level of test-manager-value depends on how you define your mission as a test manager. Your mission defines the work you choose to accomplish: with the test organization as a whole, with the project manager, through your mentoring of staff, and in the way you structure your team's work. When you perform that mission, you have at least these valuable items:
Different people use their value differently, even when going after the same goal (getting funding for more testers, to provide more information about defects to the organization). Here are stories of three test managers and their approaches to getting more positions funded in their organizations.
Andrea was a test manager who also ran the customer support group and the technical writing group, in addition to the test group. She had two testers, four technical support reps, and two writers. (Her organization had six developers on staff.) Andrea needed at least two more testers immediately, and wanted an additional two automation and tools developers over the next year. Andrea's approach was to tell her boss, the Vice President of Engineering, exactly what was necessary: "I need two more testers right now, and two more over the next year."
The vice president's response was bottom-line-based: "How expensive are those testers? Every time you ask me for more people, it costs me money-as much money as a developer. We're a young company, and we have to make our balance sheet look good. Otherwise our investors will be upset, and we'll be in trouble. Live with what you've got."
Andrea and her boss have had this same conversation at least half a dozen times. Every few months the development team adds more people to its staff, but Andrea can only add tech support people-because they cost less. As the number of developers has increased, so have the software's complexity and the size. Andrea
doesn't have enough staff to test the product sufficiently, so the company is building up its product technical debt.
Technical debt, as defined by my colleague Dave Smith, is the debt a company "owes" to a product they persisted in shipping in an incomplete or unstable condition over several releases. This is a situation referred to by Hunt and Thomas's book The Pragmatic Programmer as "software rot"; but the software isn't necessarily rotten-it's just incomplete.
At some point, as the technical debt increases, the load on the customer support staff will be so overwhelming that the company will have to use developers to staff the phones and solve the support problems. Andrea can see this coming, and knows there is a window of opportunity before the "technical debt overload" overwhelms the company's ability to do development-and actually prevents new product development. She knows she needs more testers to prevent this from happening. But she doesn't know how to explain the significance of what she's seeing to her management. Even though Andrea can see what's happening, she hasn't defined her organizational value in a way that would allow her to address the complete problem.
Bill has approached the technical debt overload problem differently. Bill also has responsibility for both a test group and the technical support group. In his organization, the writers are part of the development team. Bill already has five testers, including one full-time test tool and automation developer. (There are ten product developers.) Bill wants to hire two more testers-because two releases ago, the test group fell behind the developers and significant parts of the product were not fully tested. (Technical debt is starting to affect Bill's organization. The testers don't feel as if they are fully testing the product, and the tech support folks are hearing about the same defects repeatedly.)
Bill used the assessment and reporting mission statement to explain the problem context, the problem significance, and his value to the situation:
If I can get two more people to do the testing, I will be able to assess and
eport on the state of Modules A and B. Since the product is evolving to be
ased more on Modules A and B, I will be able to provide management the
nformation to understand the development progress and make ship decisions. f I get two testers now, I can do enough testing of Modules A and B to avoid incurring more technical debt, and having to keep people testing the inevitable ixes after we ship the product. I can use this release's testing as an early arning signal to anticipate the load on the technical support group.
Bill had a two-pronged approach. First, Bill went to the Vice President of Sales and asked if she needed technical pre-sales support. (He knew she did, because the sales reps constantly called the support reps for help before they went on sales calls.) When she said yes, he made an offer: "If you support my request for more testers, I can give you phone-based pre-sales support after the product ships." (More testers helped find defects before the product shipped. The testers could focus on the next release, and the support staff wasn't kept busy finding and reporting already-known defects.) The Vice President of Sales was thrilled, and agreed to support his cause in the Senior Management meeting.
Then Bill went to his boss, the Vice President of Engineering, and made another offer: that if he got two more people in testing he could provide benefits across the organization.
He said, "If you sign two more testing requisitions, and help me hire more testers before the freeze milestone, I expect to be able to provide pre-sales phone support to our sales staff. That should increase our sales from this product."
Bill's boss said he'd bring it up in the budget meeting, and was pleasantly surprised that the Vice President of Sales supported Bill's request. Bill got his requisitions and was able to hire the people he needed.
Andrea's value to the organization is more limited than Bill's. Andrea is focused on the testing part of the problem, which is not sufficient for showing the value she provides the organization. Bill realized he could use his staff in a number of ways, all of which would provide overall value to the organization. Another test manager, Carol, took a different approach, focusing on a narrower scope of influence than Bill: the product development organization.
Carol was recently hired to run a software test group of four people. Those four people attempt to test the product that sixteen developers are working on. Carol realized during her interview process that this organization had enormous technical product debt. Carol decided to investigate the implications of the technical debt. She talked to the other managers and listed two major consequences of the inadequate testing: Developers were spending almost half their time on product support, and the last two product releases missed their ship dates by six months (a disastrous slip, since that doubled the targeted timeline).
Carol went to her boss (who was also the development manager) with a proposal: "I have some ideas about how to meet our desired six-month release dates, and how to reduce the time the developers spend supporting the product." That got her boss's attention. She laid out a plan that included hiring a project manager, peer review of bug fixes, and hiring four more people with a variety of skills for the test group.
Carol chose to exercise her value inside the product development organization-more than just the test group, but not across organizational lines in the company. Carol is showing she has more than just "manage-the-testing" value to the organization.
Provide Value and Recognize
What Others Want
To use influence, you provide value and help others see the significance of the problem. Then it's time to look outward to see what other people want. What is valuable for you to provide?
You provide value to your organization in many ways. Sometimes, it's your general managerial assets that others value: your credibility, fairness, track record, and management capabilities. In addition to your management capabilities, you can provide additional value by:
You are much more than just someone who manages or leads the test effort on a product. If you can see the significance of an issue, and can share that with the rest of the organization, you are incredibly valuable to your organization. One way to share significance of issues is to assess and report on risk.
Product testing and measurement is a primary vehicle for the test manager to help assess risk during the project. The risk isn't just limited to the testing organization, where a risk might be "We can't get the testing we'd planned to do done on time." The risk exists across the product development organization, and sometimes across the company. The three test managers above recognized that the risk to early shipment of inadequately tested product was higher-than-desired support costs, and less capability in development for the next release.
To provide value in risk assessment, it's a good idea to look beyond the boundaries of the test group to see who else is affected by creation of technical debt, or by slipping schedules. Technical debt, for example, affects developers' ability to adequately design the next round of changes (and creates an unstable base on which to implement those changes), and also has an impact on Support and Sales.
Identifying and Solving Problems
Here's a problem many test managers run into: the developers miss their deadlines, and your time in test is reduced. Before you even start testing you know there is a substantial risk that the product that will ship is not the product your organization had planned to ship. If you can identify that problem early to the project manager, you may be able to influence the solution.
One solution could be to ship the product as an early release, such as a Beta version, to give you more test time. Another solution could be to change how the developers fix the defects, or to target certain areas of the system for defect fixing and defer fixes in other areas. Another possibility would be to reduce the number or scope of the features to be shipped in this release. The solutions you develop will depend on why your company is shipping the product.
Managing the Test and Measurement Work to Assess Product State
The testing results help all the decision-makers evaluate risk. As the test
manager, you look for information about the product in order to answer a number
You may have other product- or project-specific questions to add to your list. Choose questions that help you answer whether you've accomplished your goals and priorities. I tend to choose measures that help me know when we can ship the product.
Helping Make Ship Decisions
"Can we ship this product yet?" If you can help your organization make that ship decision, you've satisfied many people's WIIFMs.
It is difficult for many of us to make product ship decisions. As test managers, some of us want to keep the product in test until they physically pull it away from us. As proj-ect managers or development managers, we may have bonuses riding on release dates (a foolish, but very common idea). But if we are responsible for the tech support work, we have even more motivation to find and fix more of the defects before the product ships.
No matter what our perspective is, we may think we know what the right ship decision is. It's not possible, however, for the test manager alone to make a ship decision without having negotiated and objectively defined release criteria with the rest of the project team. At the very least those criteria have to define what the organization is looking for from this product for this release, and may be an excellent way to identify leverage points for what other people want. (For a brief discussion of how to create release criteria, see STQE Volume 1, Issue 2, page 34.)
What Do You Want in Return?
For the purposes of this article, I'm going to assume you don't work in a "corrupt" organization, in which managers exploit their positions just because they can. Using influence on those people requires that you look at their personal positions in the organization and satisfy some of their selfishness. I find that placating those people gives me heartburn, so I choose not to work with them.
Instead, I'm assuming you work with reasonable, well-intentioned project and senior managers who Deming was talking about when he said in his book Out of the Crisis: "No matter how it looks, everyone is doing their best." They might not know how to use test managers, or they might be making some classic testing mistakes themselves (such as assuming you, the test manager, are somehow responsible for quality).
When you help define the consequences of releasing a product with technical debt...or when you define and track release criteria...or when you have conversations about what the organization requires from the release...you've provided substantial value. You may get some well-deserved resources or support by using that value to illustrate to your managers:
You may want something else in return. That's fine. Whatever your goals are, just be clear on what you want to get from this two-way relationship.
When It's Not You
At times, when we attempt to provide this value to the organization, we feel like it's us against the rest of the world. That's not a good place to start when you want to influence people. Let's examine why you might feel that way:
Even when you've assessed your value and you think you've discovered the ther people's WIIFMs, influence may not seem to work. If that's the case, erhaps it's because the other people-the project manager or senior managers-may ot have considered their value or what they want. When faced with this nevenness of perceived value, you may want to offer to help them define their alue, and in the process help clarify their WIIFMs. There's no simple solution hen your colleagues don't know what they want. Although we'd like to think we an figure out a way to work with everyone, sometimes you just can't. ltimately, you choose with whom you work.
The Bottom Line
As a test manager, one of your roles is to assess product state and report on t. You provide value by planning the product testing so that you can ssess-along with the rest of the management team-the risk of shipping the roduct. The more widely you disseminate the data about the product state, the ore perceived value you will provide, and the more influence you can have.
As an influential test manager, you can
You don't have to feel out of control. The more you share your perception of the risks, the more you can influence what happens with your project, and the more successful you can make the organization you've invested in. STQE
I thank the following reviewers for their helpful comments while writing this rticle: Mark Druy, Elisabeth Hendrickson, Cem Kaner, Brian Lawrence, Brian arick, Noel Nyman, Jeffery Payne, Dave Smith, and Jerry Weinberg.