Find and Cultivate Allies

Prolog/Acknowledgement: 

The idea for this Pattern comes from personal experience although I am sure there must be many other writers who make a similar point.

Author, reviewer and revision dates: 

Created by John C. Thomas in May, 2018.

Abstract: 

Human beings are highly social beings by nature. We work more effectively in groups (for many tasks) and it’s also more pleasurable. In a group of any size and complexity, people will have a large variety of goals and values. To achieve a goal, including but not limited to change within the group itself, it is useful to make common cause with others within the larger group. Whenever it becomes useful to promote social change of any kind, it is important to seek out and then cultivate allies. You will achieve greater success, enjoy the process, and learn much.

Context: 

Complex problems and large problems can often only be solved by groups. Within a large group, there will be many sub-groups and individuals whose motivations, expertise, and values are partially different from those in other sub-groups or from those of other individuals. In order to achieve any kind of goal including but not limited to changes within the group itself, a great deal of knowledge must be brought to bear and a large number of actions will be required. Generally, an individual or a small group will not have the knowledge, power, or resources to take all of these actions.

The variety of goals, values, experiences, and scope of power of various individuals and subgroups within a larger group can be viewed as a resource. The interactions among such individuals be a source of creativity. In addition, in order to accomplish some goal, you may seek and find among these individuals and groups those whose goals are compatible with yours and whose power and resources allows them to do things you cannot do yourself.

Individuals are subject to a variety of perceptual and cognitive illusions and these may be exaggerated by being in a large group. Changing a group, team, organization, corporation, NGO may be even more difficult than changing an individual even if the change would benefit the group, team, organization, corporation or NGO. Within any organization, there come to be entrenched interests that are orthogonal to, or even antithetical to, the espoused purposes of the group.

Problem:

Over time, organizations eventually begin to behave in ways that are ineffective, inefficient, or even antithetical to their purpose. Whatever the cause, an individual who recognizes these infelicities in the organization will typically not, by acting alone, have the power to change them. Force of habit, custom, the culture, and the entrenched power of others will tend to make change by an individual extremely difficult or impossible despite their pointing out that the current way of doing things is counter-productive.

Forces:

• People who wield local power in an organization are often afraid that any change will weaken their power.

• Changing one part of the organization generally means that other parts must also change, at least slightly.

• What works best for an organization must necessarily change over time because of changes in personnel, society, technology, competition, the environment, and so on.

• Organizations typically codify the way they currently work by documenting procedures, providing training, incorporating current processes into software systems, floor layouts, and so on.

• Each person in an organization is typically rewarded according to the performance of a small area of the organization that centers on or near them.

* People within an organization of any size will exhibit large variations in knowledge, skill, values, goals, and the resources available to them.

* In many organizations, a valid reason for continuing to do X is simply to say, “That’s the way we’ve always done it.”

* It is not considered a valid reason for change from doing X to doing Y to simply say, “We’ve never done it this way before.”

* Organizations are therefore prone to continuing along a path long after it is a fruitful, ethical, or lawful path.

Solution:

If a person wishes to change how a large organization does things, they need to find and cultivate potential allies within the organization. Allies may be people who can be convinced that the change is best for something that is best for that individual, their department, the organization as a whole, for society or for life on earth. These allies will have crucial information, power, friends, or resources to help make the change possible.

Example: 

For two years, in the early 1980’s, I worked in the IBM Office of the Chief Scientist. My main mission was to get IBM as a whole to pay more attention to the usability of its products. No-one worked for me. I had no budget. I did, however, have the backing of the Chief Scientist, Lewis Branscomb. Among his powers, at the time, was the ability to “Non-Concur” with the proposed plans of other parts of IBM. This meant that if other IBM divisions did not have usability labs or adequate staff, the Chief Scientist could block the approval of those plans. Lewis himself was a great ally because he had a lot of personal credibility due to his brilliance. Having the power to block the plans of other divisions was also critical.

IBM at this time already had some Human Factors Labs who had done excellent work for years. However, there were large areas such as software that were mainly untested. In addition, most of IBM’s users were technical people and many of the usability tests had been done on other technical people. This had been appropriate but with the extension of computing into other areas of life, many of IBM’s “end users” were now people with little technical computer background. This included administrative assistants and clerks; even chemists, physicists, MD’s, lawyers and other people with advanced education found IBM products hard to use. None of these fairly new groups of users had typically used computers much or had been taught their use in their schooling.

