Having just had the chance to go through an election cycle here in the United States of America, some of us have had more than our fill of so called “Politics”. For many of us, it is seen as a a derisive term, associated with chaos, brow beating, and loud attacks on others that, frankly, can be pretty draining on the spirit. Thus it may seem strange to ask my fellow testers to consider the role of Politics in their every day work. What do national and state elections have to do with Software Testing?
First things first… relax! That’s not the kind of politics I’m referring to. No, the kind of politics I’m talking about are the kinds that we deal with every day in our own organizations. It would be nice to think that, somehow, our organizations don’t have politics, that we just work for the common focus of the team to ship great product and delight our customers. However, even there, we quickly see that even those goals are ripe targets for internal politics.
Let’s step back for a second and let’s make sure that we have our terminology straight, or at least an agreeable terminology for this particular discussion. When I say politics, I mean it in what I’d term the classical sense of the word. Politics is the business of the people, not an abstract of people, but the people we live and work with every day. There is aspects of governance, of power, and of control of message more so than direct corporal control of people (though they are often seen as synonymous). Organizations large and small govern themselves due to a code of ethics that is either explicit or implicit. Those rules and mores often run deeper and more pronounced than many people want to believe, even among people that might want to call themselves “political agnostics.”
Politics, in many ways, is then the art of a person or group of people looking to shape the message of the whole in ways that is advantageous to them and to others. Politics in and of itself is not bad, but when it gets perverted and used against others for control or points, then it can be come a poison in an organization. During a company’s growth trajectory, it’s common to see different approaches tried to determine which one is more effective or which one may be less successful. I had a chance to see this happen first hand with two different approaches to testing in the early to mid 90′s. There were two divisions that were developed at Cisco Systems; Development Test and Product Test. Both were important, and both aimed to help create a solid product. It seems like a little thing to name something, but I remember well, the jockeying by individuals and organizations as to which one they belonged to, and which one ultimately got the most attention and funding. Some of this came down to prestige; more people wanted to have the Development Test Engineer title than be called Product Test Engineers. At the fundamental level, they did much the same thing, but a name created an interesting battle, and the byproduct was a tug of war between groups to define the message and encourage people to want to be part of one group or another. In other words, a classic political battle, with software testers right in the middle of it.
Software testers often find themselves in the middle of political battles between teams and company interests. It doesn’t have to be this way, though. We have the ability to make different choices and not fall victim to political gamesmanship in our organizations, but it takes effort, and it takes understanding of what we are able to do. A few of the most common political challenges project teams run into include; financial, influential and relational.
First and foremost, the biggest challenge that many software testers deal with is one of the money. I am not talking about how much a software tester earns by doing their job, I’m referring to the fact that, to many, software testing is a cost. It’s a tax of doing business, so in many organizations, that’s how we’re viewed. We’re the Sheriff of Nottingham preventing software from going out the door until we have received our share of the take. Does that sound ludicrous? I assure you it is not. I have seen in many organizations over two decades where software testing is touted as being a “necessary evil,” a “cost center,” an entity that we need to have just because “regulations require it.” I would totally understand if you were to think this was just overblown hyperbole, but no, I’ve seen a fair amount of back biting against testers because they are seen as not providing revenue value to a team. That’s a political game. The political message is to try to minimize the value of the testing team to the organization, to make it appear that they offer little in the way of value.
What do we do in these circumstances? The most important is to not give in to the rhetoric. It’s also important that we frame our own story so that people can genuinely understand what it is that we do. What do we provide to a development team? We provide information as to the state of the product and the overall health of the system we are working on. Think to yourselves, how could we better tell our own story? What would it take to help convince others of our inherent value to the process of our organizations?
About a decade ago, I had the interesting situation where one discovery changed opinions from why I was working with a particular group towards appreciating the way I safeguarded revenues with a single discovery. At the time, I was working on a capacitance touch device that was being included with a variety of laptops. If you have ever used a touch pad, chances are you are using a capacitance touch device. Smart phone screens work on the same principal. Back when I was doing a variety of tests on these devices, we were looking at a series of devices with a number of different top sheet. They varied in color to match a variety of system case, with a few that were formulate to look metallic. As I was performing a number of tests, there seemed to be an unusual variance with the sample set we received with a metallic finish. It was difficult to pin down exactly what was happening, but with some focused effort and comparing a broad sample set of different coverings, including those that were not metallic in appearance, we were able to isolate the unusual behavior.
It turned out that a sample set hat we were working with used crushed mica as part of the mix that gave it its metallic shine. The concentration of mica was acting as a partial insulator, holding the charge longer than those devices that didn’t have this mica in its covering. Seems like a trivial detail, but by driving down and determining the problem, we were able to stop a large scale shipment and order that would have gone out and exhibited frustrating problems for users. Just by finding that particular problem, I was able to justify several times my annual salary as a tester, because I was able to prevent a large scale problem that could have cost considerably more to resolve later on if it were released to production.
Another area where politics comes into play is when there is something to lose. Often that something is influence. In the government political arena, this is often called “political capital”, and it’s the idea that, as long as person has influence or can make the case that their way is the best way, they can chart the direction and the momentum of a group. this in and of itself isn’t a bad thing, and usually, when an organization, team or individual makes good decisions that prove to be either helpful or lucrative, this is often a good thing. Good feelings abound. The flip side is that political capital can also lose ground during periods of challenge, controversy or decisions that don’t pan out as well. It’s during these times that we start to see resistance and infighting, people looking to “protect what’s theirs” for their own sake, rather than what would be the best for the entire organization.
This is classic human nature, and it is where politics can get ugly. It’s less about good governance at this point, it’s about protection and security. Often it turns out to be a false sense of both. Choices to adopt tools or practices can become battlegrounds. When one part of an organization sees a process as being a way to get out of a hole, and another sees the same process as being an exercise in futility, what is informing those view points? Is it that there is a real disagreement in the way that the process or tool will be utilized or implemented, or is there a fear that someone will lose influence if that process or tool is put in place?
I’ve seen this happen in the commercial tool space for years, and in some ways, the open source variety of tools stands as a significant threat to many manufacturer’s of proprietary tools. In some environments, there were a number of tool choices made not just because there was a perceived need, but because the influencers and the sales people were friends. I’ve seen a number of tools that were championed because of the fact that a particular developer or tester had a relationship with the tool vendor.
I’ve also seen a number of tool choices made because a particular developer worked on or was a contributor to an open source product. On the surface, this doesn’t really seem like a big deal, but over time, choices that were made because of “cronyism” came back to bite us. I remember well a company that put a lot of stock in a very expensive tool that offered “record and playback simplicity” as its major selling point. Of course, it turned out that the maintenance required to keep that model working far outweighed the perceived simplicity. As that realization started to come to light, several of the decision makers doubled down and fought against looking for other solutions. Why? Because their own prestige and credibility were tied into these decisions, and having to admit they were wrong, or placed their faith too greatly in a given area would cause friction. Ultimately the tool was discontinued, but not without some bad feelings an a lot of email.
If this sounds familiar to you, you are not alone. As software testers, we very often have to be the bearers of bad news, and we have to be realists about what a process can and cannot do. People will be disappointed in our decisions. They will be frustrated by the fact that we will not always have the same glowing optimism. We need to make sure, though, that we are focusing on the core value in these decisions. Do we object (or champion) a process because of the actual value to the organization, or because we fear the alternative and what it will mean to our positions?
Another source of “realpolitik” within organizations comes from personal relationships. This is the most tricky, in the sense that those relationships often go outside of the boundaries of organizations. If two or three people are close friends and interact regularly with one another, that can bias decisions and ideas/ideals away from the rational and logical and move it into the emotional and personal. If you are close friends with individuals, that friendship can often color your perceptions of difficult situations. Do we side with our friends, or do we side with the reality of a situation? As a detached observer, it seems obvious. We would never compromise our integrity of our positions just to help a friend. We say that, but often, we find ourselves siding with those we have a personal relationship with *because* we have a personal relationship there, and an unpopular or difficult decision can influence that relationship. Detached logic would say “well, we mustn’t let personal feelings get in the way of making sound and intelligent decisions” but that’s easier said than done in many cases.
So what can we do? First, we have to realize that we don’t live in vacuums; we do have relationships with the people we work and interact with, and those relationships will often be the cause of real political friction in an organization. In these cases, it is best to be up front and realize that we may have to make choices that go against relationships, against friendships, not because we want to be hurtful or side against our friends, but because we want to do something more important. We want to preserve the integrity of the work that we do, and we want to make sure that that integrity helps the organization make sound decisions that will benefit everyone. Recognizing a relationship bias and dealing with it openly and candidly can go a long way in this process.
One of the prime examples that I remember best was when I worked with Tracker Corp., a company that made legal software around Immigration law. The company is actually an off shoot of a legal practice in San Francisco, and in many ways, our core client was, you guessed it, the law firm that was the initial user of our product. Sounds great, but what happens when you try to market your product to other legal firms? In one way, it’s easy because we can say “look, we are tied to a major law firm that actively uses this product.” At the same time, competitors said “now wait a minute. Do you feel comfortable with the fact that this law firm has access to the other company’s sales records? Do you want to have your business poached by this firm, just because you are using this product?”
For many years, we made few sales into our immediate market area in the San Francisco Bay Area because many felt that this relationship was both unusual and had a potential to be abused. The criticism was also unfounded, since we had separate business teams and significant firewalls in place to prevent undue influence. What we ended up doing was making sure that it was clear to all concerned that the two companies, while they were spawned from the same group, acted independently and did not share key pieces of information. It took some time to convince businesses of this fact, but doing that went a long way towards helping us open up and encourage local firms to use our products, more so than if we were to just stand back and try to protect that relationship between our two companies.
Testers, we don’t live in a bubble. We don’t have the benefit of pure and clean processes to guide our actions at all times. Making software is a sticky, messy and challenging endeavor, with many different factions that want different things. Those wants and needs will bring up controversies and differences of opinion, differences in approach, and differences in desired outcomes. Whenever that happens, there will be politics. Software testing is not immune to those political maneuverings, but with some careful consideration and awareness, we do have the ability to help mitigate and reduce the political pressures on the work that we do. Focus less on individuals and details but more on the results and objectives. Let the data do the speaking for you, measure the process and the outcomes. This will reduce the political barriers and anecdotal opinions.