Managing Teams Congruently

Managing Teams Congruently

Volume 6 of the Quality Software Series

by

Gerald M. Weinberg

CLICK HERE TO SKIP TO THE BEGINNING

SMASHWORDS EDITION

PUBLISHED BY:

Gerald M. Weinberg on Smashwords

Managing Teams Congruently

Copyright © 2011 by Gerald M. Weinberg

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.

Smashwords Edition License Notes

This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.

Contents

Part I. Achieving Congruent Management

Chapter 1. Curing the Addiction to Incongruence

Chapter 2. Ending the Placating Addiction

Chapter 3. Ending the Blaming Addiction

Chapter 4. Engaging the Other

Chapter 5. Reframing the Context

Chapter 6. Informative Feedback

Part II. Managing the Team Context

Chapter 7. Why Teams?

Chapter 8. Growing Teams

Chapter 9. Managing in a Team Environment

Chapter 10. Starting and Ending Teams

Part III. Epilogue

Appendix A: The Diagram of Effects

Appendix B: The Software Engineering Cultural Patterns

Appendix C. The Satir Interaction Model

Appendix D. Control Models

Appendix E. The Three Observer Positions

FURTHER READING

Part I. Achieving Congruent Management

Keep good natured ... no matter what you find ... you did not invent life, so do not hold yourself responsible for what life does to you; decline to lay blame on anyone. - Hugh Mearns

Who was that masked man? The townspeople never knew who the Lone Ranger was, but fans of the show knew that his career as the masked defender of justice began in tragedy. He and his fellow Texas Rangers were ambushed by a gang of outlaws. He was the only one to escape with his life. He could have spent the rest of his life playing the victim, but instead he responded by building a new and more effective role for himself. The rest is (fictional) history—how the Wild West was tamed.

It's worth noting that the Lone Ranger possessed no secret weapon. The technology available to him was precisely what was available to the guys in the black hats. The difference was in the way he used his technology—and didn't use it. The typical bad guy had only one way to solve problems of control—namely, to gun somebody down. In remarkably few episodes did the Masked Man ever use his hardware, and then not to kill, but to disable the hardware of his opponent.

The Lone Ranger won the battle of Good over Evil because he had many behaviors at his disposal. He was clever, skilled with his hardware, persuasive, and, most of all, congruent. He never fired his gun in anger, or hatred, or revenge.

When the history of software engineering is written, the story will be the same: Thousands of individuals will respond to failure by playing victim, by pouring on hardware, or by attacking others. Only a few will respond congruently, creating new and more effective roles, and taming the Wild Profession.

Chapter 1. Curing the Addiction to Incongruence

An ounce of application is worth a ton of abstraction. - Booker T. Washington

Why do so many people respond incongruently in so many situations? For the most part, they continue to behave incongruently because they've become addicted to such behavior. So, if we're to improve the software professions, we'll need to know how to lessen incongruence—ideally, to cure it completely. This won't be easy.

Addictions are notoriously difficult to cure because most people don't recognize an addiction. Even if they do recognize it, they fail to understand its dynamic. (Figure A-1, in Appendix A, shows a diagram of effects of the generalized addiction cycle.) These failures lead to the belief in several ineffective methods of curing the addiction. This chapter examines those failures and offers a practical method of cure.

1.1 Force the Addict to Stop

The simplest idea about curing addiction to X is to stop the use of X, under the belief that X causes the addiction. X does not cause the addiction; the addiction dynamic causes the addiction. We know that's true because not everyone who is exposed to X becomes an addict. Take morphine addiction, for instance. Many people are exposed to morphine in hospitals and don't become addicted, because they have other ways of dealing with the various pains of their lives. Only those people who are inclined to believe (for personal, economic, cultural, or other reasons) that there is only one magical way to cure life's problems—only those people are likely to become morphine addicts.

The same is true, say, for the addiction to omitting various forms of testing (such as, technical reviews) to push the schedule. The only managers who become addicted to this practice are those who don't understand what the omitted testing would do for them, plus those managers who have no effective alternate ways of dealing with a schedule delay.

So, why not just forbid the skipping of planned tests? The biggest reason why not: there's absolutely no evidence that prohibition works, and lots of evidence that it doesn't. Sometimes it doesn't work because it's impossible to enforce the prohibition, as the entire population of the United States saw when alcohol was prohibited.

As Figure 1-1 shows, attempts to prohibit X lead the addict to make greater and greater attempts to do X. If the prohibition is strong enough, then the addict may not succeed in doing X, but the strength of the belief in X is unchanged. The addict is still addicted, and as soon as a weak spot in the prohibition appears, the addict will do X again.

In the case where X is skipping of planned testing, the addict might try to make up the schedule by faking the records to show that skipped testing was not skipped at all. Skipping necessary testing always leads to buggier products, which eventually leads to punishing the addict for ineffective testing. Now the addict is in even more pain, and thus more tempted to speed up the next delivery by skipping more testing.

Or perhaps the addict manages to move to a new position and avoid responsibility for the buggy product. In that case, X worked for the addict, which strengthens the belief in X.

So, either the pain increases or the faith in the incongruent practice increases—or both. None of this looks like a cure.

Figure 1-1. The simplest idea for stopping an addiction to X is prohibiting the use of X. This may lead to success or failure, but it always leads the addict to increasing efforts to do X because nothing is done about the long-range pain. If the prohibition works, the addiction may not grow stronger, but neither does it grow weaker. If it doesn't work, the addiction grows stronger, and new methods of evading the prohibition of X may now be learned.

