QSM: Volume 3.2: Managing Teams Congruently

Part I. 일치적인 관리 달성하기 (Achieving Congruent Management)

Chapter 1. 비일치성 중독을 치료하기 (Curing the Addiction to Incongruence)

Summary

1. Addictions are notoriously difficult to cure because most people don't recognize an addiction in the first place, and don't understand its dynamic in the second. These failures lead to the belief in several ineffective methods of curing the addiction.
2. The simplest idea for curing an addiction to X is to prohibit the use of X, under the belief that X causes the addiction. But X does not cause the addiction; the addiction dynamic "causes" the addiction. There's no evidence that simple prohibition works, and lots of evidence that it doesn't.
3. In a work situation, we may not care if people 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. The addicts may struggle to find a way around the system, but new people never have the opportunity to become addicted.
4. The negative reinforcement model suggests that you can cure an addiction by punishing the addict each time X is used. If done perfectly, negative reinforcement doesn't cure the addiction, but eventually leads to something breaking down, and not always the addict.
5. Some people believe you can cure addiction by relieving the pain—a placating, or rescue strategy. In most cases, the rescue attempts only hold down the painful symptoms in the short run, but require greater and greater efforts until something eventually breaks down.
6. In other cases, the rescue attempt leads the addict to replace the addiction to X with an addiction to the rescuer. The rescuer then becomes locked into an addiction to rescuing, sometimes called co-dependency.
7. A cure that works is to use the Principle of Addition: Offer an alternative solution (Z) that's superior to X. In order to have the alternative way accepted by an addict, you must do three things: prohibit X; provide an alternative (Z) that truly works; and soften the short-term pain, if necessary, but not with X.

Chapter 2. 회유 중독 끝내기 (Ending the Placating Addiction)

Summary

1. Most of the ineffective Pattern 1 (Variable) cultures are placating cultures in which managers are afraid to ask questions or take positions.
2. This Variable placating pattern is a remnant of the earliest days of computing, when expensive, inflexible machines gave technicians job security and customers and managers were afraid of any technician who seemed to be able to make the machine obey.
3. Placating organizations of this type produced low quality because customers were afraid to ask for what they wanted, for fear of offending the programmer or the entire IT organization. The power of the programmer in this environment corrupted many programmers and gave them a (deserved) reputation for arrogance.
4. As soon as a few cheap alternatives arrived on the scene, customers rebelled against the arrogance of their IT organizations. But they often found their entire business balanced on the shoulders of one or a few maintenance programmers, and nobody else knew enough about a few life-critical systems to risk offending them.
5. Placating occurs when self-esteem is low. Raising self-esteem will help to block placating, but in itself cannot prevent it. To prohibit placating, you must give customers alternative sources of services.
6. Internal IT managers dread outsourcing, but, contrary to these trepidations, outsourcing may be the best thing that ever happened and customer alternatives need not be limited to outsourcing.
7. Outsourcing does not mean you need to placate customers. When you give a customer choices, the customer has less need to blame, so the IT organization has less need to placate.
8. A number of successful Pattern 1 organizations operate on the basis of competitive bidding for jobs by software engineering teams. Customers post their requirements and various teams bid for their jobs, much as if they were external consulting firms.
9. To prevent placating in the locked-in maintenance situation, the manager must risk offending the programmer by adopting one or both of the following tactics: either rotate assignments or create maintenance teams. Both these tactics ensure that no programmer is the sole owner of any system.

Chapter 3. 비난 중독 끝내기 (Ending the Blaming Addiction)

Summary

