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. 아웃소싱은 당신이 달래는 고객이 되는 것을 의미하지는 않는다. 당신이 고객에게 선택권을 주게 되면, 고객은 비난할 필요가 적어지고, IT 조직은 달랠(자기를 꾹 눌러참을) 필요가 적어진다. 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. 다수의 성공적인 패턴1 조직들은 소프트웨어 엔지니어링 팀에 의한 경쟁 입찰을 기반으로 운영된다. 고객은 그들의 요구사항을 제출하고 다양한 팀들이 마치 외부의 컨설팅 펌처럼, 일거리를 위해서 그 입찰에 응한다. 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. 락인된 유지보수 상황에서 달래게 되는 것을 방지하려면, 관리자는 다음의 하나 혹은 둘 모두를 채택하여, 프로그래머를 괴롭히는 위험을 감수해야 한다: 할당을 회전(rotate)시키거나, 유지보수 팀을 만들거나. 이 두 전략 모두 어느 프로그래머도 어떤 시스템의 유일한 소유자가 되지 않도록 한다. 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. 관리자들이 가져온, 수년 동안 그들의 기술자들로부터 학대받아온 것에 대한 복수의 염원은 종종 패턴2 (반복) 조직으로의 비전으로 표현된다. 이것이 왜 1960년대에 포장된(packages) 방법론들이 그렇게 대중적이었는지에 대한 이유이다. 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. 복수에 대한 열망이 같았기 때문에, 많은 조직들이, 모든 사람이 프로그래머를 비난하는 대처 패턴을 가지게 되었다. 어떤 경우에는 프로그래머들이 반격했는데, 대개는 초이성적이거나 연관성 없음(irrelevant)이 되는 방법이었다. 이 두 가지 스타일은 오늘날 패턴2 문화에서 가장 일반적이다. 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. 모든 패턴2 조직이 이런 비일치적 패턴에 부합하는건 아니다. 몇몇 조직은 반복적인 방법으로 잘 동작한다. 관리자는 비난하지 않고, 기술 스탭은 비일치적으로 대응할 필요가 없다. 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. 패턴2 (반복) 조직 말고 다른 조직들에서는, 소프트웨어 시스템의 설계, 개발, 유지보수는 예민한(sensitive) 작업자를 필요로 하는, 매우 창의적인 작업이 될 수 있다. 그러한 상황에서는, 비난하기는 품질과 생산성에 기여할 수 있는 어떠한 기회도 파괴해버린다. 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. 비난하지 않는 조직의 핵심은 열려있음(개방성, openness)이다. 왜냐면 비난하기는 어둠 속에서 잘 자라기 때문이다. 열려있음은 오류의 적이고, 비난하기는 열려있음의 적이다. 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. 달래거나 비난하는 조직에서는, 관리자는 아마도 관리받는 사람들을 대면(engage)하지 않고 관리하려고 시도할 것이다. 그들이 대면하는 것을 회피하는 구체적인 방법은 그들이 선호하는 대처 스타일에 따라 다르다. 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. 비난하기는 몇 가지 방법으로 대면하기를 회피하기 위해 사용될 수 있다. 한 방법은, 규칙을 작성하거나 심지어 구현하는데 있어서, 자동화된 도구를 사용하는 것이다. 그러한 도구 안에 구현된 일반화된 비난은 종종 관련없는(irrelevant) 응답과 마주친다. 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. 비난하지 않으면서 규칙과 표준을 정착시키는 일치적인 접근 중 하나는, 스텝들의 지능과 전문성(professionalism)을 존중하면서 그들에게 선택지를 주는 것이다. A congruent approach to setting rules and standards avoids blaming, respects the intelligence and professionalism of the staff, and gives them choices.

7. 비난에 대한 한 가지 처방은, 사람들이 인적 자원(human resource) 이상의 무언가로서 서로를 알 수 있는 환경을 마련하는 것이다. 또 다른 처방은 아이키도(aikido)의 접근법인데, 비난하는 에너지를 반대하지 않고, 그것을 따라 흐르고, 조금 더 생산적인 방향으로 부드럽게 선회시키는 것이다. 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. 이메일은 누군가와 의사소통하기 원하는 초이성형 관리자에게 완벽한 매체이다. (그러한 관리자는 "누군가에게 의사소통하다"라고 말하기를 즐여할 것이다. "함께"라는 것을 무시하고. 단방향만이 충분하다고 믿는다.) 일치적인 관리자는 의사소통 방법에 다양한 선택지를 가진다. 그 선택은 일치성을 위한 self-other-context 판단을 적용함으로써 간단하게 이루어진다. 발신자와 수신자 사이의 성향의 차이를 충분히 고려하면서. 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. '악의적 모델'이나 '편집증 모델'은 누군가가 나를 해치려고 하기 때문에 상황이 잘못 흘러간다고 말한다. 상화을 재구성하는데 있어 이러한 방식들의 가장 나쁜 점은, '괴물 만들기 역동'을 통해 자기 충족(self-fullfilment)이 되는 경향이 있다는 것이다. 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.