I needed to find allies because the changes that were necessary to IBM were widespread. One important ally was already provided: Tom Wheeler had a similar position to mine within another corporate staff organization called “Engineering, Products, and Technology.” Tom could also get his boss to non-concur with the plans of divisions who were unwilling to “get on board” with the changes. But I needed more allies.

One obvious source of allies were the existing Human Factors Groups. Where they existed, they were typically staffed and managed by excellent people; however, they were often understaffed and often brought in near the end of the development cycle. In many cases, only their advice on “surface features” or documentation could be incorporated into the product. This was frustrating to them. They knew they could be more effective if they were brought in earlier. Often, this did happen, but typically because they had developed personal reputations and friendships (allies) within their organization. It was not mandated by the development process.

Who else would benefit from more usable IBM products? There’s a long list! A lot of “power” within IBM came from Sales and Marketing. The founder, Thomas J. Watson was himself primarily a sales and marketer. Most of the CEO’s had been from this function of the organization. Many in Sales and Marketing were beginning to see for themselves that IBM products were frustrating customers. Finding people within such organizations who were willing to stand up and “be counted” was critical. It was especially useful to find some allies in Europe who were on board with suggested changes. In many countries in Europe, there were various social and legal constraints that gave even more weight to having products that did not cause mental stress, repetitive motion injuries, eyestrain, hearing loss and so on.

In many parts of IBM, there were also “Product Assurance” organizations that required products to be tested before final release. In this case, two simple but crucial and fundamental changes needed to be made. Again, people who worked in Product Assurance wanted these changes to be made. First, we needed to convince development to work with Product Assurance earlier rather than later so that any problems would not be the cause of product announcement slippages (or ignored). Second, we needed to convince Product Assurance to test the procedures and documentation with people outside the development teams. Current practice was often for the Product Assurance people to watch people on the development team “follow” the documented process to ensure that it actually worked. The problem with this process is that language is ambiguous. The people on the development team already knew how to make the product work, so they would interpret every ambiguity in instructions in the “proper” way. IBM customers and users, however, would have no way of knowing how to resolve these ambiguities. Instead of making sure that the documentation was consistent with a successful set-up, the process was changed to see whether documentation actually resulted in a successful set-up when attempted by someone technically appropriate but outside the development team.

People within IBM product divisions did care about budgets. Adding human factors professionals to existing labs or, in some cases, actually setting up new labs, would obviously cost money. We needed to show that they would save money, net. Some of the human factors labs had collected convincing data indicating that many service calls done at IBM’s expense were not due to anything actually being wrong with the product but instead were because the usability of the product was so bad that customers assumed it must not be working correctly. In most cases, fixing the usability of products would save far more money than the additional cost of improving the products.

In some cases, developing allies was a fairly simple business. For example, IBM had a process for awarding faculty grants for academic research relevant to its technologies and products. These were awarded in various categories. Adding a category to deal with human-computer interaction required a single conversation with the person in charge of that program. Similarly, IBM awarded fellowships to promising graduate students in various categories of research. Again, adding the category of human-computer interaction resulted from a single conversation. It should be noted that the ease of doing that resulted much more from the fact that it was known throughout the company that usability was now deemed important and the fact that I worked for the well-respected Chief Scientist than from any particular cleverness on my part.

In at least one case, an ally “fell in my lap.” Part of how I operated was to visit IBM locations around the world and give a talk about the importance of usability for IBM’s success. Generally, these talks were well-received although that did not guarantee any success in getting people to change their behavior. When I gave the talk to the part of IBM that made displays, however, I got a completely hostile reaction. It was clear that the head of the division had somehow made up his mind before I started that it was complete nonsense. I had no success whatever. Only a few months later, the head of this division got an IBM display of his own. He couldn’t get it to work! He did a complete 180 and became an important supporter, through no fault of my own. (Of course, there may have been additional arm-twisting beyond my ken).