1. Substituting information for blame provides a substantial advance for software engineering management, especially in those organizations addicted to blaming behavior.
2. To eradicate blaming behavior from their organization at the same time they improve the software product, managers must learn congruent ways to provide necessary corrective feedback.
3. Perhaps the easiest way for managers to err in response to blaming behavior is to slip into blaming back. Blaming motivates people to find ways to avoid being blamed.
4. If programmers get beaten for faults in their programs, they try hard to conceal faults or to direct the blame for the faults onto someone else. Most of the continuing conflict between testing and development arises as a response to a climate of blame.
5. Managers' wish for revenge for years of abuse from their techies was often expressed as a vision of the Pattern 2 (Routine) organization. That's why in the 1960s, packaged methodologies were so popular.
6. The same desire for revenge resulted in many organizations with a coping pattern in which everybody blamed the programmers. In some cases, the programmers fought back, usually by being either superreasonable or irrelevant. These two styles are the most common Pattern 2 cultures of today.
7. Not all Pattern 2 organizations fit these incongruent patterns. Some organizations work well in a routine fashion. Managers don't blame and the technical staff need not respond incongruently.
8. In organizations other than Pattern 2 (Routine) organizations, the design, development, and maintenance of software systems can be highly creative work, requiring sensitive workers. In such situations, blaming destroys any chance at quality and productivity.
9. There are two kinds of pain we may feel when we are blamed. The pain of blame is the pain of feeling judged and found inadequate. The pain of recognition is simply the cost of getting new information.
10. To deliver criticism in a congruent way without losing its significance, I simply preface the criticism with a statement about myself and a statement about the context. Congruence works. It doesn't always work, but it works more often than any incongruent strategy. Moreover, it doesn't always work as fast as I like, but in the end, it saves a lot of time.
11. The key to a non-blaming organization is openness, since blame thrives in the dark. Openness is the enemy of error, and blame is the enemy of openness.
12. Blaming is based on the exclusion of the other person from the interaction. Thus, blaming cannot survive among people who see each other fully in their humanness. Anything that gets people interacting on a person-to-person basis rather than as boss to subordinate tends to prevent blaming behavior.

Chapter 4. 다른 사람들과 마주하기 (Engaging the Other)

Summary

1. In placating and blaming organizations, managers attempt to manage without engaging the people supposedly being managed. The particular way they avoid engaging depends upon their favored coping style.
2. In a placating organization, the lack of engagement is deeply rooted and appears in many guises. For instance, much placating is hidden under the label of compromise.
3. By building small, frequent checkpoints into interactions with brilliant employees, a manager has a chance to verify the usability of brilliant ideas before becoming overcommitted to something inconsistent with the project's goals. Placating managers, however, will undermine this approach.
4. To end placating behavior, you must bring the placater's self back into the equation. This can sometimes be done by creating a double bind: If you placate in one direction, you won't be able to placate in the other, so in either case, you'll be unable to be the perfect placater. Another form of double bind is, "If you want to placate me, you have to stop placating me!"
5. Blaming can also be used to avoid engagement in a number of ways. One way is to create rules and even to implement them in automated tools. The generalized blaming implemented in such tools is often met with an irrelevant response.
6. A congruent approach to setting rules and standards avoids blaming, respects the intelligence and professionalism of the staff, and gives them choices.
7. One prescription for blaming is to arrange circumstances in which people can come to know one another as something more than human resources. Another prescription is the Aikido approach of never opposing blaming energy head to head, but flowing with it, then diverting it gently in a more productive direction.
8. Superreasonable managers often attempt to set the context for a project or organization once and for all when they give an inspiring speech, issue a vision paper, or publish a strategic plan. If they wish to be effective, they must break their communications into small, relevant feedback.
9. E-mail is the perfect medium for the superreasonable manager who wants to communicate with someone. (Such a manager would likely say "communicate to someone," ignoring the "comm," believing that only one direction is necessary.) The congruent manager has many choices of communication methods. The choice is easily made by applying the self-other-context test for congruence, as well as taking note of personality differences between the sender and the recipient.
10. Coping styles out of touch with the context (loving, hating, and irrelevant) have a tendency to be self-correcting in an organizational environment. These coping styles invariably lead to costly errors. No organizational culture based on being out of touch with the context can long endure, unless subsidized by the wealth of a larger organization.
11. Irrelevant managers keep busy doing irrelevant or unimportant things, or things they should be delegating to others. For instance, when giving performance appraisals, managers appear to be doing management work, but are simply making trouble.
12. Lovers are best left alone, to let nature take its course. Love doesn't last, but hate can gnaw the entrails of an organization for a long, long time. The clue to handling blood feuds is to confront the participants with the missing context, but without placating.

Chapter 5. 맥락에 대한 관점을 새롭게 하기 (Reframing the Context)

Summary