Prohibition then cannot stop addiction, though at best it may stop new people from becoming addicts. Nevertheless, in a work situation, we may not care if the person or persons stay addicted as long as they cannot practice the behavior. For example, the prohibition of code-patching can be absolutely enforced with an appropriate configuration management system. When such a system is first introduced, programmers who are addicted to patching invariably try dozens of ingenious ways to beat the prohibition. If there's a crack, they will surely find it. If not, they'll eventually find that they may as well work within the system, albeit grudgingly. Their belief system remains unchanged, though, and given the slightest chance, they'll slip right back into the old behaviors.

Because the existing addicts will try harder and harder to beat the prohibition, the cost of this way of stopping the behavior is at least an increase in policing activity, with the accompanying deterioration in the general climate. Nevertheless, in circumstances like patch prevention with configuration management, the benefit can be worth the cost.

In other circumstances, however, it's simply not possible to obtain such absolute prevention. For instance, many software engineers are addicted to fiddling with software tools to the point where it interferes with their productive work. They are not addicted to tools, but to the overuse of tools. Because tools are a necessity for programming, there's no conceivable way management can stop these tool addicts from having access to their addiction.

At its worst, prohibition creates a class of people who profit from helping addicts beat the prohibition. This class of people then grows and recruits more addicts. A case in point is the tool vendors, who have a legitimate function, but who also may have no scruples about pandering to tool-based addictions. Why else would we find that 70 percent of purchased software tools are never used productively, yet few vendors will give their customers a refund for a returned tool?

1.2 Punishment

Some people believe they can cure an addiction by punishing the addict each time X is used. For example, upper management may criticize a middle manager for abusing employees. In this case, of course, the punishment must not be done in an abusive way, lest it simply reinforce the behavior it's designed to stop. Abusing only confirms the model and makes the abuser more abusive. The abuser simply tries harder not to get caught the next time—to do the abuse in private, accompanied by threats to employees if they inform upper management. Another approach is to shift the abuse elsewhere, like taking it home and punishing the spouse, the children, or the dog.

If the punishment can really be done every time that X is done, we get the dynamic of Figure 1-2. The punishment (negative reinforcement), Y, is added every time X is used; Y causes pain, so using X causes an increase in painful symptoms. Since the deep belief in the efficacy of X is not diminished, however, the only response to this increased pain is to do X again. The abusive manager will continue to abuse employees, even while saying, I don't know what came over me. I couldn't help myself, but I'll try harder next time.

Figure 1-2. Another way to attempt to cure the addiction is to attach a punishment (negative reinforcement), Y, to X in such a way that it cannot be avoided any time X is used. In this case, the addiction doesn't grow stronger, but it doesn't grow weaker either, as the conviction remains strong: If only I could get X with Y removed, I would feel better. Also, if Y is painful, it may add to the existing misery, thus increasing the temptation to do X, eventually leading to enough pain to cause a breakdown.

The manager keeps abusing, thus being punished by upper management. The short cycle of pain continues to build up until something breaks. Upper management may give up, turn irrelevant, and fire the manager. Or they may stop punishing and become superreasonable, saying, That's just the way some people are. Besides, it's not that bad, and, after all, we are getting results.

If upper management sticks with Y, and the manager's abuse grows stronger, then perhaps the abused employees will all leave, causing the work to fail. More likely, though, only a few employees will actually quit. Most of them will simply continue to undermine the abusive manager. Eventually, the manager will suffer some sort of physical, mental, or social breakdown, like getting ulcers or a heart attack, suffering a nervous breakdown, or suddenly resigning.

1.3 Rescue

Because the pain of the addict is so visibly part of the dynamic, some people believe an addiction can be cured by relieving the pain—a placating, or rescuing strategy. Unfortunately, because X itself is causing the pain, regardless of the original cause, you cannot use this rescuing strategy on the cause but only on the symptoms. The rescuer attempts to provide symptomatic relief, but can only succeed if the relief is generated from a dynamic that's more powerful than the long-range cycle of the addiction.

Figure 1-3. The rescuer tries to help the addict by relieving the pain generated in the long-term cycle. This intervention can succeed if the dynamic of the rescuer is more powerful than the long-term cycle's dynamic, but then the addict can become addicted to the rescuer. Usually, though, the rescuer or the addict breaks down because the rescuer cannot continue to match the escalating pain from the long-term cycle.

Sometimes, it is actually possible to create a relief dynamic that's more powerful. In the nineteenth century, for example, heroin was put into use as a cure for morphine addiction, and because heroin was more powerful, it was successful at ending morphine addiction as long as heroin was available. Of course, the morphine addiction then became a heroin addiction, which doesn't seem to be much progress. This replacement dynamic is was repeated in the twentieth century with the use of methadone. And, oh yes, morphine itself was originally used as a cure for opium addiction.

In the software world, FORTRAN was put forth as a cure for the addiction to assembly language. COBOL was designed to eliminate managers' dependence on programmers, since executives would be able to write their own code. Spreadsheets were going to replace COBOL, but now many executives spend more time fiddling with their spreadsheets than doing executive-type work. Indeed, weren't PCs going to cure the addiction to mainframes?

In most cases, however, replacement does not occur because the rescuer cannot develop a sufficiently strong relief dynamic. The rescue attempts merely suppress the painful symptoms in the short run, but require greater