There were also two important, instructive, and inter-related failures in lining up my allies. First, it was very difficult to line up development managers. An IBM developer’s career depended on getting their product “out the door.” Not every product development effort that began resulted in a product being shipped. Once the product was shipped, the development manager was promoted and often went to another division. So, from the development manager’s perspective, the important thing was to get their product shipped. If it “bombed” after shipment, it wasn’t their problem. In order for the product to be shipped, it had to be forecast to make significant net revenue for IBM. No big surprise there! However, these predictions did not take into account actual sales, or the actual cost of sales, or the actual service costs, or even the actual production costs. The only thing that was really known were the development costs. So, for every additional dollar the development manager spent during development, there was one dollar added to the development costs, but also an additional dollar added to predicted service costs and predicted manufacturing costs. Moreover, there were an additional five dollars added to the predicted sales and marketing costs. If they spent an extra dollar doing usability tests, for example, it added not just one but eight dollars to estimated overall costs. Moreover, since IBM was in business to make a profit, an increase of 8 dollars in costs, meant an increase of nearly 20 dollars in projected price. This meant fewer predicted products sold.

In actuality, spending an additional dollar to improve usability of products should reduce service costs and sales and marketing costs. But that is not the formula that was used. The logic of the formula, corroborated by correlational data, was that bigger, more complex products had higher development costs and also had higher service, manufacturing and sales costs. When one compared a mainframe and a PC, this formula made sense. But when used as a decision tool by the development manager, it did not make sense. (By analogy, there is a strong correlation between the size of various species of mammals and their longevity. This, however, does not mean that you will live twice as long if you double your own body weight!).

Recall however, that the development manager’s career did not much depend on how successful the product was after release; it mainly depended on showing that they could get their product shipped. Development managers proved to be difficult to get “on board.” In some cases, despite the organizational pressures, some development managers did care about how the product did; were interested in making their products usable; did spent additional money to improve their product. Making such allies, however, relied on appealing to their personal pride of ownership or convincing them it was best for the company.

Some development managers suggested that perhaps I could get the Forecasters to change their formula so that they would be given credit for higher sales to balance the projected increase in price (and attendant reduction in sales volume forecasts). It would have been an excellent leverage point to have gotten the Forecasting function as an ally. I was not, however, sufficiently wise to accomplish this.

The organizational payoff matrix for the forecaster was quite skewed toward being conservative. If they used the existing formula and ended up thereby “killing” a product by reducing the sales forecast because of the money spent improving usability, no-one would ever find out that the forecaster might have erred. On the other hand, if I had convinced them by giving them evidence (which would necessarily be quite indirect) that the product, by virtue of its being more usable, would therefore sell many more units, there were at least two logical possibilities. First, I might be right and the product would be a success. The forecaster would have done the right thing and would keep their job (but not be likely to receive any special recognition, promotion, or raise). Second, I might be wrong (for a variety of reasons having nothing to do with usability such as unexpected competition or unexpected costs) and the product might tank. In that case, the company would lose a lot of money and the forecaster might well lose their job. While I occasionally found development managers I could convince to be allies because I could get them to value making the most excellent product over their own career, I never was able to gain any allies in the Forecasting function. In retrospect, I think I didn’t take sufficient time to discover the common ground that it would have taken to get them on board.

Resulting Context:

Finding allies will often enable the organization to change in ways that will benefit the organization as a whole and most of the individuals and sub-groups within it. If done with the best interests of the organization in mind, it should also increase internal mutual trust.

There is a related Anti-Pattern which is finding allies, not to change the organization in a positive way, but to subvert the organization. If, instead of trying to make IBM be more effective by making its products more usable, I had tried to ruin it by finding allies who, in the process of ruining IBM would also profit personally, that would have been highly unethical. Such a process, even if it ultimately failed, would decrease internal mutual trust and decrease the effectiveness of the organization. Of course, one could imagine that some competitor of IBM (or of a government or team) might try to destroy it from the inside out by favoring the promotion of those who would put their own interests ahead of the company or its customers. Finding allies is likely to be ethical when it is for the best interests of the overall organization and all its stakeholders and if is a known initiative (as was the case for improving the usability of IBM products).

References: 

https://gps.ucsd.edu/faculty-directory/lewis-branscomb.html

Branscomb, L. and Thomas, J. (1984). Ease of use: A system design challenge. IBM Systems Journal, 23 (3), pp. 224-235.

Thomas, J. (1984) Organizing for human factors. In Y. Vassilou (Ed.) Human factors and interactive computing systems. Norwood, NJ: Ablex.

Thomas, J.C. (1985). Human factors in IBM. Proceedings of the Human Factors Society 29th Annual Meeting.  Santa Monica, CA: Human Factors Society. 611-615. 

——————————————————

Author Page on Amazon: https://www.amazon.com/author/truthtable