1. One of the manager's primary jobs is to set—either by words or actions—the context in which interactions take place and work is accomplished. In real-world situations, there are so many possible ways of looking at the same context that there are probably an infinite number of ways to reframe the situation.
2. Frames can be in space or time. They can be changed by changing scale, again, in space or time. Frames can also be in type: Is it a thing or a model of a thing or a model of a model of a thing?
3. Another important job of the software engineering manager is to keep everybody in the organization working in the same frame, or at least compatible frames. This is done almost exclusively through the use of language, a system of symbols. Much of management action in the setting context must be directed toward reframing symbolic communication, to achieve stability by converting or harnessing the nonlinearity of symbols.
4. The context may be set through the use of presuppositions, either positively or negatively. The strongest presuppositions are covert. Managers who don't notice the presuppositions in their speech will continue to be mystified by seemingly incongruent reactions.
5. The implicit mental models from which we make meaning set a hidden context that may differ from person to person. These models often determine the surprising character of an interaction because each person is operating in a different frame, unknown to the others.
6. The Helpful Model says that no matter how it looks, everyone is trying to be helpful. Even if you're dealing with people who are quite obviously being unhelpful, reframing the situation as if they were being helpful can improve the situation.
7. The Malice Model or Paranoid Model says things are going wrong because somebody is trying to hurt me. The worst thing about this way of reframing the situation is that it tends to become self-fulfilling, through the Monsterizing Dynamic.
8. The Stupid Model says you should never attribute to maliciousness that which can otherwise be attributed to stupidity—a gentler reframe, but somewhat short of the Helpful Model.
9. Culture makes language, then language makes culture, which is certainly true in software engineering cultures. Organizations using bug language develop and maintain software in a different way than those using fault language.
10. When someone speaks incongruently, you can move the interaction toward congruence by inserting missing self-other-context elements.
11. Reframing gives you a powerful tool when you find yourself being criticized and don't know how to respond. The key is to frame the situation from a distance—from the third observer position. A similar technique is useful when someone is throwing a temper tantrum.
12. Reframing is especially helpful in handling perfection beliefs, especially your own.

Chapter 6. 정보 피드백 (Informative Feedback)

Summary

1. If a manager is to manage congruently, each interaction must balance the self, other, and context. The best way to do accomplish this ideal result is to concentrate on improving the flow of information, making the effort to create a small increment of correct information out of each interaction.
2. Both my praising and my blaming presuppose that I am someone entitled to do so, that I am the boss. They supply a disguised context behind which a frightened self can hide.
3. "Feedback," as used in management texts, has several different definitions. One of the most common is "I am the boss, and I'm going to demonstrate my dominance over you by telling you what is right and wrong about you (mostly wrong)." When the giver is afraid to deal with people directly, the feedback may take on the meaning "I am manipulating you." Sometimes, the feedback is clearly intended to burn the receiver.
4. All of these forms fit the definition of feedback as information about past behavior delivered in the present which may or may not influence future behavior. Congruent feedback, however, is information you may not have, you may find useful, and you are free to use in any way that fits for you. Congruent feedback offers the best chance to improve a relationship or an organization.
5. Feedback always follows The Giver's Fact: No matter what it appears to be, feedback information is almost totally about the giver, not the receiver. It takes skill and hard work to provide feedback that actually contains other information.
6. Feedback comes in many forms: offering verbal statements, showing trust, offering a challenge, allowing freedom, showing feelings, listening empathically, and especially modeling desired behavior.
7. Simple, informative feedback can sometimes be a source of pain, which many managers fear to give. Often, the managers themselves have had painful experiences with feedback. They are ashamed to want it, afraid of a hook concealed within it, envious of the people to whom they're giving it, or merely unskilled from lack of practice.

Part II. 팀 맥락을 관리하기 (Managing the Team Context)

Chapter 7. 왜 팀인가? (Why Teams?)

Summary

