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. X에 대한 중독을 치료하는 가장 간단한 아이디어는, X가 중독을 야기시킨다는 믿음에 따라, X의 사용을 금지하는 것이다. 하지만 X는 그 중독의 이유가 아니다; 중독의 역학(dynamics)이 중독의 원인이다. 단순한 금지가 효과가 있다는 근거는 없다. 그리고 그것이 동작하지 않는다는 증거는 많다. 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. 부정적 강화 모델은 X가 사용될 때마다 중독자를 처벌함으로써 중독을 치료할 수 있다고 제안한다. 완벽하게 이루어진다면, 부정적 강화는 중독을 치료하지 않고, 결국은 무언가 파괴하게 만들고, 그것은 항상 중독자만 파괴하지는 않는다. 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. 다른 경우에는 구조자가 X에 대한 중독을 구조자에 대한 중독으로 대체하도록 유도한다. 그렇게 되면 구조자는 구조하는 것에 중독된 상태에 빠져들게 된다. 이것은 때로 공동-의존이라고 부른다. 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. 효과가 있는 치료법은, 덧셈의 원칙을 사용하는 것이다: X보다 우월한 대안적인 솔루션 Z를 제공한다. 중독자에게 그 대안이 받아들여지게 하기 위해, 다음의 세 가지를 해야 한다: X를 금지하라; 정말로 효과가 있는 대안 Z를 제공하라; 그리고 필요하다면 단기 통증을 부드럽게 하되, X를 사용하지 않는다. 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. 대부분의 비효과적인 패턴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. 이러한 유형의 달래는 조직은 낮은 품질을 생산한다. 왜냐하면 고객들은 자칫 프로그래머나 IT 조직 전체에 불쾌감을 줄까봐 자기들이 원하는 것을 묻기를(요청하기를) 두려워하기 때문이다. 이런 환경에 있는 프로그래머의 힘은 많은 프로그래머를 오염시켰고, 그들에게 오만하다는 (받아 마땅한) 명성을 주었다. 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. 몇 가지 저렴한 대안이 현장에 도착하자마자, 고객들은 그들의 IT 조직의 오만함에 반기를 들었다. 하지만 그들은 종종 그들의 비즈니스 전체가 몇 명의 유지보수 프로그래머들의 어깨 위에 달려 있다는 것을 발견했고, 그 외에는 아무도 그들을 위협할 수도 있는 life-critical한 시스템에 대해 거의 아는 바가 없었다. 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. 내부 IT 관리자들은 아웃소싱을 두려워하지만, 이러한 불안과는 다르게 아웃소싱은 최고의 것이 될 수 있고, 이러한 고객 대안은 꼭 아웃소싱에 한정되지는 않는다. 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

Up to now, these Quality Software volumes have been a long journey for me—and perhaps for you. When I started, I imagined that the final volume would consist of a recipe for precisely what to do to create a quality software engineering organization—a recipe with ingredients such as CASE tools, project organization, training practices, testing techniques, and configuration management approaches. Along the way, I've discussed such ingredients, but I've never given the recipe. This was no mistake, but a conscious omission, because without a capable chef, a recipe is merely a mess of ingredients.

I'm now in the process of preparing additional volumes, under the general title of "Anticipating Change," with the full recipe. I have already seen that these first six volumes have influenced the number of capable chefs out there. I also know there are plenty of chefs who will make a mess, then blame me for giving them the wrong recipe.

I myself have certainly messed up some perfectly sound recipes for software engineering success. When I haven't felt good about myself, I've bullied people, ignored them, blamed them, blamed myself, run away from difficult situations, or buried my head in clouds of abstraction. Through all this, I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organizations, when I'm not able to be congruent. So, I work on that first, and that's what I hope you do.

Decades ago, I went into computing because I believed that computers could be a major factor in making a far better world. I've wavered at times, but I've never lost that vision. Perhaps I'm a naive dreamer, but I always felt that this better world would be created by people who were driven by similar vision. Unhappily, I've encountered many people who were driven by something else—personal gain, power over others, or perhaps simple meanness. I don't understand such people, I don't deal well with them, and I think they hurt our profession. No sense preaching, though, because they can surely sense that I have not been writing for them, and have left these pages long ago.

For the rest of you, there's an ancient story that sums up what I think you can accomplish through congruence, or, if you like, character. I think of this story whenever I'm a little down from a bout with one of those others—the greedy, the power hungry, or the mean-spirited. I'm sure I can't live up to the righteousness of its hero, Hsün Chü-po, yet it makes me feel that my attempts to improve my behavior will ultimately make a difference.

Hsün Chü-po Visits His Friend

Hsün Chü-po traveled a great distance to see his friend, who was stricken ill. It happened that at this time the prefecture came under attack by the Tartars.

"Death will soon claim me," his friend said to Chü-po. "Please leave while you may!"

"I've come a long way to see you," Chü-po replied, "and you ask me to leave? Is this proper conduct for Hsün Chü-po, to cast aside the principle of righteousness and run away, leaving his friend behind?"

Then the Tartars came, and they said to Chü-po, "Our great armies are here and the people have fled the land. What manner of man are you that dare to linger?"

"My friend lies ill, and I cannot endure the thought of leaving him," Chü-po answered. "Spare his life and take mine in its stead!"

At this, the Tartars marveled. "Indeed, we are iniquitous men who have come to the land of the righteous." So they gathered their troops and departed, and the prefecture was saved from destruction.

You, too, can be one person who makes a difference.