고등학교때, 나는 1년간 음악 캠프에 다녔다. 한 오케스트라 리허설 중에 내 섹션은 특히 어려운 악절로 어려움을 겪었다. 차장이 그것에 대해 물었고, 나는 "걱정하지 마세요. 내일은 성공할거예요."라고 말했다. 그는 "알았어."라고 말하고 리허설을 계속했다. 다음날 우리는 실제로 그 구절을 배웠다.
... 일단 조직이 구축되면, 대인관계는 팀의 효율성에 긍정적이거나 부정적인 영향을 미친다.
✥ ✥ ✥
팀의 사람들이 서로를 신뢰하는 것이 중요하다. 그렇지 않으면 다른 어떤 것도 하기가 어려울 것이다.
커뮤니케이션은 모든 팀의 원활한 작업에 필수적이다; 예를 들어, 소프트웨어 개발자는 지속적으로 서로 대화해야 한다. 인터페이스, 빌드 및 테스트를 조정한다. 개인이 서로를 신뢰하지 않으면 의사소통이 원활하지 않다.
사람들이 서로를 신뢰하지 않으면 방어 모드에서 시간을 보낸다. 예를 들어, 내가 당신이 제 때에 특정 인터페이스를 제공할 수 없다고 믿으면, 나는 그것에 대한 코드를 작성하는데 길고 힘든 시간을 할애할 수 있고, 그것은 추가 작업과 시간을 소요한다.
설계 리뷰는 불신을 일으킬 수 있다. 너무나 자주, 설계 리뷰는 여러 리뷰어들 사이에서 누가 더 영리한지 보여주기 위한 콘테스트가 되고, 다른 설계자에게 유용한 제안을 제공하지 않는다. 한 가지 대안은, 사람들이 리뷰에서 훌륭한 사회적 행동을 취하도록 하는 것이지만, 그것은 그룹 토론에서 최고의 통찰력으로 이어지는 에너지 넘치는 토론을 방해한다.
조직에는 불신의 냄새가 나는 정책들이 있을 수도 있다: 누군가 프로젝트 베이스에 코드를 제출하도록 허가받으려면 여러 단계를 거쳐 고생해야 할 수도 있다.
그 의도와는 상관 없이, 신뢰나 불신에 대한 인식이 현실이다.
따라서:
분명하게 신뢰를 증명하는 일을 하라. 예를 들어, 관리자는 수행해야 하는 작업을 수행하도록 사람들을 제어하는 중앙 역할을 수행하기보다는, 자신이 조직의 편이라는 사실을 분명히 밝혀야 한다. 개발자가 프로세스를 제어할 수 있도록 가시적인 조치를 취하라.
여기서 핵심은, 행동이 가시적이고 분명해야 한다는 것이다. 특히 그들이 번거로운 규칙과 프로세스를 제거하는 경우에는 더욱. 내가 어떤 회사에 일하기 시작하기 직전에, 그 회사는 연구 개발 인력을 위한 시계(time clock)를 생략했다. 내 동료들은 그들이 가졌던 시계 박살내기 행사에 대해 친절하게 말했다.
✥ ✥ ✥
이것은, 자주 인용되는 "임파워먼트" 전략과는 다르다. 임파워먼트는 더 낮은 수준으로의 통제권을 의식적으로 포기하는 것이다. ('팀의 개방형 폐쇄 원칙'을 참조하라.) 신뢰의 공동체에서는, 일방적인 방향보다는 양자 합의에 의해 진전이 이루어진다. 사람들이 자신의 목소리가 있고 결정에 영향을 미친다고 느끼면, 결정을 내리는 사람들을 더 신뢰할 가능성이 높다. 마찬가지로, 그들은 자신에게 "주어진" 책임보다는 자신이 스스로 결정(committed)한 책임들에 더 반응적이 되는 경향이 있다. 사실, 누군가에게 책임감(responsibility)을 줄 수는 없다; 오직 의무(accountability)만 줄 수 있을 뿐이다. 책임감은 주어지지 않는다, (스스로) 취하는 것이다. 관리자가 할 수 있는 가장 사기를 떨어뜨리는 일 중 하나는 책임감(responsibility)이 없는 상태에서 의무(accountability)를 주는 것이다.
프로젝트 관리 패턴 언어의 OrgPatterns/Size the Schedule에서 확장되는 프로젝트 계획을 배치하려면 고객과 모든 팀 구성권 간의 신뢰가 필요하다. 역할 차별화도 마찬가지다; OrgPatterns/Size the Organization 및 점진적 성장 패턴 언어의 하위 패턴과 같이, 모든 사람에게 자부심과 개성을 부여하면 신뢰에 기여할 수 있다. OrgPatterns/Few Roles로 작게 시작하여 신뢰 구축을 시작하고, 이 원칙이 조직적 스타일 패턴 언어를 안내하도록 하라. 사람들이 방어적으로 일하지 못하도록 하려면 팀 정신이 필요하다. 이것은 진정한 OrgPatterns/Architect Controls Product 및 사람 및 코드 패턴 언어와 관련된 하위 패턴이다.
신뢰의 공동체는 다른 패턴들을 위한 기반을 제공한다. OrgPatterns/Unity of Purpose, OrgPatterns/Patron Role, OrgPatterns/Fire Walls, OrgPatterns/Developer Controls Process, OrgPatterns/Responsibilities Engage, 그리고 그 외의 다른 것들.
그렇다면 왜 이것이 별도의 구분된 패턴인가? 이것은 특정한 구조적 영향을 가지고 있다: 그것은 커뮤니케이션 경로를 육성하는 것에 관한 것이고, 어떤 위치적(positional) 영향을 가지고 있다 (특히, 그것은 중심에서 멀리 떨어진 관리자 역할을 장려한다.) 둘째로, 행동의 가시적인 특성이 중요하다; 우리는 그러한 특성을 다른 패턴들에서는 보지 못했다.
신뢰는 전염성이 있고, 조직을 통해 하향식으로 가장 효과적으로 전파된다.