1. Each temperament finds teamwork satisfying, but each for a different reason. The NTs, for instance, find great satisfaction in the quality that a team can produce. The SJs especially like the efficiency of well-functioning teams, while the SPs really enjoy the team as a crisis management tool.
2. The NFs particularly like teams. They like the communication, excitement, and hope generated by teamwork. They especially like the way the team fosters the growth of its members.
3. Fault location teams are easy to form and easy to bring quickly to a productive state because the errors missed by two people will be much fewer than missed by either one.
4. Comperation, for competitive cooperation, is a normal team mode. One example is a mild, friendly competition to see who can locate a problem first. Super-teams, composed of representatives from other teams, can be another form of comperation. The super-team meets to tackle the most serious problems, and super-team members bring solved problems back to their daily meetings, so that everyone shares their solution methods.
5. Teams also excel at problems when the combined set of solution ideas is bigger than any one member could provide. Technical reviews of proposed fault resolutions prevent surprising side effects. A properly structured team is better at anticipating side effects than any individual can be because of this combining of ideas.
6. Both tests and reviews work on product improvement, but reviews also work on process improvement. Technical reviews are usually the first and easiest method of process improvement to introduce into Pattern 1 and Pattern 2 organizations.
7. The manager can influence both product and process quality by selling the idea of scheduling the reviews as early as possible. Although some reviews may lead to throwing away the product, they yield great information about the process.
8. A most striking effect of technical reviews (when used in combination with well-designed on-line testing) is the way they reduce variability. More conventionally, reviews and machine tests are used to improve quality and consequently reduce subsequent testing time.
9. Even more important for managers, reviews reduce variability in quality and subsequent testing time. Less variation in the number of faults shipped to system test mean more predictable system test time, which again means better manageability.
10. In Pattern 3 (Steering) Organizations, managers begin concentrating on process management, and spend a great deal of time creating and controlling teams. The types of teams are limited only by the imagination of the manager and the work force.

Chapter 8. 성장하는 팀 (Growing Teams)

Summary

1. Once an organization experiences some of the power of teamwork, the climate may be favorable for introducing more permanent teams to deal with software maintenance and development.
2. Teams require a startup cost, and in many projects this startup process is so long the loss is never recovered during the life of the project. This argument favors better management of team formation.
3. Even if management were poor, the cost of team startup could be recovered by reusing the teams over a series of projects. Unfortunately, only the better software organizations seem to reuse their teams. Insecure managers tend to dissolve well-functioning teams.
4. Reusable components are the basic units in hardware and software development, and the software team is the basic design unit for software engineering processes. The manager's job is to create, nurture, and maintain the teams that can be configured and reconfigured into reliable, predictable projects.
5. Many managers don't notice well-performing maintenance teams, yet these are precisely the teams that are most reusable. Maintenance engineers gravitate to teams because they reduce the high risk of mistakes in maintaining living systems. Maintenance teams also remove the maintenance career trap, a situation created by poor management in which the engineers who maintain the most critical systems are the engineers most likely to leave.
6. What ineffective managers often call motivation and teamwork is not the same as the real meaning of those terms. To them, "teamwork" equals "everybody doing what I say, without question," and "motivation" equals "pressuring everybody to work hard under poor conditions."
7. Management by process improvement can be extended to management by team process improvement. This approach establishes teams and trains them in techniques for using the best from each member; analyzes the performance of the best teams and individuals to determine why they are doing so well; and develops systems of training and technical reviews for passing on these best processes.

Chapter 9. 팀 맥락에서 관리하기 (Managing in a Team Environment)

Summary

1. Many managers undermine team spirit by their high-and-mighty attitudes. Other managers unconsciously undermine their own efforts to reap the benefits of effective teams. The first group is hopeless, but the second can be helped by learning to become more congruent.
2. Perhaps the most frequent confusion about the manager's role in a team-based organization is between the manager and the team leader. The team leader is responsible for the technical task of the team. The manager is responsible for the nontechnical direction of two or more teams.
3. Seen from inside the team, the manager's role is to unburden the team leader by handling certain nontechnical tasks. Seen from the manager on the outside, the manager's role is to control the team in terms of the higher goals of the organization.
4. The number one way to build teams is to delegate challenging work. Challenge is an emotional reaction, influenced as much by the way the task is assigned as by the task itself. Each temperament, for instance, is challenged in a different way, so an effective leader has to reframe a challenge for each temperament.
5. Delegating is not as easy as it seems to non-managers, for several reasons. It's easy to be misunderstood, to use the wrong communication medium, to make mistakes, and to become defensive when things don't work out and people complain about what you did.
6. Managers make two mistakes concerning the amount of control they exert over internal team affairs: too much or too little. Pattern 1 managers tend to intervene too little, placating the team. Pattern 2 managers tend to overcorrect by intervening too much, blaming the team, often in the form of claiming to be better able to do the job themselves. Both placating and blaming usually stem from the manager's internal needs rather than the team's.
7. Well-functioning teams can be recognized by the behavior of their members. They make sure that everybody participates in decisions. They stay in touch with one another, and everyone feels the chance to contribute. They are united, and talk in terms of "we." They have fun. They rely on each others' individual strengths, and all do what they can that's best for the team. When they speak, they take care to be sure that everyone understands. They each feel strong and useful, but not out of proportion to their competence as a team. Finally, it's easy to monitor them, because they show how they are truly feeling.
8. You manage a team gently, using single incidents only to trigger a state of alertness for other signs. When you do make interventions, you use them as opportunities for team building and team problem solving.
9. It's easy for a manager to envy a well-functioning team. The cure is to emphasize the joys of successful management, and the part successful management plays in the team's success.
10. Attempts to reward a team can often backfire. Work with the team to find out what would truly reward them. Use the MOI model to determine what kind of intervention a team needs at any moment.
11. It's not the manager's job to punish people. It is the manager's job to arrange opportunities for people to learn. To do that, the manager may have to play Mother Duck, protecting the team from inappropriate influences from outside.
12. Performance appraisals can destroy team spirit. Avoid them if you can. If you can't, a more effective way is to ask the team to appraise the performance of each member. An external performance rating is obtained by multiplying the team's overall rating by the individual's rating as given by the team.

Chapter 10. 팀을 시작하고 끝내기 (Starting and Ending Teams)

Summary

1. The manager's job with respect to a team is to start it when a team is needed, leave it alone when it's working effectively, and stop it when it's not.
2. It's not a trivial management task to form a team during a crisis. If the organization is severely depressed, you may need a skilled facilitator in the first meetings of a new team. The composition of the team must ensure that everyone has some unique contribution.
3. A better starting point than a crisis for long-lived teams is using teams that have formed naturally in maintenance or development. The trick is not to dissolve them just because their project was completed successfully.
4. Existing teams in the organization can also be an impediment to change. They may see attempts to create special problem solving teams as a way of breaking up their ring of solidarity, or of placing blame on their team for not doing a better job.
5. A well-functioning team is the busy manager's biggest potential asset, if the manager lets the team do its work. A real team is much stronger than your typical manager, and not as likely to be intimidated by top brass. A real team's opinion is likely to carry a lot more weight.
6. Teams are less likely to panic when the project is late. Incongruent managers don't like to see other people remaining calm when they themselves are panicking, and often try to spread their panic to others. An experienced team, however, simply absorbs the manager's incongruence and most often has a calming effect.
7. One piece of unmanaged work injected from the outside can disrupt any amount of planned work. Teams can establish a specialist role to handle such disruptions, such as demonstrations of customers and management. In general, teams can do a better job of setting and meeting realistic priorities.
8. Teams can't handle every problem by themselves. There are times when a team member is unable to work with others and has to leave the team. Then it is the manager's job to intervene and change the composition of the team.
9. Perhaps the main impediment to successful teamwork is an individual's attitude that "Because it's mine, I won't let others touch it, or even see it" or, "If it's not my idea, it can't be the best idea." This closed attitude invariably leads to disaster in software, and must not be allowed to persist. A person may decide to change this attitude, but typically you have to exchange the person for someone else. Not everybody is cut out for the software business.
10. Sometimes teams become dysfunctional for no reason you can identify, or because of the involvement of several people. In those cases, the manager has to step in and break up the team, usually after putting the members on warning.
11. Once a manager has appointed a group of people, even in a crisis, it takes on a life of its own and may be hard to dissolve when needs change. Thus, you should avoid creating teams you cannot terminate if they become nonfunctional. When you do create temporary groups, give them a definite life span, after which they will have to justify their existence again.
12. Groups that seem to be dysfunctional may simply be providing a different function than you intended. Before you break up a group, try to determine what functions it serves.

Part III. Epilogue

..