디버깅 팀(Debugging Teams)

시작하기 전에, 당신의 기대치를 설정해야 합니다. 열정적인 프로그래머는 도메인 구체적인 문제를 완벽한 수학적 표현으로 제시하는 책을 읽기 좋아하죠. 각 문제는 일반적으로 정해진 절차적 솔루션과 함께 나옵니다.

이 책은 그런 책이 아닙니다.

또 몇 가지 더 미리 말씀드릴 것이 있습니다. 우리가 강연에서 농담처럼 말하듯, "이 의견들은 전적으로 우리의 것이며 우리의 경험에 근거합니다. 동의하지 않는다면, 당신도 당신만의 강연을 하시면 됩니다." 구두 발표에서 그랬듯, 이 책의 내용에서 촉발되는 모든 논의를 환영합니다. 피드백, 교정, 새로운 의견, 이견 모두 즐겁게 이야기하고 싶습니다. http://www.debuggingteams.com/에서 우리를 찾을 수 있습니다. 이 책의 모든 내용은 우리가 불 속에서 겪은 시행착오와 그로부터 얻은 교훈에서 나왔습니다.

또한 사례에 등장하는 모든 이름은 당사자들을 보호하기 위해 바꾸어졌다는 점도 알려 드립니다.

우리가 아는 대부분의 소프트웨어 엔지니어는 컴퓨터 과학과 소프트웨어 엔지니어링을 배우는 데 4년에서 10년까지 시간을 보냈습니다. 그런데 정작 팀이나 회사에서 어떻게 소통하고 협업하는지 실제로 가르치는 커리큘럼^[1]은 거의 없습니다. 물론 대부분 학생은 학력 과정의 어느 시점엔가 팀 프로젝트를 수행해야 합니다. 하지만 누군가에게 다른 사람과 성공적으로 일하는 법을 가르치는 것과, 그를 강제 협업 상황에 던져 넣는 것 사이에는 큰 차이가 있습니다. 대부분 학생은 그 경험에 염증을 느끼게 됩니다.

누군가 “미션 스테이트먼트”이라고 말하면, 대기업들이 흔히 내세우는 싱겁고 과장된 마케팅 문구가 먼저 떠오르기 마련입니다. 예를 들어, 이름은 밝히지 않을 어느 대형 통신사의 미션 문구를 보시죠:

아이러니하게도, 우리는 그 회사를 존경한다고 말하는 사람을 아직 못 만났습니다! 다음은 다른 대기업의 예시입니다:

도대체 무슨 뜻일까요? 문자 그대로 아무 의미로나 해석될 수 있습니다—우리가 그 회사에서 일한다면, 차를 닦는 일이 중요한지, 새는 파이프를 고치는 게 중요한지, 아니면 피자를 배달하는 게 중요한지조차 알 수 없을 겁니다. 바로 이런 기업식 이중언어 때문에 미션 스테이트먼트가 나쁜 평판을 얻게 됩니다.

효과적이고 효율적인 팀에게 미션 스테이트먼트 작성은, 제품의 방향을 간결하게 정의하고 범위를 제한하는 방법입니다. 좋은 미션 스테이트먼트를 쓰려면 시간과 노력이 들지만, 팀이 해야 할 일과 하지 말아야 할 일을 명확히 함으로써 잠재적으로 수년간의의 일을 절약할 수 있습니다.^[15]

구글이 Google Web Toolkit(GWT)의 개발을 오픈 소스 프로젝트로 전환하기로 했을 때, 우리는 팀의 멘토를 맡았습니다. 오픈 소스와 폐쇄형 개발 사이의 여러 차이를 검토하며, 누구나 끼어들어 의견을 내고, 패치를 기여하며, 제품의 사소한 부분까지 비판할 수 있는 환경에서 설계·토론·코드 작성이 얼마나 어려운지에 특히 주목했습니다.^[16] 이런 도전들을 살펴본 뒤, 우리는 팀에 미션 스테이트먼트를 만들어 대중에게 제품의 목표(그리고 비목표)를 설명하라고 권했습니다.

팀원들 중 일부는 앞서 말한 이유들로 난색을 보였지만, 다른 이들은 호기심을 보였고 팀 리드는 훌륭한 제안이라 여기는 듯했습니다. 그러나 막상 미션 스테이트먼트를 쓰기 시작하자, 내용과 골자, 문체를 두고 논쟁이 이어졌습니다. 충분한 토론(과 몇 번의 추가 회의) 끝에 팀은 훌륭하고 간결한 미션 스테이트먼트 뿐만 아니라, 해당 문장을 구절별로 설명한 “Making GWT Better”라는 전체 문서를 만들었습니다.^[17] 심지어 프로젝트의 비목표가 무엇인지 설명하는 섹션까지 포함했습니다. 다음이 그 미션 내용입니다:

저 짧은 문장에 실질적인 내용이 가득합니다. 방향(“개발자가 사용할 수 있도록 하여 웹 경험을 개선”)과 범위 제한(“Java 도구”)이 모두 담겼다는 점에서 미션 스테이트먼트의 훌륭한 본보기입니다. 수년 뒤 팀 리드와 저녁을 먹으며, Fitz는 팀이 미션 스테이트먼트를 쓰도록 한 노력에 그가 강력히 힘을 실어 준 데 대해 고맙다고 말했습니다. 그는 처음에는 이 모든 과정이 시간 낭비라고 생각했지만, 팀과 논의를 시작하고 나서야 자신도 몰랐던 사실—리드 엔지니어들이 제품의 방향에 합의하지 못하고 있었다—는 것을 알게 되었다고 답했습니다.

이 경우 미션 스테이트먼트를 쓰는 과정이 팀의 이견을 마주하게 했고, 제품의 방향에 합의하도록 만들었습니다. 그렇지 않았다면 시간이 지날수록 개발이 느려지거나 멈췄을 수도 있는 문제였습니다. 그들은 미션 스테이트먼트를 웹에 게시했고, 전 팀이 제품에서 무엇을 하려는지에 ‘레이저처럼’ 집중하게 되었을 뿐 아니라, 기여 희망자들과 제품 방향을 두고 몇 달을 소모할 논쟁도 줄었습니다—신규 팀원에게 “Making GWT Better”를 안내하면 대부분의 질문이 해결됐습니다.

프로젝트가 진행되는 동안, 미션 스테이트먼트는 궤도를 유지하게 합니다. 다만 변화에 대한 넘을 수 없는 장벽이 되어서는 안 됩니다. 환경이나 사업 계획에 급격한 변화가 생기면(예: 스타트업), 팀은 스스로에게 솔직해져 그 미션이 여전히 유효한지 재평가해야 합니다. 헌법을 변경하기 어렵게 만든 이유는, 변덕으로 변경하지 못하게 하기 위해서입니다. 하지만 격변의 시기에는 적어도 변경할 가능성이 있어야 하며, 검토되어야 합니다. 회사나 제품이 급격히 방향을 전환한다면, 미션 스테이트먼트도 그에 맞춰 업데이트되어야 합니다.

대부분의 사람은 회의를 ‘필요악’으로 분류합니다. 잘만 쓰면 매우 효과적일 수 있지만, 회의는 자주 남용되고, 보통 정리가 안 되어 있으며, 거의 언제나 너무 깁니다. 우리는 회의를 하수처리장처럼 대합니다. 적고, 드물며, 바람 아래에 있길 바랍니다. 그래서 이 섹션은 짧게, 팀 회의만 다루겠습니다.

모든 회의 중 가장 두려운 것부터 시작해 봅시다. 정기 회의입니다. 이 회의는 보통 매주 열리며, 기본적인 공지와 소개로 딱 제한해야 합니다. 참석자 전원을 돌며(중요한 말이 있든 없든) 현황을 말하게 하는 관행은 시간을 낭비하고, 눈을 굴리게 만들며, 빨리 끝내려고 목을 치고 싶은 욕망을 불러일으키는 지름길입니다.

더 깊은 논의가 필요한 건 회의 후에, 관련자만 남겨서 진행하세요. 누군가 특정 주제로 깊이 파고들어 회의를 탈선시키려 할 때도 같은 방식이 좋습니다. 진행자는 그 주제를 “사이드바(sidebar)” 목록에 추가하고, 본회의가 끝난 뒤 하나씩 검토하면 됩니다. 이를 습관화하면, 주제가 벗어나기 시작할 때 누구의 기분도 상하지 않게 “사이드바”를 선언하기 쉬워집니다. 이 회의를 잘 굴리는 핵심은, 본 파트가 끝나면 사람들이 기꺼이 자리를 떠나도록 하는 것입니다. 다룰 게 없거나 이메일로 충분히 전파할 수 있으면, 주저 말고 회의를 취소하세요. 참석이 곧 지위인 양 여겨져 모두가 빠지기 싫어하는 문화도 봤습니다. 노골적으로 말해, 그건 명백히 미친 일입니다.

새로운 것을 설계하려면 회의는 다섯 명 이내로 유지하세요. 다섯 명이 넘으면, 한 사람이 독단적으로 결정하지 않는 이상 새로운 설계를 내고 결정을 내리기가 사실상 불가능합니다. 믿기지 않으면 친구 다섯을 불러 여섯이 함께 시내로 나가, 관광지 여섯 곳을 도는 도보 여행 코스를 정해 보세요. 한 사람을 최종 심판으로 정해 그를 따라다니는 게 아니라면, 하루 종일 길모퉁이에서 언쟁만 하게 될 확률이 높습니다.

회의는 흔히 많은 이들이 “메이크 타임(make time)”이라고 부르는 시간을 방해합니다. 이는 폴 그레이엄의 “Maker’s Schedule, Manager’s Schedule”에서 영감을 받은 개념입니다.^[18] 특히 엔지니어에게는 회의 때문에 일을 계속 끊어야 하면 몰입 상태에 들어가기 어렵습니다. 캘린더에 3~4시간짜리 블록을 잡아 “바쁨” 혹은 아예 “메이크 타임”으로 표시하고, 그 시간에 일을 끝내세요. 회의를 잡아야 한다면 점심시간 같은 자연스러운 휴식 지점이나 하루의 맨 끝에 배치하세요. 구글에는 “목요일 회의 금지” 전통이 오래(그리고 안타깝게도 자주 무시되면서) 이어져 왔습니다.^[19] 그냥 일만 하는 시간을 확보하기 위한 취지입니다. 이것은 더 긴 블록으로 20~30시간의 메이크 타임을 확보하는 첫걸음입니다.

회의를 해야 한다면, 안건을 만들고 최소 하루 전에 참석자 모두에게 배포하세요. 무엇을 기대해야 하는지 알게 하려는 것입니다. 동기식 커뮤니케이션의 비용을 기억하며 가능한 적은 인원만 초대하세요. 우리가 아는 팀원, 관리자, 심지어 이사와 부사장급까지도 안건 없는 회의 초대는 단호하게 거절합니다.

회의의 목표를 달성하는 데 실제로 필요한 사람만 초대하세요. 참석자들이 집중하지 않고 이메일을 본다는 이유로 회의장 노트북 반입을 금지하는 사람들도 있습니다. 하지만 이는 원인이 아니라 증상을 공격하는 일입니다—사람들이 회의에서 이메일을 보기 시작하는 이유는, 아마도 그들이 애초에 그 회의에 있을 필요가 없기 때문입니다.

회의를 운영하는 사람은 정말로 회의를 운영해야 합니다. 주제에서 벗어나거나, 더 나쁘게는 대화를 독점하려 드는 사람을 (부드럽지만) 과감히 제지하세요. 잘 해내기 어렵지만 그만한 가치가 있습니다. 그리고 가장 중요한 점은 안건을 마쳤다면 겁내지 말고 회의를 일찍 끝내세요.

분산된 팀의 일원이거나 원격으로 일한다면, 단지 다른 소통 방법을 찾는 데 그치지 않고, 아예 커뮤니케이션 자체에 더 많은 노력을 기울여야 합니다. 팀에 원격 근무자가 있다면, 보통 이메일을 통해 의사결정을 문서화하고 공유해야 한다는 뜻입니다. 온라인 채팅, 인스턴트 메시지, 복도 대화에서 많은 논의가 이루어질 수 있지만, 이런 관련 논의를 모두에게 전파해 모두가 정보를 받아보고 참여하도록 만드는 장치가 필요합니다(게다가 메일링 리스트 아카이브는 문서화라는 보너스도 제공합니다). 영상 통화도 빠른 대화를 이끌어내는 데 매우 유용하고, 요즘은 대부분의 노트북에 웹캠이 달려 있습니다.

서브버전(Subversion) 프로젝트에는 이런 모토가 있었습니다. “메일링 리스트에서 일어나지 않은 논의는, 실제로는 일어나지 않은 것이다.” 사람들은 채팅방에서 아이디어를 주고받는 데 많은 시간을 썼지만, 결정을 “진짜”로 만들려면 그 장면을 보지 못한 모두를 고려해야 했습니다. 대화 내용을 메일링 리스트에 다시 올리도록 함으로써, 분산된 팀 전체가 의사결정 과정을 확인할 수 있는 기회를 제공했고(원한다면 의견을 제시할 수도 있었습니다). 이는 합의 기반의 팀 문화를 장려하려 할 때 특히 중요합니다.

원격지의 누군가와 대화하는 일은, 그 사람 책상으로 걸어가 말을 거는 만큼이나 마찰이 없어야 합니다. 원격으로 일한다면, 온라인 채팅, 인스턴트 메시지, 이메일, 영상 통화, 전화 등 가능한 모든 수단으로 팀과 과하게 소통하세요. 여러분이 ‘존재’한다는 사실뿐 아니라 지금 무엇을 하고 있는지도 모두가 알도록 하기 위해서입니다. 그리고 무엇보다도, 대면 대화의 대역폭을 과소평가하지 마세요.

Fitz가 한번은 콜로라도 팀과 함께 일하는 엔지니어를 둔 적이 있습니다. 그녀는 공동 프로젝트의 동력을 얻는 데 어려움을 겪고 있었습니다. 그녀가 Fitz에게 이를 털어놓자, Fitz는 비행기를 타고 콜로라도로 가 팀과 일주일을 함께 보내며 프로젝트에 시동을 걸라고 조언했습니다. 2주 뒤, 그녀는 콜로라도에서 단 하루만 보낸 후 좋은 소식과 함께 이메일을 보냈습니다. 프로젝트에 큰 동력을 얻었을 뿐 아니라, 점심을 함께 먹고 퇴근 뒤에 한잔하면서 팀과 아주 잘 지내게 되었다는 소식이었습니다.

Ben에게는 다른 사무실 팀과 새 프로젝트를 시작한 Corey라는 팀원이 있었습니다. Corey는 새 팀에서 동력을 얻기 어렵다며, 둘의 주간 1:1에서 이를 하소연했습니다. Ben은 비행기를 타고 그 팀의 사무실로 가 일주일간 함께 앉아 프로젝트를 시작하라고 했습니다. Corey는 항공료와 숙박비 때문에 주저했지만, 그 여행의 이익을 고려하지 못하고 있었습니다. Corey는 이틀 일정으로 팀과 함께 일했고, 현장에 함께 있는 것이 얼마나 가치 있는지 즉시 깨달았습니다. 대면 대화의 추가적인 대역폭이 주는 이점뿐 아니라, 점심을 먹고 하루는 퇴근 뒤에 함께 나가며, Corey와 팀은 서로를 사람으로 알게 되었습니다. 그 결과 Corey가 천 마일이나 떨어져 있었음에도, 이후 팀과의 상호작용은 훨씬 원활해졌습니다.

이메일을 얼마나 하고, 채팅과 통화를 얼마나 하든, 주기적으로 비행기를 타고 팀을 방문하는 일을 두려워하지 마세요. 이는 원격 직원, 원격 팀, 원격 오피스 모두에 해당합니다—본사로 나가 사람들과 직접 대화할 시간을 만드세요.

엔지니어라면 새 프로젝트에서 당장 코드 작성으로 뛰어들고 싶은 충동을 참기 어려울 때가 있습니다. 하지만 이는 (대충 뚝딱 만든 프로토타입이 아니라면) 거의 결실을 맺지 못합니다. 그럼에도 많은 엔지니어가 설계 전에 코드 작성부터 서두르고, 보통은 아주 좋지 않은 결말로 이어집니다.

디자인 문서는 보통 한 사람이 소유하고, 두세 사람이 작성하며, 더 많은 인원이 리뷰합니다. 이는 미래 프로젝트의 상위 청사진일 뿐 아니라, 무엇을 어떻게 할 것인지 더 큰 팀에 알리는 저비용의 커뮤니케이션 수단이기도 합니다. 아직 몇 주(혹은 몇 달)간 코드를 쓰지 않았기 때문에, 이 시점에는 비판을 받아들이기가 훨씬 쉽고 결국 더 나은 제품과 구현으로 이어집니다. 또한 디자인 문서를 확정하고 나면, 일정 수립과 작업 분할의 길잡이가 됩니다. 다만 코드 작성을 시작하고 나서는 디자인 문서를 돌에 새긴 것처럼 다루지 말고 살아 있는 문서로 여겨야 합니다. 프로젝트가 성장하고 변함에 따라 문서를 반드시 업데이트해야지, 출시 후에야 고치는 것이 아닙니다. 말은 쉽지만 실천은 어렵습니다. 대부분의 팀은 아예 문서가 없고, 나머지는 짧은 전성기 이후 오래도록 낡은 문서를 둔 채로 지냅니다.

그렇다고 “디자인 문서 교”의 반대 극단으로 치닫지는 마세요. 100줄짜리 프로그램에 4페이지짜리 설계 에세이를 쓰는 통제광도 봤습니다. 디자인 문서를 작성하는 데 걸리는 시간에 프로젝트를 처음부터 여러 번 다시 쓸 수 있다면, 디자인 문서는 분명 시간 낭비입니다. 이런 시간 계산과 트레이드오프에서는 경험과 판단을 사용하세요.

요즘 팀으로 일하는 사람 중에 메일링 리스트를 하나도 안 쓰는 사람은 없다고 봅니다. 다만 메일링 리스트를 더 유용하게 만드는 몇 가지 방법이 있습니다.

큰 성공을 거둔 프로젝트는 메일링 리스트를 여러 개 두는 경우가 많습니다. 개발 논의, 코드 리뷰, 사용자 토론, 공지, 긴급 알림 이메일, 기타 행정 등을 분리합니다. 종종 소규모 프로젝트가 이를 흉내 내며 시작부터 여섯 개의 리스트를 만들기도 하는데, 엔지니어 셋과 사용자 둘뿐인 상황에서 벌어지는 일입니다. 이는 다섯 사람이 논의하자고 회의실을 여섯 개 마련하는 것과 같습니다—일관성은 떨어지고, 메아리만 많고, 방은 대체로 비게 됩니다. 실제로는 리스트 하나로 시작하고, 하나의 리스트의 트래픽이 감당하기 어려울 때(보통 리스트 구성원들이 살려달라고 할 때)만 리스트를 추가하는 것이 가장 좋습니다. 예외적으로 자동 이메일과 봇 알림은 별도 리스트로 보내거나, 최소한 쉽게 필터링할 수 있도록 식별자를 사용하세요.

이메일 토론의 예절을 마련하는 데 시간을 쓰세요—토론을 예의 바르게 유지하고, “시끄러운 소수”의 필리버스터를 막으세요.^[20]

사무실을 함께 쓰는 팀에서 메일링 리스트가 1차 토론 수단은 아닐 수 있지만, 회의 안건, 회의록, 의사결정, 디자인 문서, 기타 관련 텍스트 정보를 팀의 메일링 리스트에 보내 중앙 기록으로 남기는 것이 좋습니다. 모든 게시물을 검색 가능한 인덱스로 보관하도록 설정하세요—오픈 소스 프로젝트는 공개 인덱스로, 폐쇄형 프로젝트는 사내망 인덱스로 말입니다. 이제 프로젝트의 역사를 기록하는 시스템이 생기고, 새로운 팀원이 과거 의사결정의 근거를 물을 때도 쉽게 참고할 수 있습니다. 이런 논의가 어딘가에 아카이브되지 않으면, 여러분은 똑같은 이야기를 반복하고 또 반복하게 될 것입니다.

온라인 채팅은 팀 커뮤니케이션에 믿을 수 없을 만큼 편리합니다. 특히 동료의 업무를 방해하지 않고도 빠르게 요청을 보낼 수 있기 때문입니다(물론 채팅 프로그램이 방해하지 않도록 설정되어 있어야 합니다!). 새로운 프로젝트를 빠르게 진행할 때, 저녁이나 주말에 가볍게 일할 때, 팀원이 하루 이틀 자리를 비울 때 유용합니다. 일대일 채팅도 유용하고 팀 커뮤니케이션에서 분명히 역할이 있지만, 우리는 어떤 형태로든 그룹 채팅 메커니즘을 사용할 것을 강력히 권장합니다.^[21]

인스턴트 메시징이 대중화되기 한참 전부터, 팀들은 IRC(Internet Relay Chat) 채널에 모여 대부분의 토론을 그룹 채팅으로 진행했습니다. 때로는 시끄러웠지만, 팀원들이 전체의 관심사가 아닌 주제를 논의할 때는 사적인 대화로 쉽게 빠져나갈 수 있었습니다. 하지만 대부분의 경우 토론은 팀의 다른 모두가 "보는 앞에서" 진행되었습니다. 덕분에 다른 사람들이 대화에 참여하거나, 배경에서 지켜보며 흐름을 따라가거나, 나중에 놓친 토론을 따라잡을 수 있었습니다. 이는 즉석 그룹 토론을 쉽게 시작할 수 있기 때문만이 아니라, 지리적으로 흩어진 팀에서도 공동체 의식을 형성하는 데 도움이 되기 때문입니다. 새 팀원이 자신이 직접 참여하지 않는 다양한 논의를 그저 지켜보는 것만으로도(또는 나중에 읽기만 해도) 많은 것을 배울 수 있다는 점은 종종 놀라운 일입니다.

인스턴트 메시징이 등장하면서, 예전 같으면 그룹 채팅방에서 이뤄졌을 대화가 1:1로 옮겨갔습니다. 인스턴트 메신저의 기본이 1:1 대화였기 때문입니다. 팀 앞에서 망신을 살 위험을 감수하기보다는, 스스로 불안함을 달래며 ‘어리석게 보일지 모를’ 질문을 1:1로 가져가고 싶은 유혹이 큽니다. 안타깝게도 이렇게 하면 공유된 지식이 축적되지 않아 팀의 부담이 커집니다. 서로 다른 팀원들이 같은 질문을 다른 사람들에게 계속해서 반복하게 되기 때문입니다.

다행히 2014/2015년경 슬랙(Slack)의 부상과 함께 그룹 채팅이 부흥을 맞았습니다. 슬랙은 무료(하지만 무료 소프트웨어나 오픈 소스는 아님) 그룹 메시징 클라이언트로, 현대판 IRC에 가깝습니다. 수십 종의 제품과 통합되며, 소규모 회사, 스타트업, 심지어 인터넷상 느슨한 지인 그룹에서도 선호하는 도구가 되었습니다. 사적인 메시지도 보낼 수 있지만, 팀 소유자는 주간 리포트를 통해 사적 메시지와 그룹 메시지의 비율을 확인할 수 있습니다. 덕분에 팀이 1:1보다 그룹 채널에서 더 많이 대화하도록 부드럽게 “유도”하기가 쉬워졌습니다.

어떤 채팅 애플리케이션을 쓰든, 우리는 팀이 편리하고 접근성 높은 그룹 채팅 수단을 갖추길 강력히 권합니다. 팀에 이 추가적인 커뮤니케이션 대역폭을 확보하는 일은 그만한 노력을 들일 가치가 충분합니다.

사람들은 온라인에서 대화하는 편이 더 편할 때가 있습니다. 우리는 여러 오픈 소스 기여자가(그중 다수는 처음으로) 얼굴을 맞대고 프로젝트를 함께 하던 첫 해커톤을 기억합니다. 방에는 6~8명씩 앉은 12개 테이블이 있었지만, 거의 침묵 속에 모두 노트북을 두드리고 있었습니다. 우리는 늦게 도착해 다들 코드를 쓰고 있구나 싶어, 자리에 앉아 에디터를 열고 프로젝트 IRC 채널에 접속했습니다. 현장에 오지 못한 이들이 “가상으로” 와 있는지 보려던 것이었죠. 그런데 채널에선 여러 대화가 진행 중이었고, 우리가 방에 막 도착했다고 인사하자 몇몇이 IRC에서 인사를 건넸습니다. 확인해 보니 그들은 우리로부터 3미터도 떨어지지 않은 곳에 앉아 있었습니다! 관성 탓도 있었겠지만, 많은 이들에게는 온라인이 그룹과 소통하기 가장 편안한 방식이었기 때문입니다. 4시간 비행을 마치고 더 넓은 대역폭의 소통이 절실했던 우리는 자리에서 일어나 테이블마다 돌아다니며 직접 인사를 나눴습니다.

채팅과 이메일 중 무엇을 언제 써야 하는지에 대한 철칙은 없습니다. 실시간으로 빠르게 진행되는 논의에서, 결정이 쉽게 내려지고 모든 참여자가 현재 자리에 있다면 채팅이 더 유용합니다. 일부가 자리에 없거나 논의의 긴급성이 낮다면 이메일이 더 나을 수 있습니다. 앞서 성공적인 문화의 커뮤니케이션 패턴들에서 살펴본 동기식 대 비동기식 커뮤니케이션의 비용을 기억하세요.

코드 주석 스타일은 매우 주관적입니다. 장황한 주석은 원 작성자의 의도와 이유에 대한 실마리를 제공해 유용할 때가 많지만, 그만큼 유지보수 비용이 듭니다. 낡거나 틀린 주석은 코드베이스 이해를 크게 해칩니다. 반대로 너무 짧거나 아예 없는 주석은, 미래의 유지보수자나 API 소비자가 추리하느라 시간을 낭비하게 만듭니다. 주석은 흔히 빠진 구조와 나쁜 네이밍을 지적한 뒤, 코드가 이미 말하는 바를 다시 설명하는 데 쓰입니다. 주석은 코드가 무엇을 하는지가 아니라, 왜 그렇게 하는지에 집중해야 합니다.

주석은 함수나 메서드 수준에서 가장 유용합니다. 특히 API를 문서화하는 수단으로서요. 장황함을 피하라는 뜻에서, “μηδέν άγαν(과유불급)”이라는 유명한 그리스 격언으로 요약할 수 있습니다. 그다음으로 중요한 것은 팀의 주석 스타일을 정해 모두가 따르도록 하는 것입니다—우리 생각에 일관성이 실제 선택지보다 더 중요합니다.^[22] 스타일 가이드는 왜 존재하는지와 무엇을 규정하려는지 설명해야 합니다. 예컨대 Google C++ 스타일 가이드는 이렇게 시작합니다.^[23]

이 가이드는 C++를 쓰는 가장 좋거나 가장 빠른 방법을 강제하려는 것이 아니라, 코드베이스 전반의 일관성 유지가 얼마나 중요한지를 강조할 뿐임을 유념하세요.

누구나 자신이 한 일에 대한 공로를 인정받고 싶어 합니다. 그림에 사인을 남기는 화가에서부터, 책 등이나 블로그 상단에 이름을 올리는 저자까지 말이죠. 어떤 식으로든 인정받고 싶은 마음은 인간의 본성입니다. 하지만 소스 파일마다 이름을 도배하는 일은, 우리가 보기에 얻는 것보다 잃는 것이 큽니다. 저작권 표시 옆에 바싹 붙은 이름 줄들을 모두가 본 적 있을 겁니다.

소스 코드 상단에 이름을 넣는 전통은 오래되었습니다(우리도 과거에 그랬습니다). 개인이 프로그램을 쓰던 시절에는 타당했을지도 모릅니다. 하지만 오늘날에는 같은 코드에 많은 사람이 손을 댑니다. 파일의 이름 표기는 끝없는 논쟁과 시간 낭비, 그리고 상처받은 감정의 온상이 됩니다. 따라서 우리는 소스 파일에 소유권의 표시로 이름을 넣는 것을 강하게 반대합니다(굳이 넣는다면, 변경 시 우선 리뷰어 지정을 위한 정도로만, 결코 소유권을 암시하지 않도록 조심하세요).

예를 들어 봅시다. 여러분이 팀의 프로젝트—새 파일을 만들고 수백 줄의 코드를 씁니다. 파일 상단에 이름과 적절한 저작권 표시를 넣어 코드 리뷰에 보내고, 이후 저장소에 커밋합니다. 지금까지는 문제도, 드라마도, 이견도 없습니다. 그런데 동료 Adrian이 와서 파일을 고칩니다. 언제 그가 파일 상단에 자신의 이름을 올릴 수 있을까요? 버그를 한 개 고치면? 버그 다섯 개? 함수를 하나 작성하면? 함수 두 개는? 코드 몇 줄을 작성해야 할까요? 그가 함수를 하나 작성하고 이름을 올렸는데, 다른 누군가가 와서 “그의” 함수를 다시 쓴다면? 그 사람도 이름을 올려야 할까요? Adrian의 이름은 지워야 할까요? 연극, 소설, 영화 같은 다른 협업 창작물과 달리, 소프트웨어는 “완성” 이후에도 계속 변합니다. 영화 끝에 올라가는 참여자 목록은 안전하고 정적인 일이지만, 소스 파일의 이름을 더했다 뺐다 하는 일은 끝없는 광기로 흐르기 쉽습니다.

물론 위 질문들에 답을 정하고 가능한 모든 엣지 케이스를 상세히 문서화할 수는 있습니다. 하지만 이를 유지·추적하고 위반을 감시하는 일은—원래 코드 작성에 썼어야 할—엄청난 시간 낭비입니다. 바로 이 때문에, 우리는 공로를 코드가 아닌 프로젝트 수준에서 추적할 것을 권합니다. 우리가 본 대부분의 프로젝트에는 일을 한 모든 사람을 나열한 “Authors”나 “Contributors” 파일이 있습니다. 더 자세한 내용이 필요하면, 버전 관리 시스템이 알려줄 것입니다. 물론 버전 관리를 하지 않는다면, 그 모든 순간은 빗속의 눈물처럼 시간 속에 사라질 것입니다.^[24]

코딩 표준을 둘 것이라면, 제품으로 들어오는 코드를 감시할 수단이 필요합니다. 커밋 전이든 후든, 저장소로 들어오는 모든 코드 한 줄 한 줄이 두 번째 시선의 검토를 거쳐, 스타일, 품질, 그리고 물론 부주의한 실수를 확인하도록 하세요. 변경사항은 작고 리뷰 가능하게 유지하세요—수천 줄짜리 변경세트는 포맷팅 문제 외에는 제대로 리뷰할 수 없습니다. 이는 더 높은 품질의 코드베이스를 만들 뿐만 아니라, 코드 품질에 대한 강한 집단적 자부심을 심어주는 데도 크게 기여합니다. 더 자세한 내용은 숨기는 것은 해롭다의 피드백 루프 섹션을 참고하세요.

풀 TDD를 하는 팀이든, 간단한 회귀 테스트만 있는 팀이든, 자동화된 테스트가 많을수록 버그를 고치고 기능을 추가할 때 더 큰 확신을 갖게 됩니다. 당신의 팀에서 테스트의 역할을 정했다면, 그것이 코딩과 리뷰 과정의 일부가 되어야 합니다. 못지않게 중요한 점은, 릴리스 프로세스가 충분히 가벼워서(예: 주단위) 자주 릴리스할 수 있어야 하면서도, 사용자에게 문제를 전파하기 전에 깨짐을 잡아낼 만큼 충분히 철저해야 한다는 것입니다.

많은 이들이 ‘관리자’라는 직함을 여전히 쓰지만, 이 말은 자주 시대착오적입니다. 우리는 관리자 대신 리더라는 말을 써야 한다고 봅니다. 정치적 올바름을 외치는 부류와는 거리가 있지만, ‘관리자’는 네 글자 욕처럼 느껴질 정도입니다. 그 말의 존재 자체가 새 관리자로 하여금 사람을 관리하게 부추깁니다. 관리자는 부모^[29]처럼 행동하게 되고 직원들은 아이처럼 반응합니다. HRT 맥락에서 말해 보죠. 관리자가 직원에 대한 신뢰를 분명히 보여 주면, 직원은 그 신뢰에 부응하려는 긍정적 압박을 느낍니다. 정말 간단합니다. 리더는 팀의 길을 열고, 안전과 행복을 살피며, 필요가 충족되도록 합니다. 이 장에서 하나만 기억한다면, 다음과 같습니다.

몇 해 전 Fitz 팀에 새 엔지니어가 합류했습니다. 제리의 이전(다른 회사) 관리자는 매일 9시부터 5시까지 자리에 앉아 있으라고 고집했고, 자리에 없으면 일을 충분히 안 한다고 가정했습니다(물론 터무니없는 가정이죠). Fitz와 함께하는 첫날 오후 4시 40분, 제리는 미리 잡힌 약속 때문에 15분 일찍 나가야 한다며 미안하다고 더듬거리며 말했습니다. Fitz는 미소 지으며 단호히 말했습니다. "일만 잘하면, 몇 시에 나가든 상관없어요." 제리는 잠시 멍하니 바라보다 고개를 끄덕이고 자기 일로 돌아갔습니다. Fitz는 제리를 성인으로 대했고, 제리는 항상 일을 마쳤으며, Fitz는 제리가 자리에 있는지 걱정할 필요가 없었습니다. 제리는 보모가 필요하지 않았습니다.

"리더"가 된다는 것이 모든 것에 대해 최종 책임을 진다는 뜻은 아닙니다. 리더십에는 기술적인 것도 있고, 사람과 관련된 것도 있습니다. 소프트웨어 개발 세계에서 팀을 이끄는 사람에게는 보통 두 가지 뚜렷한 역할(과 직함)이 있습니다. TL(테크 리드)과 TLM(테크 리드 관리자)입니다.^[30] TL은 보통 제품 전체(또는 일부)의 기술적 방향을 책임지고, TLM은 제품 전체(또는 일부)의 기술적 방향을 책임 지는 것에 더해 팀원의 커리어와 행복까지 책임집니다. 덕분에 프로젝트 리딩에 집중하고 싶은 사람은 원한다면 사람 관리 영역을 피할 수 있습니다.

사람들이 관리자라는 단어에서 느끼는 막연한 불쾌감 외에도, 관리자가 되기를 꺼리는 이유는 여럿 있습니다. 소프트웨어 세계에서 가장 큰 이유는, 코드 작성 시간이 크게 줄어든다는 점입니다. 기술 리더든 사람 리더든 마찬가지입니다. 이는 뒤에서 더 이야기하고, 먼저 우리가 관리자를 피하는 또 다른 이유들을 보겠습니다.

커리어 대부분을 코딩에 써왔다면, 보통 하루가 끝날 때 코드를 쓰든, 디자인 문서를 만들든, 닫은 버그 더미를 남기든, “오늘 나는 이것을 했다”고 손가락으로 가리킬 무언가가 있습니다. 이런 생산성 기준에서 보면, “관리”로 분주했던 하루 끝에는 “오늘 아무것도 못 했네”라고 생각하기 쉽습니다. 매일 딴 사과 개수만 세다가, 바나나를 따는 일로 옮긴 뒤에도 하루가 끝나 “오늘 사과를 하나도 못 땄네”라고 말하는 꼴입니다. 옆에는 바나나 더미가 수북한데 말이죠. 관리 업무를 수치화하는 일은 생산된 부품을 세는 것보다 확실히 어렵고, 팀의 성과를 본인이 가져갈 필요도 없습니다. 다만 팀이 행복하고 생산적으로 일할 수 있게 만드는 것이 당신 일의 큰 기준이라는 점을 잊지 마세요. 바나나를 따면서 사과 개수를 세는 함정에 빠지지 마세요.

관리자가 되지 않으려는 또 하나의 큰 이유는 자주 말로는 하지 않지만, 유명한 “피터의 법칙”에 뿌리를 둡니다. 이 법칙은 “위계에서 모든 직원은 자신의 무능 수준까지 승진하는 경향이 있다”고 말하죠. 대부분의 사람은 일을 못 하거나 사람 관리를 몹시 못 하는 관리자를 한 번쯤은 겪었고,^[31] 몇몇은 커리어 내내 나쁜 관리자 밑에서만 일하기도 했습니다. 커리어 내내 형편없는 관리자만 봤다면, 왜 스스로 관리자가 되려 하겠습니까? 왜 자신이 잘하지 못할 역할로 승진하길 바라겠습니까?

관리자가 되는 것을 고려할 만한 훌륭한 이유도 있습니다. 첫째, 자신을 확장하는 방법입니다. 코드를 아무리 잘 써도, 혼자 쓸 수 있는 양에는 상한이 있습니다. 당신의 리더십 아래 훌륭한 엔지니어 팀이 얼마나 많은 코드를 쓸 수 있을지 상상해 보세요! 둘째, 당신이 정말 그 일을 잘할지도 모릅니다. 프로젝트의 리더십 공백 속으로 빨려 들어간 많은 이들이, 팀이 필요로 하는 안내·지원·엄호를 제공하는 데 비범한 재능이 있음을 발견하곤 합니다.

당신이 관리자이고 역할에 대해 불안감을 느끼고 있다면(어떤 이유든), 아무도 당신의 권위에 의문을 제기하거나 직장을 위협하지 못하게 하는 한가지 방법은 당신이 밀어붙일 수 있는 사람들을 채용하는 것입니다. 당신보다 똑똑하지 않거나 야망이 없는 사람들, 아니면 당신보다 더 불안한 사람들을 채용함으로써 이를 달성할 수 있습니다. 이렇게 하면 팀 리더이자 의사결정자로서의 당신의 위치는 확고해지지만, 당신에게는 훨씬 더 많은 일이 생깁니다. 당신 팀은 목줄에 묶인 개들처럼 당신이 이끌지 않으면 움직일 수 없습니다. 만약 당신이 밀어붙일 수 있는 사람들로 팀을 구성한다면, 아마 휴가를 갈 수 없을 것입니다. 당신이 방을 떠나는 순간, 생산성은 급격히 멈춥니다. 하지만 직장에서 안전함을 느끼는 것에 비하면 이 정도는 작은 대가일 뿐이겠죠, 그렇지 않나요?

대신, 당신보다 똑똑하고 당신을 대체할 수 있는 사람들을 채용하려고 노력해야 합니다. 이는 어려울 수 있습니다. 바로 그런 사람들이 정기적으로 당신에게 도전할 것(당신이 실수했을 때 확실한 말로 알려주는 것 외에도)이기 때문입니다. 그런 사람들은 계속해서 당신을 감동시키고 훌륭한 일들을 만들어낼 것입니다. 그들은 훨씬 더 큰 범위에서 스스로를 이끌 수 있고, 일부는 팀을 이끌고 싶어할 것입니다. 당신은 이것을 당신의 권력을 빼앗으려는 시도로 보지 말고, 오히려 추가 팀을 이끌거나 새로운 기회를 탐색하거나, 심지어 매일 팀이 일을 제대로 하고 있는지 확인하느라 신경 쓰지 않고도 휴가를 갈 수 있는 기회로 봐야 합니다.

구글에서 팀 리더로서 Fitz의 커리어 초기에, 팀에게 보너스 편지를 나눠줄 때가 되었고, 그는 관리자에게 "관리자가 되는 게 정말 좋아요!"라고 말하며 활짝 웃었습니다. 오랜 업계 베테랑이었던 Fitz의 관리자는 주저하지 않고 답했습니다. "때로는 이빨 요정이 되어야 하고, 때로는 치과의사가 되어야 하지."

이빨을 뽑는 일은 결코 즐겁지 않습니다. 우리는 팀 리더들이 믿을 수 없을 정도로 강한 팀을 구축하기 위해 모든 올바른 일을 하는 것을 보았지만, 단지 한두 명의 저성과자 때문에 이런 팀들이 뛰어나지 못하고 (결국 무너지는) 것을 보았습니다. 인간적 측면이 소프트웨어 작성에서 가장 어려운 부분이라는 것을 이해하지만, 인간을 다루는 데 있어 가장 어려운 부분은 기대치를 충족하지 못하는 사람을 처리하는 것입니다. 때로는 사람들이 충분히 오래 또는 열심히 일하지 않아서 기대치를 놓치지만, 가장 어려운 경우는 아무리 오래 또는 열심히 일해도 자신의 일을 할 수 없는 사람입니다.

구글에서 모든 서비스를 계속 운영하는 책임을 맡은 팀의 모토는 "희망은 전략이 아니다"입니다. 그리고 저성과자를 다루는 데 있어서만큼 희망이 전략으로 남용되는 곳은 없습니다. 대부분의 팀 리더들은 이를 악물고, 눈을 돌리고, 저성과자가 마법처럼 나아지거나 그냥 사라지기를 희망합니다. 하지만 이런 일이 일어나는 경우는 극히 드뭅니다.

리더가 희망을 품고 있는 동안 저성과자가 나아지지도 않고 (떠나지도 않는) 상황에서, 팀의 고성과자들은 저성과자를 끌고 가는 데 귀중한 시간을 낭비하고 팀 사기는 허공으로 새어나갑니다. 당신이 그들을 무시하고 있어도 팀은 그들이 있다는 것을 확실히 알고 있습니다. 팀의 나머지 구성원들은 저성과자가 누구인지 예리하게 알고 있습니다. 왜냐하면 그들을 떠안아야 하기 때문입니다.

저성과자를 무시하는 것은 또한 새로운 고성과자들이 당신의 팀에 합류하는 것을 막는 방법이고, 기존 고성과자들이 떠나도록 부추기는 방법이기도 합니다. 결국 당신은 저성과자들로만 이루어진 팀을 갖게 됩니다. 왜냐하면 그들만이 스스로의 의지로 떠날 수 없는 사람들이기 때문입니다. 마지막으로, 저성과자를 팀에 계속 두는 것은 저성과자에게도 도움이 되지 않습니다. 종종 당신의 팀에서 잘하지 못하는 사람이 다른 곳에서는 실제로 많은 영향을 미칠 수 있습니다.

저성과자를 가능한 한 빨리 다루는 것의 이점은 그를 끌어올리거나 아니면 내보낼 수 있는 위치에 자신을 둘 수 있다는 것입니다. 저성과자를 즉시 다룬다면, 종종 그가 더 높은 생산성 상태로 들어가기 위해 단지 약간의 격려나 방향이 필요할 뿐이라는 것을 발견하게 될 것입니다. 저성과자를 다루기까지 너무 오래 기다리면, 팀과의 관계가 너무 악화되고 당신도 너무 좌절해서 그를 도울 수 없게 될 것입니다.

저성과자를 효과적으로 코칭하는 방법은 무엇일까요? 우리 둘은 (불행히도) 고통스러운 시행착오를 통해 이 분야에서 상당한 경험을 쌓았습니다. 가장 좋은 비유는 절뚝거리는 사람이 다시 걷고, 조깅하고, 팀의 나머지 구성원들과 함께 달릴 수 있도록 돕는다고 상상하는 것입니다. 거의 항상 일시적인 마이크로매니징이 필요하지만—여전히 많은 HRT, 특히 존중이 필요합니다. 특정 시간대(예: 2-3개월)를 설정하고, 그 기간 동안 그가 달성하기를 기대하는 매우 구체적인 목표들을 설정하세요. 목표를 작고 점진적으로 만들어서 많은 작은 성공의 기회가 있도록 하세요. 진행 상황을 확인하기 위해 매주 팀원과 만나고, 성공이나 실패를 측정하기 쉽도록 다가오는 각 이정표에 대해 정말 명시적인 기대치를 설정하세요. 저성과자가 따라갈 수 없다면, 과정 초기에 당신 둘 모두에게 매우 명백해질 것입니다. 이 시점에서 그 사람은 종종 일이 잘 되지 않고 있다는 것을 인정하고 그만두기로 결정할 것입니다. 다른 경우에는 결단력이 발동되어 기대치를 충족하기 위해 "게임을 업그레이드"할 것입니다. 어느 쪽이든, 저성과자와 직접 작업함으로써 당신은 중요하고 필요한 변화를 촉진하고 있는 것입니다.

앞서 말했듯이, 팀 리더는 팀에 대해 사회적 측면과 기술적 측면이란 두 가지 주요 영역에 집중해야 합니다. 리더들이 기술적 측면에서 더 강한 것은 꽤 흔한 일이고, 대부분의 리더들이 기술적 직무에서 승진했기 때문에(그들의 직무의 주요 목표가 기술적 문제를 해결하는 것이었기 때문에), 그들은 인간적 문제를 무시하는 경향이 있습니다. 팀의 기술적 측면에 모든 에너지를 집중하는 것은 유혹적 입니다. 개인 기여자로서 당신은 대부분의 시간을 기술적 문제 해결에 썼기 때문입니다. 학생이었을 때 당신의 수업은 모두 당신의 일의 기술적 요령을 배우는 것이었습니다. 하지만 이제 당신이 리더가 되었으니, 팀의 인간적 요소를 무시하는 것은 당신 자신의 위험입니다.

팀에서 인간적 요소를 무시하는 리더의 예시부터 시작해보겠습니다. 몇 년 전, Fitz의 친한 친구—Jake라고 부르겠습니다—가 첫 아이를 가졌습니다. Jake와 Fitz는 원격으로도, 같은 사무실에서도 수년간 함께 일해왔기 때문에, 새 아기가 태어난 후 몇 주 동안 Jake는 집에서 일했습니다. 이는 Jake와 그의 아내에게 훌륭하게 작동했고, Fitz는 이미 Jake와 원격으로 일하는 데 익숙했기 때문에 전혀 문제없었습니다. 그들은 평소처럼 생산적이었습니다. 그런데 (다른 사무실에서 일하는) 그들의 관리자 Pablo가 Jake가 일주일 대부분을 집에서 일하고 있다는 것을 알게 되었습니다. Jake가 평소처럼 생산적이고 Fitz도 그 상황에 만족함에도 불구하고, Pablo는 Jake가 Fitz와 함께 일하기 위해 사무실에 나오지 않는다고 화를 냈습니다. Jake는 Pablo에게 사무실에 나와서 일하는 것만큼 생산적이고, 몇 주 동안 주로 집에서 일하는 것이 자신과 아내 모두에게 훨씬 쉽다고 설명하려 했습니다. Pablo는 "야, 사람들은 항상 아이를 가져. 너는 사무실에 나와야 해."라고 반응했습니다. 말할 필요도 없이, (평소에는 온화한 엔지니어인) Jake는 분노했고 Pablo에 대한 존경을 많이 잃었습니다.

Pablo가 이를 다르게 처리할 수 있었던 방법은 많습니다. Jake가 아내를 위해 집에 더 있고 싶어한다는 것을 이해하고, 그의 생산성과 팀에 영향을 미치지 않는다면 한동안 계속 그렇게 하도록 놔둘 수 있었습니다. 상황이 안정될 때까지 Jake가 일주일에 하루나 이틀은 사무실에 나오도록 협상할 수도 있었습니다. 최종 결과가 무엇이든, 약간의 공감은 이 상황에서 Jake를 행복하게 유지하는 데 큰 도움이 되었을 것입니다.

대부분의 사람들이 리더십에 첫 발을 내딛는 것은 이전에 팀원이었던 팀의 리드가 될 때입니다. 많은 리드들이 팀과 쌓아온 우정을 잃고 싶어하지 않기 때문에, 팀 리드가 된 후에도 팀원들과의 우정을 유지하기 위해 때로는 더 열심히 노력합니다. 이는 재앙이 되며 많은 우정을 깨뜨리는 레시피가 될 수 있습니다. 우정과 부드러운 터치로 이끄는 것을 혼동하지 마세요. 당신이 누군가의 커리어에 대한 권력을 가지고 있을 때, 그는 우정의 제스처에 인위적으로 보답해야 한다는 압박감을 느낄 수 있습니다.

팀의 동료가 되지 않고도(또는 엄청나게 독한 사람이 되지 않고도) 팀을 이끌고 합의를 이룰 수 있다는 것을 기억하세요. 마찬가지로, 기존의 우정을 바람에 날려버리지 않고도 강한 리더가 될 수 있습니다. 우리는 팀과 함께 점심을 먹는 것이 그들을 불편하게 만들지 않으면서도 사회적으로 연결을 유지하는 효과적인 방법이 될 수 있다고 발견했습니다. 이는 정상적인 업무 환경 밖에서 비공식적인 대화를 나눌 기회를 제공합니다.

때로는 좋은 친구이자 동료였던 사람을 관리하는 관리자 역할로 이동하는 것이 까다로울 수 있습니다. 관리받는 친구가 자율적이지 않고 열심히 일하지 않는다면, 모든 사람에게 스트레스가 될 수 있습니다. 가능한 한 이런 상황에 빠지지 않도록 하는 것을 권장합니다.

스티브 잡스는 한때 이렇게 말했습니다: "A 등급 사람들은 다른 A 등급 사람들을 채용하고, B 등급 사람들은 C 등급 사람들을 채용한다." 이 격언의 희생자가 되기는 매우 쉽고, 빠르게 채용하려고 할 때는 더욱 그렇습니다. 우리가 흔히 보는 접근법은 팀이 5명의 엔지니어를 채용해야 한다고 해서, 지원서 더미를 훑어보고 40-50명을 면접한 다음, 채용 기준을 충족하는지 여부와 상관없이 최고의 5명을 뽑는 것입니다. 이는 평범한 팀을 만드는 가장 빠른 방법 중 하나입니다.

올바른 사람을 찾는 비용—리크루터에게 돈을 주든, 광고비를 내든, 또는 추천을 위해 길을 뛰든—은 처음부터 채용하지 말았어야 할 직원을 다루는 비용에 비하면 아무것도 아닙니다. 이 "비용"은 팀 생산성 손실, 팀 스트레스, 직원을 관리하거나 내보내는 데 드는 시간, 그리고 직원을 해고하는 데 관련된 서류 작업과 스트레스로 나타납니다. 물론 그 직원을 팀에 그대로 두는 엄청난 비용을 피하려고 노력한다고 가정할 때의 이야기입니다. 만약 당신이 채용에 대한 발언권이 없는 팀을 관리하고 있고 팀을 위해 채용되는 사람들에 불만족스럽다면, 더 높은 품질의 엔지니어를 위해 치열하게 싸워야 합니다. 여전히 수준 이하의 엔지니어들만 받게 된다면, 아마 다른 직장을 찾아볼 때일 것입니다. 훌륭한 팀을 위한 원료가 없다면, 당신은 망할 것입니다.

팀에게 당신이 그들을 신뢰하지 않는다는 것을 보여주는 가장 좋은 방법은 그들을 아이처럼 대하는 것입니다. 사람들은 당신이 그들을 대하는 방식대로 행동하는 경향이 있으므로, 만약 당신이 그들을 아이나 죄수처럼 대한다면, 그들이 그렇게 행동할 때 놀라지 마세요. 당신은 그들을 세세하게 관리하거나 단순히 그들의 능력을 존중하지 않고 그들의 일에 책임질 기회를 주지 않음으로써 이런 행동을 나타낼 수 있습니다. 만약 신뢰하지 않기 때문에 사람들을 세세하게 관리하는 것이 영구적으로 필요하다면, 당신은 채용 실패를 손에 쥐고 있는 것입니다. 물론, 당신의 목표가 평생 돌봐야 할 팀을 만드는 것이 아니라면 실패입니다. 만약 당신이 신뢰할 만한 사람들을 채용하고 이 사람들에게 그들을 신뢰한다는 것을 보여준다면, 그들은 보통 기회에 부응할 것입니다(앞서 언급한 기본 전제, 즉 당신이 좋은 사람들을 채용했다는 것에 충실하여).

피츠는 시카고에서 지역 기관에서 빌린 장소에서 열리던 컨퍼런스를 운영합니다. 피츠가 컨퍼런스를 위해 장소에 접근하려고 처음 갔을 때, 시설 관리자는 피츠가 모든 것이 어디에 있는지 알 수 있도록 장소를 간단히 둘러보게 했습니다. 그런 다음 관리자는 건물 열쇠를 그에게 건네주고 다음 주에 열쇠를 돌려받겠다고 말했습니다. "해야 할 일과 하지 말아야 할 일" 목록도 없었고, 행사에 대한 광범위한 감독도 없었으며, 결과적으로 피츠와 그의 팀은 마치 자신들의 것처럼 시설을 돌보는 책임감을 느꼈고, 장소를 깨끗하고 정리된 상태로 유지한다는 기대를 뛰어넘었습니다.

이 수준의 신뢰의 결과는 건물 열쇠에서 사무실과 컴퓨터 용품까지 모든 곳에 나타납니다. 또 다른 예로, 구글은 직원들에게 다양한 사무용품(예: 펜, 노트북, 그리고 다른 "레거시" 창작 도구들)이 가득한 캐비닛을 제공하며, 직원들이 필요에 따라 자유롭게 가져갈 수 있습니다. IT 부서는 미니 전자상가와 같은 셀프 서비스 영역인 여러 "테크 스톱"을 운영합니다. 이곳에는 컴퓨터 액세서리와 잡동사니들(예: 전원 공급 장치, 케이블, 마우스, USB 드라이브 등)이 많이 있는데, 그냥 집어서 가져가기 쉽지만, 구글 직원들이 이 물품들을 체크아웃하도록 신뢰받고 있기 때문에, 올바른 일을 해야 한다는 책임감을 느낍니다. 전형적인 기업의 많은 사람들은 이런 말을 듣고 공포에 반응하며, 확실히 구글은 사람들이 이 물품들을 "훔쳐가서" 돈을 잃고 있을 것이라고 외칩니다. 그럴 수도 있지만, 아이처럼 행동하는 직원을 두는 비용은 어떨까요? 확실히 그것이 펜 몇 개와 USB 케이블 몇 개의 가격보다 더 비쌀 것입니다.

HRT를 처음 다룰 때 Chapter 1. The Myth of the Genius Programmer에서 ‘자아를 내려놓기’에 대해 이야기했는데, 이는 서번트 리더 역할을 할 때 특히 중요합니다. 이 패턴을 ‘바닥걸레처럼 깔리고 팀이 마음대로 하게 두라’는 의미로 오해하곤 하지만 전혀 아닙니다. 겸손함과 남에게 휘둘림 사이에는 미묘한 경계가 있지만, 겸손은 자신감 부족과 같지 않습니다. 자아도취자가 아니면서도 자신감과 의견을 가질 수 있습니다. 큰 개인적 자아는 어떤 팀에서도, 특히 리더에게서는 다루기 어렵습니다. 대신 강력한 집단적 팀 자아와 정체성을 키워야 합니다.

‘자아를 내려놓기’의 일부는 이미 다룬 바와 같습니다. 팀을 신뢰해야 합니다. 이는 신규 합류자라 하더라도 팀원의 능력과 과거 성취를 존중한다는 뜻입니다.

마이크로매니징을 하지 않는다면, 최전선의 사람들이 당신보다 일을 더 잘 이해하고 있다고 봐도 됩니다. 즉, 당신이 합의를 이끌고 방향을 돕더라도, 목표를 어떻게 달성할지는 제품을 만드는 이들이 결정하는 편이 가장 좋습니다. 이는 소유감뿐 아니라 성과(또는 실패!)에 대한 책임감까지 크게 높여 줍니다. 좋은 팀이 있고 그들이 품질과 속도의 기준을 스스로 세우게 두면, 당근과 채찍으로 군림할 때보다 훨씬 많은 것을 이룹니다.

리더 역할을 처음 맡으면 모든 걸 완벽히 하고, 다 알고, 모든 해답을 가져야 한다는 압박을 느낍니다. 하지만 실제로는 그럴 수 없고, 그런 척하면 팀의 존중을 빠르게 잃습니다. 핵심은 역할 속에서 기본적인 안정감을 갖는 것입니다. 개인 기여자 시절을 떠올려 보세요. 불안은 멀리서도 냄새로 맡을 수 있었죠. 질문을 환대하세요. 누군가 당신의 결정이나 발언을 묻는다면, 대개 더 잘 이해하려는 것입니다. 질문을 장려하면 당신과 팀을 더 낫게 만드는 건설적 비판을 받을 가능성이 커집니다. 훌륭한 건설적 비판을 줄 사람을 찾기는 매우 어렵고, 특히 당신에게 ‘보고하는’ 사람에게서 그런 비판을 얻기는 더 어렵습니다. 팀의 큰 그림을 생각하고 피드백과 비판을 열린 마음으로 받으세요. 영역 싸움의 유혹을 피하세요.

‘자아를 내려놓기’의 마지막은 단순하지만, 많은 엔지니어가 기름에 삶기는 한이 있어도 피하고 싶어하는 일입니다. 실수했을 때 사과하는 것. 팝콘에 소금 치듯 “미안”을 남발하라는 뜻이 아니라, 진심으로 사과하라는 뜻입니다. 실수는 반드시 생기고, 인정하든 말든 팀은 이미 알고 있습니다(그리고 확실한 사실 하나: 그들은 분명 서로 이야기할 겁니다). 사과에는 돈이 들지 않습니다. 실수했을 때 사과하는 리더에 대한 존중은 큽니다. 흔한 통념과 달리, 사과가 당신을 취약하게 만들지 않습니다. 오히려 사람들은 당신을 더 존중합니다. 사과는 당신이 침착하고 상황 판단이 좋으며—HRT로 돌아가—겸손하다는 신호이기 때문입니다.

화학에서 촉매는 반응을 가속하지만 스스로는 소모되지 않는 물질입니다. 촉매(예: 효소)가 작동하는 방식 중 하나는 반응물들을 가까이 데려다 놓는 것입니다. 용액 속에서 이리저리 튀던 반응물들이, 촉매의 도움으로 서로 가까워지면 유리한 상호작용을 할 가능성이 훨씬 커집니다. 리더로서 당신도 자주 이런 역할을 하게 되며, 이를 위한 방법은 여러가지입니다.

팀 리더가 가장 흔히 하는 일 중 하나는 합의를 만드는 것입니다. 처음부터 끝까지 프로세스를 이끌 수도 있고, 속도를 내도록 올바른 방향으로 살짝 밀어 줄 수도 있습니다. 팀 합의 형성은 비공식 리더들이 자주 쓰는 리더십 기술입니다. 실제 권한 없이도 리드할 수 있는 방법이기 때문이죠. 권한이 있다면 지시하고 명령할 수 있지만, 합의를 만드는 것에 비해 전체적으로 효과는 떨어집니다. 팀이 빠르게 움직이고자 할 때는, 팀원들이 자발적으로 한두 명의 팀 리드에게 권한과 방향 결정을 위임하기도 합니다. 겉으로는 독재나 과두정치처럼 보여도, 자발적으로 이루어진 것이라면 그것 역시 합의의 한 형태입니다.

때로 팀은 해야 할 일에 이미 합의했지만, 장애물에 막혀 멈춥니다. 기술적일 수도, 조직적일 수도 있습니다. 이때 다시 움직이도록 돕는 것은 흔한 리더십 기술입니다. 팀원들에게는 사실상 넘기 어려운 장애물이, 리더인 당신에게는 쉽게 처리할 수 있는 일일 때가 있습니다. 이런 장애물이라면 기꺼이(그리고 능히) 도와주겠다는 신호를 팀이 이해하도록 돕는 것이 가치 있습니다.

어느 날 Fitz의 팀은 법무 부서와의 장애물을 넘기 위해 몇 주를 보냈습니다. 마침내 한계에 다다라 Fitz에게 도움을 청했을 때, 그는 연락해야 할 ‘적임자’를 알고 있었기에 두 시간도 안 되어 문제를 풀었습니다. 또 다른 날, Ben의 팀은 서버 자원이 필요했지만 배정을 받을 수 없었습니다. 다행히 Ben은 회사 전체의 다른 팀들과 소통하고 있었고, 그날 오후 바로 팀이 필요로 하는 자원을 확보했습니다. 또 한 번은 Fitz 팀의 엔지니어가 난해한 Java 코드에 막혔는데, Fitz는 자바 전문가가 아니었지만 문제를 정확히 아는 다른 엔지니어를 연결해 주었습니다. 모든 답을 알아야 장애물을 치울 수 있는 것은 아닙니다. 대신 답을 아는 사람을 아는 것이 대개 큰 도움이 됩니다. 많은 경우, ‘정답’을 아는 것보다 ‘정답을 아는 사람’을 아는 게 더 가치 있습니다.

팀의 촉매가 되는 또 다른 방법은, 더 큰 위험을 감수할 수 있도록 안전함과 심리적 안정감을 주는 것입니다. 위험은 흥미로운 주제입니다. 대부분의 인간은 위험 평가를 형편없이 합니다. 대부분의 회사는 어떤 대가를 치르더라도 위험을 피하려 하죠. 그래서 보통은 보수적으로 일하고, 더 큰 위험이 기하급수적 성과를 가져올 수 있는 상황에서도 작은 성공에만 집중합니다. 구글에선 자주 이렇게 말합니다. 불가능해 보이는 목표에 도전하면 실패할 확률이 높다. 하지만 불가능에 도전하다 실패하면, 애초에 해낼 수 있는 일만 시도했을 때보다 훨씬 더 많은 것을 이루게 된다. 위험 감수를 받아들이는 문화를 만들려면, 실패해도 괜찮다는 사실을 팀이 알도록 하세요.

그러니 분명히 합시다. 실패해도 괜찮습니다. 사실 우리는 실패를 아주 빠르게 많은 것을 배우는 방법으로 봅니다(물론 같은 일을 반복해서 실패하지 않는다는 전제하에). 실패를 비난이나 책임 추궁의 대상이 아니라 학습 기회로 보는 것이 중요합니다. 빨리 실패하는 건 좋습니다. 걸린 것이 많지 않으니까요^[35]. 천천히 실패해도 배움은 있지만, 위험과 손실(대개 엔지니어링 시간)이 커서 더 아픕니다. 고객에게 영향을 주는 방식의 실패는 우리가 가장 원치 않는 실패로, 그럴수록 실패에서 학습하기 위한 구조를 더 갖춰 둡니다. 앞서 말했듯 구글은 프로덕션 실패가 있을 때마다 포스트모템을 진행합니다. 이는 실제 실패로 이어진 사건들을 기록하고, 재발 방지를 위한 단계들을 만드는 절차입니다. 이 과정은 책임을 따지거나 불필요한 관료적 점검을 들이밀기 위한 자리가 아닙니다. 문제의 핵심에 강하게 집중해 완전히 고치기 위한 자리입니다. 매우 어렵지만, 아주 효과적입니다(그리고 카타르시스입니다!).

개인의 성공과 실패는 조금 다르게 다뤄야 합니다. 개인의 성공을 칭찬하는 것은 좋지만, 실패했을 때 개인에게 책임을 전가하려 드는 건 팀을 분열시키고 전반적 위험 감수를 위축시키는 최악의 방법입니다. 실패해도 됩니다. 다만 팀으로서 실패하고, 거기서 배우세요. 개인이 성공했다면 팀 앞에서 칭찬하고, 개인이 실패했다면 비공개로 건설적 비판을 제공하세요.^[36] 어떤 경우든 기회를 살려 HRT를 넉넉히 적용해, 팀이 실패에서 학습하도록 도우세요.

팀 리더로서 가장 어려운 일 중 하나는, 당신이라면 20분이면 끝낼 일을 주니어가 세 시간을 들여 씨름하는 모습을 지켜보는 것입니다. 사람을 가르치고 스스로 배울 기회를 주는 일은 처음엔 몹시 어렵지만, 효과적인 리더십의 필수 구성 요소입니다. 특히 신규 입사자에게 중요합니다. 그들은 팀의 기술과 코드베이스뿐 아니라 팀의 문화와 적절한 책임 수준까지 함께 배우고 있기 때문입니다.

관리자 역할과 마찬가지로, 멘토 역할은 지원해서 맡기보다는 팀 리드가 신입을 도울 사람을 찾다가 자연스럽게 맡게 되는 경우가 많습니다. 멘토에게 거창한 교육이나 준비는 필요하지 않습니다. 본질적으로 세 가지가 중요합니다. 팀의 프로세스와 시스템에 대한 경험, 타인에게 설명하는 능력, 그리고 멘티가 어느 정도 도움을 필요로 하는지 가늠하는 능력. 마지막이 아마 가장 중요합니다. 멘티에게 충분한 정보를 주는 것은 당신의 일입니다. 하지만 지나치게 장황하게 설명하면, 멘티는 “알겠다”고 정중히 말하기보다, 그냥 귀를 닫아 버릴 것입니다.

겉보기에는 너무나 자명하지만 놀라울 만큼 많은 리더들이 꾸준히 무시하는 패턴입니다. 팀을 한 방향으로 빠르게 움직이게 하려면, 구성원 모두가 그 방향이 무엇인지 이해하고 동의하게 해야 합니다. 제품을 거대한 트럭이라고 상상해 봅시다(파이프가 아니라). 각 팀원이 트럭 앞에 묶인 밧줄을 손에 쥐고 있고, 일을 하면서 자신의 방향으로 트럭을 끕니다. 당신의 목표가 트럭(혹은 제품)을 가능한 한 빨리 북쪽으로 끌고 가는 것이라면, 제각각으로 끌게 둘 수는 없습니다. 모두가 북쪽으로 끌어야 합니다.

명확한 목표를 세우고 팀이 같은 방향으로 제품을 끌도록 만드는 가장 쉬운 방법은, 간결한 팀 미션 스테이트먼트를 만드는 것입니다(미션 스테이트먼트에 대해서는 Chapter 2. Building an Awesome Team Culture 의 미션 스테이트먼트—정말로 절을 참조하세요). 팀의 방향과 목표를 정의하도록 도운 뒤에는 한 발 물러서 자율성을 부여하고, 주기적으로 점검해 올바른 궤도에 있는지 확인하세요. 이렇게 하면 리더십의 다른 과제에 시간을 쓸 여유가 생길 뿐 아니라, 팀의 효율이 비약적으로 향상됩니다. 명확한 목표 없이도 팀은 (실제로) 성공할 수 있지만, 대개는 각자가 약간씩 다른 방향으로 제품을 끌면서 엄청난 에너지를 낭비합니다. 이는 당신을 좌절시키고 팀의 진행을 늦추며, 당신이 진로를 바로잡기 위해 더 많은 에너지를 쓰게 만듭니다.

당신이 팀에게 거짓말을 한다고 가정하는 것은 아닙니다. 다만, 언젠가 반드시 팀에게 어떤 것을 말할 수 없거나, 더 나쁘게는 듣기 싫은 사실을 말해야 하는 상황이 오기 때문에 이 주제를 언급합니다. Fitz의 이전 관리자는 신입 팀원들에게 이렇게 말하곤 했습니다. “나는 너희에게 거짓말하지 않아. 하지만 어떤 건 말할 수 없을 때가 있고, 그냥 모를 때도 있다는 건 말해 줄게.”

팀원이 당신이 공유할 수 없는 것을 묻는다면, 답을 알고 있지만 말해 줄 수 없다고 말해도 괜찮습니다. 더 흔한 상황은, 당신이 답을 모르는 질문을 받는 경우입니다. 모른다고 말하세요. 글로 보면 너무나 자명하지만, 많은 이들이 관리자 역할로 이동하면 답을 모르는 것이 약하거나 둔감하다는 증거라고 느낍니다. 현실에서 그게 증명하는 유일한 사실은 ‘인간’이라는 점뿐입니다.

어려운 피드백을 주는 일은… 음, 어렵습니다. 부하 직원에게 실수를 했거나 기대만큼 일을 잘하지 못했다고 처음 말해야 할 때는 엄청나게 스트레스를 받을 수 있습니다. 대부분의 관리 서적은 어려운 피드백을 전할 때 충격을 완화하기 위해 "칭찬 샌드위치"를 사용하라고 조언합니다. 칭찬 샌드위치는 다음과 같습니다:

"당신은 팀의 든든한 구성원이고 우리의 가장 똑똑한 엔지니어 중 한 명입니다. 그런데 말이지, 당신의 코드는 엄청나게 복잡하고 팀의 다른 누구도 이해하기 거의 불가능합니다. 하지만 당신은 엄청난 잠재력이 있고 멋진 턱수염도 있어요."

물론 이렇게 하면 충격은 완화되지만, 이런 식으로 에둘러 말하면 대부분의 사람들은 회의를 마치고 나서 "좋아! 내 턱수염이 멋지다는군!"이라고만 생각할 것입니다. 우리는 칭찬 샌드위치 사용을 강력히 반대합니다. 불필요하게 잔인하거나 가혹해야 한다고 생각해서가 아니라, 대부분의 사람들이 핵심 메시지를 듣지 못하기 때문입니다. 그 핵심 메시지는 무언가가 바뀌어야 한다는 것입니다. 여기서도 HRT를 적용할 수 있습니다. 칭찬 샌드위치에 의존하지 않고도 건설적 비판을 전할 때 친절하고 공감적으로 할 수 있습니다. 사실, 상대방이 비판을 듣고 즉시 방어적으로 나오지 않게 하려면 친절함과 공감이 필수적입니다.

몇 년 전, Fitz는 다른 관리자로부터 팀원 Tim을 인수받았는데, 그 관리자는 Tim과 함께 일하는 것이 불가능하다고 주장했습니다. 그는 Fitz에게 Tim이 피드백이나 비판에 전혀 반응하지 않고, 대신 하지 말라고 들은 똑같은 일을 계속 한다고 말했습니다. Fitz는 관리자와 Tim 사이의 상호작용을 관찰하기 위해 몇 번의 회의에 참석했고, 그 관리자가 Tim의 감정을 상하게 하지 않으려고 칭찬 샌드위치를 광범위하게 사용한다는 것을 알아차렸습니다. Fitz가 Tim을 자신의 팀으로 데려왔을 때, 그는 Tim과 앉아서 팀과 더 효과적으로 일하기 위해 몇 가지 변화가 필요하다고 매우 명확하게 설명했습니다. Fitz는 Tim에게 어떤 칭찬도 하지 않았고 문제를 포장하지도 않았지만, 똑같이 중요한 것은 Fitz가 비정하지 않았다는 점입니다. 그는 단지 이전 팀에서의 Tim의 성과를 바탕으로 자신이 본 사실들을 제시했을 뿐입니다. 놀랍게도 몇 주 만에 (그리고 몇 번의 "복습" 회의 후에) Tim의 성과가 극적으로 향상되었습니다. Tim에게는 매우 명확한 피드백과 방향이 필요했을 뿐이었습니다.

직접적인 피드백이나 비판을 제공할 때, 메시지가 들리고 회피되지 않도록 하는 데 있어 전달 방식이 핵심입니다. 상대방을 방어적으로 만들면, 그는 어떻게 변화할 수 있을지 생각하는 대신 당신이 틀렸다는 것을 보여주기 위해 어떻게 논쟁할지를 생각하게 됩니다. Ben은 한때 Dean이란 엔지니어를 관리했습니다. Dean은 극도로 강한 의견을 가지고 있었고 팀의 나머지 구성원들과 무엇이든 논쟁했습니다. 팀의 미션처럼 큰 것이든 웹 페이지의 위젯 배치처럼 작은 것이든 상관없이, Dean은 같은 확신과 격렬함으로 논쟁했고, 어떤 것도 그냥 넘어가게 두지 않았습니다. 몇 달간 이런 행동을 한 후, Ben은 Dean과 만나 그가 너무 호전적이라고 설명했습니다. 만약 Ben이 그냥 "Dean, 그렇게 짜증나게 굴지 마"라고 말했다면, Dean이 그것을 완전히 무시했을 것이 확실합니다. Ben은 Dean이 자신의 행동이 팀에 어떻게 악영향을 미치고 있는지 이해하게 할 방법을 열심히 생각했고, 다음과 같은 비유를 생각해냈습니다.

이 일화는 상황에 약간의 유머를 주입했을 뿐만 아니라, Dean의 "기차 멈추기"가 팀에 미치는 영향과 Dean이 그것에 들이는 에너지에 대해 Ben과 Dean이 더 쉽게 논의할 수 있게 했습니다.

리더로서 장기적으로 팀을 더 생산적으로 만들고 (떠날 가능성을 줄이는) 한 가지 방법은 시간을 내어 그들의 행복을 측정하는 것입니다. 우리가 함께 일한 최고의 리더들은 모두 아마추어 심리학자였습니다. 때때로 팀원들의 복지를 살피고, 그들이 하는 일에 대한 인정을 받도록 하며, 그들이 자신의 일에 만족하는지 확인하려고 노력했습니다. 우리가 아는 한 리더는 해야 할 모든 더럽고 고마움을 받지 못하는 작업들의 스프레드시트를 만들어 이런 작업들이 팀 전체에 고르게 분산되도록 합니다. 다른 리더는 팀이 일하는 시간을 관찰하고 보상 휴가와 재미있는 팀 외출을 활용해 번아웃과 탈진을 피합니다. 또 다른 리더는 팀원들과의 일대일 세션을 기술적 문제를 다루는 것으로 시작해 분위기를 풀고, 그다음 각 엔지니어가 일을 완료하는 데 필요한 모든 것을 갖추고 있는지 확인하는 데 시간을 씁니다. 분위기가 풀린 후에는 엔지니어와 잠시 이야기하며 현재 하고 있는 일을 얼마나 즐기고 있는지, 다음에 무엇을 기대하고 있는지 알아봅니다.

팀의 행복을 추적하는 데 가장 가치 있는 도구 중 하나는 각 일대일 회의가 끝날 때 팀원에게 "무엇이 필요하세요?"라고 묻는 것입니다. 이 간단한 질문은 마무리하고 각 팀원이 생산적이고 행복하게 지내는 데 필요한 것을 갖추고 있는지 확인하는 좋은 방법입니다. 세부 사항을 얻기 위해 조심스럽게 좀 더 파고들어야 할 수도 있지만 말입니다. 일대일 회의를 할 때마다 이렇게 묻는다면, 결국 팀이 이것을 기억하게 되고 때로는 자신의 일을 더 좋게 만들기 위해 필요한 것들의 목록을 가지고 당신에게 오기도 할 것입니다.

사무실 밖에서의 팀의 행복에도 어느 정도 관심을 기울이는 것이 가치 있을 수 있습니다. 사람들이 일 밖에는 삶이 없다고 가정하지 않도록 주의하세요. 사람들이 일에 투입할 수 있는 시간에 대해 비현실적인 기대를 갖는 것은 사람들이 당신에 대한 존경을 잃게 하거나, 더 나쁘게는 번아웃을 일으킬 것입니다. 우리는 팀원들의 사생활을 캐라고 주장하는 것이 아니라, 팀원들이 겪고 있는 개인적 상황에 민감하게 반응하는 것이 특정 시점에 그들이 왜 더 생산적이거나 덜 생산적일 수 있는지에 대한 많은 통찰을 줄 수 있다는 것입니다. 지금 집에서 힘든 시간을 보내고 있는 팀원에게 약간의 여유를 주는 것은 나중에 팀이 촉박한 마감일을 맞춰야 할 때 그가 더 긴 시간을 기꺼이 투입하게 만들 수 있습니다.

팀원들의 행복을 추적하는 큰 부분은 그들의 커리어를 추적하는 것입니다. 팀원에게 5년 후 자신의 커리어를 어떻게 보는지 묻는다면, 대부분의 경우 어깨를 으쓱하며 멍한 표정을 짓게 될 것입니다. 갑자기 그런 질문을 받으면 대부분의 사람들은 이에 대해 많이 말하지 않을 것이지만, 보통 모든 사람이 향후 5년 동안 하고 싶어하는 몇 가지가 있습니다: 승진하기, 새로운 것 배우기, 중요한 것 출시하기, 그리고 똑똑한 사람들과 일하기. 이것을 말로 표현하든 그렇지 않든, 대부분의 사람들은 이에 대해 생각하고 있습니다. 효과적인 리더가 되려면, 이 모든 것들이 일어나도록 어떻게 도울 수 있는지 생각하고 이에 대해 생각하고 있다는 것을 팀에게 알려야 합니다. 이 중 가장 중요한 부분은 이러한 암묵적 목표들을 명시적으로 만드는 것입니다. 그래야 커리어 조언을 할 때 상황과 기회를 평가할 수 있는 실제 지표 세트를 갖게 됩니다.

행복 추적은 단순히 커리어를 모니터링하는 것뿐만 아니라, 팀원들에게 자신을 개선하고, 그들이 하는 일에 대한 인정을 받으며, 그 과정에서 약간의 재미를 느낄 기회를 주는 것으로 귀결됩니다.

위임하되, 손을 더럽혀라. 개인 기여자 역할에서 리더십 역할로 이동할 때, 균형을 맞추는 것은 가장 어려운 일 중 하나입니다. 처음에는 모든 일을 스스로 하려는 경향이 있고, 리더십 역할을 오래 맡은 후에는 일을 전혀 하지 않는 습관에 빠지기 쉽습니다. 리더십 역할이 처음이라면, 팀의 다른 엔지니어들에게 일을 위임하는 데 열심히 노력해야 할 것입니다. 그들이 그 일을 완수하는 데 당신보다 훨씬 오래 걸릴지라도 말입니다. 이것은 당신의 정신 건강을 유지하는 한 가지 방법일 뿐만 아니라, 팀의 나머지 구성원들이 배우는 방법이기도 합니다. 한동안 팀을 이끌어왔거나 새로운 팀을 맡게 된다면, 팀의 존경을 얻고 그들이 하고 있는 일을 빠르게 파악하는 가장 쉬운 방법 중 하나는 손을 더럽히는 것입니다. 보통 다른 누구도 하고 싶어하지 않는 더러운 작업을 맡는 것으로 말입니다. 이력서와 성취 목록이 아무리 길어도, 실제로 뛰어들어 힘든 일을 하는 것만큼 팀에게 당신이 얼마나 숙련되고 헌신적이며 (그리고 겸손한지) 알려주는 것은 없습니다.

자신을 대체할 사람을 찾아라. 평생 똑같은 일을 계속하고 싶지 않다면, 자신을 대체할 사람을 찾으세요. 이는 앞서 언급했듯이 채용 과정에서 시작됩니다. 팀의 구성원이 당신을 대체하기를 원한다면, 당신을 대체할 수 있는 사람들을 고용해야 합니다. 우리는 이를 보통 "당신보다 똑똑한 사람을 고용하라"고 요약합니다. 당신의 일을 할 수 있는 팀원들이 있으면, 그들에게 더 많은 책임을 맡거나 때때로 팀을 이끌 기회를 주어야 합니다. 이렇게 하면 누가 리더십에 가장 적성이 있는지, 그리고 누가 팀을 이끌고 싶어하는지 빠르게 알 수 있을 것입니다. 어떤 사람들은 그냥 고성과 개인 기여자로 있는 것을 선호한다는 것을 기억하세요. 그것도 괜찮습니다. 우리는 항상 최고의 엔지니어들을 데려다가—그들의 의사에 반해—관리 역할에 던져넣는 회사들에 놀라왔습니다. 이는 보통 팀에서 훌륭한 엔지니어를 빼고 평균 이하의 관리자를 추가하는 결과를 낳습니다.

언제 변동을 일으켜야 하는지 알아라. (필연적이고 빈번하게) 몸의 모든 세포가 아무것도 하지 말라고 소리치는 어려운 상황들이 생길 것입니다. 기술적 실력이 기준에 미치지 못하는 팀의 엔지니어일 수도 있습니다. 모든 기차 앞으로 뛰어드는 사람일 수도 있습니다. 주 30시간만 일하는 동기 부족한 직원일 수도 있습니다. "조금만 기다리면 나아질 거야"라고 스스로에게 말할 것입니다. "저절로 해결될 거야"라고 합리화할 것입니다. 이 함정에 빠지지 마세요. 이런 상황들이야말로 가장 큰 변동을 일으켜야 하고 지금 일으켜야 하는 상황들입니다. 이런 문제들이 저절로 해결되는 경우는 거의 없으며, 해결을 미룰수록 팀의 나머지 구성원들에게 더 악영향을 미치고 밤에 그것들을 생각하며 잠 못 이루게 할 것입니다. 기다리는 것은 불가피한 일을 지연시키고 그 과정에서 헤아릴 수 없는 피해를 일으킬 뿐입니다. 그러니 행동하세요. 그리고 빠르게 행동하세요.

팀을 혼돈으로부터 보호하라. 리더십 역할을 맡으면, 보통 가장 먼저 발견하게 되는 것은 팀 밖에는 개인 기여자였을 때 결코 보지 못했던 혼돈과 불확실성(또는 심지어 광기)의 세계가 있다는 것입니다. Fitz가 1990년대에 처음 관리자가 되었을 때(다시 개인 기여자로 돌아가기 전), 그는 회사에서 일어나고 있는 엄청난 양의 불확실성과 조직적 혼돈에 깜짝 놀랐습니다. 그는 다른 관리자에게 평소 차분했던 회사에 갑자기 이런 불안정함이 생긴 원인이 무엇인지 물었고, 그 관리자는 Fitz의 순진함에 히스테리컬하게 웃었습니다. 혼돈은 항상 존재했지만, Fitz의 이전 관리자가 Fitz와 팀의 나머지 구성원들을 그것으로부터 보호해왔던 것입니다.

팀에게 엄호를 제공하라. 회사에서 그들 "위에서" 무슨 일이 일어나고 있는지 팀에게 알려주는 것이 중요하지만, 팀 외부에서 당신에게 부과될 수 있는 많은 불확실성과 사소한 요구들로부터 그들을 방어하는 것도 똑같이 중요합니다. 팀과 가능한 한 많은 정보를 공유하되, 실제로 그들에게 영향을 미칠 가능성이 극히 낮은 조직적 광기로 그들을 산만하게 하지는 마세요.

팀이 잘하고 있을 때 알려주어라. 많은 새로운 팀 리드들은 팀원들의 부족한 점을 다루는 데 너무 몰두한 나머지 충분히 자주 긍정적인 피드백을 제공하는 것을 소홀히 할 수 있습니다. 누군가 실수했을 때 알려주는 것처럼, 잘했을 때도 반드시 알려주고, 홈런을 쳤을 때는 그 사람(과 팀의 나머지 구성원들)에게 반드시 알려주세요.

마지막으로, 새로운 것을 자주 시도하고 싶어하는 모험적인 팀원들이 있을 때 최고의 리더들이 알고 자주 사용하는 것이 있습니다. 무언가를 되돌리기 쉽다면 "예"라고 말하기도 쉽다는 것입니다. 제품 속도를 높일 수 있는 새로운 도구나 라이브러리를 하루나 이틀 시도해보고 싶어하는 팀원이 있다면(그리고 촉박한 마감일이 없다면), "물론, 해보세요"라고 말하기 쉽습니다. 반면에, 향후 10년간 지원해야 할 제품을 출시하는 것 같은 일을 하고 싶어한다면, 좀 더 신중하게 생각해보고 싶을 것입니다. 정말 좋은 리더들은 언제 무언가를 되돌릴 수 있는지에 대한 좋은 감각을 가지고 있습니다.

프로젝트의 현재 상황을 전혀 파악하지 못하는 사람들이 있습니다. 이들이 끼치는 피해는 주로 팀의 시간을 낭비하는 형태로 나타납니다. 기본 문서, 미션 스테이트먼트, FAQ, 최신 메일 스레드만 몇 분 읽으면 될 일을 하지 않고, 온 팀을 반복적으로 붙잡아 스스로도 쉽게 찾을 수 있는 질문을 던집니다.

Subversion 프로젝트에는 한 참여자가 있었는데, 메인 개발자 포럼을 자기 의식의 흐름을 떠보는 놀이터로 쓰기로 했습니다. Charlie는 코드 기여를 전혀 하지 않았습니다. 대신 두세 시간마다 공상과 브레인스토밍을 뿌렸습니다. 그의 아이디어가 왜 틀렸는지, 불가능한지, 이미 진행 중인지, 예전에 논의됐거나 문서화돼 있는지 설명하는 답글이 반드시 여러 개 달렸습니다. 더 나쁜 건, Charlie가 지나가던 사용자들의 질문에 틀린 답을 달기 시작했다는 점입니다. 핵심 기여자들이 그의 답을 거듭 수정해야 했습니다. 우리는 이 상냥하고 열정적인 참여자가 실은 독이 되어 공동의 에너지를 빨아들이고 있음을 깨닫기까지 시간이 걸렸습니다. 이 상황을 어떻게 처리했는지는 뒤에서 다룹니다.

여기서 자아(에고)라는 말이 완벽하진 않지만, 우리는 합의 결정을 받아들이지 못하고, 다른 관점을 경청하거나 존중하지 못하며, 타협에 이르지 못하는 사람을 가리키는 용어로 씁니다. 이런 사람은 자신이 그 자리에 없었다는 이유로 오래전에(그리고 메일 아카이브에 문서화되어) 끝난 논의를 다시 열곤 합니다. 아예 기록을 읽지도, 생각하지도 않고 자기만을 위해 논쟁을 처음부터 다시 하자고 요구합니다. 자기 방식대로 하지 않으면 곧 파멸이 임박했다고 프로젝트의 성공 가능성을 휘둘러 말하기도 합니다.

Subversion 프로젝트에서는 어느 날 똑똑한 프로그래머가 메일 목록에 나타나 제품 전체가 잘못 설계되었다고 발언한 적이 있습니다. 그는 진리를 보았고, 사물이 작동해야 하는 급진적 구상을 가졌으며, 프로젝트를 처음부터 다시 시작해야 한다고 주장했습니다. 심지어 자신이 재시작을 이끌겠다고 ‘도움’까지 자처했습니다. 자신의 리더십 없이는 완전한 실패가 코앞이라고도 공언했습니다.

그 사람과 창립자들이 일주일 내내 논쟁하며 원래의 설계 결정을 방어하는 동안, 엄청난 주의와 집중이 소모됐습니다. 그는 타협할 의사가 없었고, 자신의 아이디어를 현재 제품에 통합할 생각도 없다는 것이 분명해졌습니다. 제품은 이미 베타였고, 현업에서 사용되고 있었습니다. 우리는 어느 시점에 토론을 떠나 본궤도로 돌아갈 수밖에 없었습니다. 아이러니하게도 수년 후에 이 사람의 예측은 여러 측면에서 옳은 것으로 드러났습니다. 그러나 그렇다 해도 Subversion이 크게 성공하는 것을 막지는 못했습니다. 적어도 기업용 소프트웨어 개발 분야에서는 그렇습니다. 요점은 옳고 그름 싸움이 아니라, 이견이 언젠가 결말을 맺을 수 있는지, 논쟁을 계속할 가치가 있는지입니다. 스스로에게 이런 질문을 멈추지 마세요. 언젠가는 손실을 줄이고 다음으로 넘어갈 때를 결정해야 합니다.

무언가가 반드시 이루어져야 한다고 요구하는 방문자가 나타난다면, 경고 신호를 켜야 합니다. 소프트웨어의 부족한 점을 불평하는 데 모든 에너지를 쏟으면서도, 어떤 방식으로든 직접 기여하려 하지 않는 사람에게는 분명 문제가 있습니다.

이러한 권리의식은 때때로 트롤 같은 행동으로 번집니다. 우리가 구글의 Project Hosting 서비스를 운영할 때, 한 프로젝트 소유자가 외설적 행동을 이유로 사용자를 차단해 달라고 요청했습니다. 해당 오픈 소스 프로젝트는 비디오 게임 에뮬레이터였고, 그 사용자가 좋아하는 게임이 제대로 동작하지 않았습니다. 그는 무례한 버그 리포트로 시작했고, 개발자들은 왜 아직 작동하지 않는지, 왜 당분간 고치기 어려운지 정중히 설명했습니다. 그러나 그는 그 답을 받아들이지 않았고, 매일 개발자들을 괴롭히기 시작했습니다. 같은 불만으로 버그를 계속 열었고, 다른 버그에도 “내 문제를 고치지 않는 바보들”이라는 식의 댓글을 달았습니다. 개발자들과 구글 관리자의 반복 경고에도 언행은 점점 더 심해졌습니다. 파괴적 행동을 없애려는 모든 노력에도 그는 끝내 변하지 않았고, 결국 최후의 수단으로 전체 차단을 할 수밖에 없었습니다.

실명 대신 “SuperCamel”, “jubjub89”, “SirHacksalot” 같은 유치한 닉네임만 씁니다. 더 나쁜 건 미디어마다 별명이 다르기도 합니다. 이메일용, 메신저용, 코드 제출용이 각각 다른 식이죠. 사람들은 lol-speak(인터넷 은어), 1337speak(leetspeak), 모두 대문자, 혹은 과도한 문장 부호로 소통하는 모습을 보이게 됩니다.

앞선 예시에서 보았듯이, 때로는 부적절한 특권 의식이 프로젝트에 대한 공개적인 적대감으로 곧바로 이어지기도 합니다. 그것이 완전한 피해 의식으로 번지는 경우도 자주 봅니다. 기존 팀이 방문자와 의견이 다르면, 독이 되는 사람은 때땨로 “파벌”이나 음모가 있다고 비난하기 시작합니다. 프로젝트 팀이 그 사람을 그렇게까지 중요하게 생각해서 방문자에게 대항하기 위해 음모를 꾸민다고 상상하는 것은 우스꽝스러운 일이겠습니까. 이미 Chapter 2. Building an Awesome Team Culture 에서 권한 것처럼 소통이 개방적이고 투명한 문화라면 모든 대화가 이미 공개 기록이라 이런 비난은 더 우스워집니다. 우리의 권고는 간단합니다. 이런 주장에 굳이 답하지 마세요. 그 사람이 여기까지 갔다면, 당신이 무슨 말을 해도 그의 마음속 구덩이만 더 깊어집니다. 그러니 애초에 아무 말도 하지 않는 편이 낫습니다. 중요한 만들기 작업으로 돌아갈 때입니다.

표면적으로 완벽주의자는 전혀 위험해 보이지 않습니다. 때로는 강박적 성향이 조금 보일 수도 있지만, 보통 겸손하고 공손하며, 존중을 알고, 경청합니다. HRT와 선의로 가득 차 보이죠. 그럼 문제가 뭘까요? 문제는 ‘마비’의 위협입니다.

과거에 함께했던 사람을 보죠. Patrick은 뛰어난 엔지니어였습니다. 설계 감각이 탁월했고, 고품질 코드와 테스트를 썼으며, 함께 일하기 편했습니다. 하지만 새 소프트웨어를 설계할 때면, 평생을 설계를 다듬고 개선하는 데 쓸 기세였습니다. 계획에 결코 만족하지 않았고, 코딩을 시작할 준비가 영원히 되지 않은 듯 보였습니다. 우리가 풀려고 하던 문제에 대한 그의 통찰은 훌륭했지만, 팀은 엄청난 좌절을 겪었습니다. 우리는 실제로는 코드를 절대 쓰지 못할 것 같았죠. 프로젝트의 몇몇이 이 문제를 어떻게 할지 오랜 논의를 했습니다. 한편으로 Patrick은 팀에 큰 도움이었습니다. 다른 한편으로 그는 팀의 전진을 막고 있었습니다. 코딩을 막 시작하려 할 때마다 그는 공손하게 거부권을 행사하며, 먼 미래에 어쩌면 문제가 될지 모를 이론적 위험을 지적했습니다. 그는 자신도 모르게 우리를 마비시키고 있었습니다. 해결법은 다음 절에서 다룹니다.

원래 문제에 대해 ‘충분히 좋은’ 해법을 찾았다면, 완벽주의자의 에너지를 아직 손봐야 하는 다른 문제로 돌리세요.

Subversion의 완벽주의자에게도 이 전략이 통했습니다. 우리는 결국 Patrick을 따로 불러 이렇게 말했습니다. “좋아요, 지금의 설계대로 그냥 시작해 보고, 일어나는 일을 보죠. 길에서 문제가 생기면 그때 당신이 우회로를 찾도록 도와주세요.” 놀랍게도 Patrick은 이를 받아들였고, 집착의 대상을 다른 주제로 옮겼습니다. 누구의 감정도 상하지 않았고, Patrick은 계속 전체 노력에 기여했습니다.

“완벽이 좋은 것의 적이 되게 하지 말라”는 오래된 속담이 있습니다. 성과 높은 팀을 만들고자 한다면, 더 분명하게 방해가 되는 행동들을 지적할 때만큼이나 완벽주의를 피하는 데에도 경계를 늦추지 않아야 합니다.

에너지를 돌리는 요령은, 돕기보다 불평·비난에 시간을 더 쓰는 과도한 권리의식의 소유자에게도 통합니다. 이런 사람에게 “패치 환영” 같은 상투적 응수(‘말만 하지 말고 기여하라’는 오픈 소스식 완곡 표현)를 하고 싶겠지만, 대신 정식 테스트와 리그레션 지적에 관심을 두게 해 보세요. 불평을 계속하되 유익한 방식으로 하게 됩니다.

Usenet에서 유래한 옛 격언입니다.^[44] 특히 이것은 의도적으로 당신이나 당신의 팀을 자극하려는 트롤(trolls) 에게 가장 잘 통합니다. 당신이 반응하면 할수록 트롤은 당신의 에너지를 빨아들이고, 당신은 그만큼 더 많은 시간을 낭비하게 됩니다. 가장 좋은 대응은 침묵인 경우가 많습니다. 한 방 먹이는 멋진 한 줄을 던지고 싶더라도, 참으세요. 아무도 자신에게 관심을 주지 않는다는 걸 깨닫게 되면, 그는 보통 흥미를 잃고 그냥 떠납니다. 대응하지 않기 위해서는 꽤 큰 의지가 필요하다는 점을 명심하십시오. 참고 버티세요!

상대가 의도적으로 트롤링하지 않더라도, 방어적으로 굴기 쉽습니다. 누군가가 나쁜 설계 결정을 했다거나 음모를 꾸몄다고 비난하거나, 자명한 질문을 너무 많이 해서 시간을 낭비하게 만들면 쉽게 화가 납니다. 기억하세요. 당신의 일은 훌륭한 것을 만드는 일이지, 방문자 모두를 달래거나 존재 이유를 반복 입증하는 일이 아닙니다. 감정이 강할수록, 그만한 대우를 받을 자격이 없는 사람에게 격정적 답장을 쓰느라 시간과 날을 더 낭비하기 쉽습니다. 싸움을 신중히 고르고, 침착함을 유지하세요. 누구에게 답할지, 누구는 그냥 두고 넘어갈지 신중히 결정하세요.

과도한 감정을 경계한다는 주제의 연장선에서, 또 하나의 보완점은 사실을 적극적으로 찾는 것입니다. 누군가가 불평하면 주의 깊게 들으세요. 화가 섞이거나 무례한 언어에도 불구하고, 언제나 먼저 그 사람에게 선의의 해석을 부여하는 것부터 시작해야 합니다. 정말 일리가 있나요? 그 사람의 경험에서 배울 것이 있나요, 응답할 가치가 있는 아이디어가 있나요? 종종 대답은 “그렇다”입니다.독성 인물의 독설 속에도 실제로는 지혜가 묻혀 있는 경우가 많습니다. 논의를 항상 기술적 토론으로 되돌리세요^[45].

좋은 예가 하나 있습니다. 오픈 소스 커뮤니티의 유명 리더에게서 독설 가득한 이메일을 받은 날이었습니다. 버그 리포트의 형식을 띠었지만, 표면상으로는 팀의 지능을 깎아내리는 분노의 글에 가까웠습니다. 중상과 과장이 가득했고, 버그를 고치려는 의도보다 팀을 자극하려는 의도가 더 뚜렷해 보였습니다. 하지만 우리 팀의 한 구성원은 버그에만 집중해 몇 가지 구체 질문으로 응답했습니다. 리포터는 추가 설명을 보냈지만, 여전한 독설에 싸여 있었습니다. 팀원은 모욕을 완전히 무시한 채 이슈를 조사하고 간단히 답했습니다. “리포트 감사합니다. 고치는 방법이 보입니다. 곧 패치를 배포하겠습니다.”

그 팀원의 대처가 몹시 자랑스러웠습니다. 철저히 침착하고 사실 중심으로 임하자, 대화가 진행될수록 원 게시자는 더 광적으로 보였습니다. 결국 교환의 끝에서 버그 리포터는 청중의 신뢰를 완전히 잃었고, 더는 머물 관심도 사라졌습니다.

앞서 말한(침착하고 사실에 충실한) 접근을 한 걸음 더 나아가면, 지나치게 친절함 만으로도 사람을 물러가게 만들 때가 있습니다! 아래는 Subversion IRC 채널의 실제 대화록입니다.

아무리 노력해도, “보조 비트”를 켜고 지나가야 할 때가 있습니다. 나쁜 행동을 바로잡으려 주의와 집중을 많이 들였더라도, 가망이 없는 일을 알아보는 법을 알아야 합니다.

메일을 너무 자주 올리던 친절한 철학자, Charlie의 이야기로 돌아갑시다. 우리는 결국 메일 토론을 분석했고, 두 달 사이 그가 세 번째로 많은 글을 올린 참가자가 되었음을 발견했습니다. 1등과 2등은 핵심 기여자였고, 그들의 글 70%가 Charlie에게 답장하는 데 쓰였습니다! Charlie에게 악의가 없었음에도 우리의 에너지와 집중이 빨려나가고 있었습니다. 최종 해결책은 그에게 개인적으로 (정중히) 메일을 보내서, 그렇게 자주 글을 올리지 말아 달라고 요청하는 것이었습니다. 이는 어려운 대화였는데, 주로 그가 자신의 방해 규모를 이해하지 못했기 때문입니다. 몇 주 더 큰 변화가 없자, 우리는 전화로 길고(더 어려운) 대화를 통해 아예 글을 멈춰 달라고 부탁했습니다. 그는 약간 슬프고 혼란스러워했지만, 팀의 뜻을 존중해 물러났습니다. 그가 가한 피해를 끝내 완전히 이해하지 못했기에 모두가 약간 죄책감을 느꼈지만, 동시에 옳은 일이라 느꼈습니다. 섬세한 상황이었지만, 우리는 HRT를 충분히 적용해 예의를 지키며 적절히 해결했습니다.

성공으로 가는 길에는 수천 가지 산만함이 늘어서 있습니다. 독성 인물로 인한 산만함을 다룰 때 공통 주제가 있다면, 눈앞의 드라마에 휘말리기 너무 쉽다는 점입니다. 독성 행동으로 보이는 장면을 목격했다면, 자신에게 다음의 두 가지 핵심 질문을 던지세요.

이 질문들 중 하나라도 답이 “아니오”라면, 가능한 한 빨리 개입해 그 행동을 멈춰야 합니다. 독을 묵인하면 단기적 이득이 있다고 스스로를 설득하기 쉽지만, 보통은 그렇지 않습니다. 누군가 훌륭한 기술 기여자일지라도 독성 행동을 보일 수 있습니다. 기술적 진보의 이익을 위해 행동을 못 본 척하고 싶겠지만, 조심하세요! HRT에 기반한 강한 문화는 대체 불가능하지만, 기술 기여는 충분히 대체 가능합니다. 우리 팀 동료의 말을 빌리면

물론 Greg이 말하는 ‘천재’는 문자 그대로의 천재가 아닙니다. 세상은 유능한 프로그래머로 가득합니다. 장기적으로 불쾌감을 주거나 문화를 위협하는 사람이라면, 다른 사람을 기다리는 편이 낫습니다.

Subversion 프로젝트에서도 비슷한 상황을 겪었습니다. 팀에는 소스 파일에 이름을 넣지 않는 엄격한 정책이 있습니다(Chapter 2. Building an Awesome Team Culture 에서 다룬 바로 그 정책!). 개인 명의는 통제하기 어려운 영역의식을 만듭니다. 누군가의 이름이 박힌 코드는 바꾸기 두렵고, 버스 팩터를 인위적으로 낮춥니다. 대신 버전 관리 이력을 통해 적절히 공을 돌리고, 최상위에 모든 기여자의 이름을 모은 파일을 하나 둡니다.

어느 날 똑똑한 프로그래머가 나타나 절실히 필요했던 큰 기능을 자원해 구현하겠다고 나섰습니다. 그는 리뷰를 위해 코드를 제출했는데, 우리가 준 주요 피드백은 파일 상단에 적힌 자신의 이름을 지워 달라는 단순한 요청이었습니다. 다른 기여자들과 마찬가지로 동일한 방식으로 공로를 인정하겠다는 뜻이었습니다. 그러나 그는 이를 거부했고, 논의는 교착 상태에 빠졌습니다. 결국 우리는 그의 코드를 거절했고, 그는 자신의 코드를 챙겨 떠나 버렸습니다. 물론 모두가 실망했지만, 새로운 기능을 빨리 얻자고 해서 우리의 정책을 어기고 문화를 희석하고 싶지는 않았습니다. 그리고 두어 달 뒤, 다른 사람이 그 기능을 다시 구현했습니다.

분명히 말하자면, 단기적인 이익을 위해 문화를 희생할 가치는 없습니다. 특히 그것이 HRT의 중요성을 인정하지 않는 뛰어난 기여자에 관한 것이라면 더더욱 그렇습니다.

당신의 매니저가 HRT를 실천하며 당신의 성공을 진심으로 돕고자 하는 서번트 리더라면(Chapter 3. Every Boat Needs a Captain 참조), 그녀의 일을 더 쉽게 만들어주고 결과적으로 당신을 더 생산적이고 가치 있는 팀원으로 만들 수 있는 몇 가지 간단한 방법들이 있습니다. 더 중요한 것은, 이런 방법들이 당신의 일을 더 좋게 만들고 커리어를 더 성공적으로 만들 수 있다는 점입니다.

추가적인 책임을 추구하라 일을 해나가면서 말입니다. 이에 대한 우리가 가장 좋아하는 비유 중 하나는 산림 관리원이 당신(주니어 관리원)을 숲으로 보내 병들거나 손상된 나무를 베어내라고 하는 상황입니다. 단순히 당면한 과제에만 집중한다면, 숲에 들어가서 병든 나무를 베고 의기양양하게 돌아올 것입니다. 하지만 더 큰 그림을 생각한다면, 숲에 들어가서 병든 나무를 베고, 여행 중에 마주친 다른 모든 병든 나무들의 지도와 함께 돌아올 것입니다. 그리고 시니어 관리원이 이것이 최선의 행동 계획이라고 동의한다면 효율적으로 그것들을 베어낼 계획도 함께 말입니다. 이런 종류의 행동의 결과로, 다음에 산림 관리원이 그 수준의 책임감을 요구하는 과제를 가지고 있을 때 그녀는 당신에게 첫 번째 기회를 줄 가능성이 높습니다. 그녀가 이렇게 하는 이유는 당신이 할 수 있다는 것을 알기 때문일 뿐만 아니라, 그것이 최소 저항의 경로이기 때문입니다—그녀에게는 더 적은 일이죠.

이런 종류의 적극적이고 책임을 추구하는 행동은 매니저가 걱정할 일이 하나 줄어들기 때문에 그녀의 업무량을 줄여주고, 당신이 현재 수준을 넘어서는 일을 할 수 있다는 것을 보여줍니다. 이는 또한 당신이 컴포트 존을 벗어나 새로운 것들을 시도해야 할 가능성이 높다는 것을 의미하며, 위험을 감수하고 빠르게 실패하는 것이 장려되는 팀에 있다면 그것은 괜찮습니다.

위험을 감수하고 실패를 두려워하지 마세요. 우리는 3장과 4장에서 위험을 감수하고 빠르게 실패하는 것의 중요성에 대해 많이 이야기했습니다. 깨달은 매니저가 있는 상황에서 실패는 빠르게 배우고, 당신이 할 수 있는 것과 할 수 없는 것의 한계를 발견하며, 시간이 지나면서 그 한계를 늘려가는 훌륭한 방법입니다. 업무상 여행을 많이 다니는 우리 친구 Steve Hayman은 종종 이렇게 말했습니다. "1년에 적어도 한 번은 비행기를 놓치지 않는다면, 공항에 너무 일찍 도착하고 있는 것이다." 이는 어떤 종류의 제품을 만드는 것에 대한 훌륭한 비유입니다. 1년에 적어도 한 번은 실패하지 않는다면, 충분한 위험을 감수하지 않고 있는 것입니다. 그리고 추가적인 책임을 추구하는 것처럼, 위험을 감수하는 것은 당신이 더 큰 일들을 할 수 있다는 것을 보여주는 방법입니다.

일에서 위험을 감수하지 않으면 실패는 적겠지만, 큰 성공도 적을 것입니다. 좋은 매니저는 자신들이 무엇을 할 수 있고 할 수 없는지 알아보기 위해 한계를 밀어붙이려는 팀을 원하며(그 과정에서 많은 것을 배우기 위해), 당신이 실패했을 때 부드러운 착지를 제공할 것입니다. 실패했을 때는 책임을 지고, 비난할 대상을 찾지 말며, 무슨 일이 일어났는지와 같은 실패를 다시 피하기 위해 무엇을 할 수 있는지 문서화하세요. 반복하고, 헹구고, 다시 반복하세요.

어른처럼 행동하라. 뻔해 보이는 제안들의 긴 목록에서 또 다른 권고사항입니다: 사람들에게 어떻게 행동하고 당신을 어떻게 대해야 하는지 가르치는 것은 당신의 책임입니다. 나쁜 매니저들은 종종 어떤 주도권, 책임감, 또는 규칙 위반이라도 짓밟음으로써 팀이 아이들처럼 행동하도록 훈련시킵니다. 이런 매니저를 겪었다면, 모든 매니저들로부터 이런 종류의 대우를 기대하게 되는 경우가 많습니다.

확실하지 않은 것들에 대해 질문하라. 매니저가 당신이 동의하지 않는 결정을 내린다면, 그녀와 논쟁하거나 그녀가 결정을 내린 전제에 대해 질문하는 것을 두려워하지 마세요. 이것이 장애물이 되라는 허가증은 아니지만, 당신이 그녀에게 없는 정보나 경험을 가지고 있다면 "예스맨"이 되는 것은 리더십 위치에 있는 사람에게 도움이 되지 않습니다.

당신의 매니저는 천리안을 갖고 있지 않습니다: 조직에서 과도하게 소통하는 사람을 찾는 것은 드물기 때문에, 그녀가 무슨 일이 일어나고 있는지 묻기 전에 당신이 무엇을 하고 있는지 팀 리더에게 업데이트하는 것을 주저하지 마세요. 장애물에 부딪히거나, 승리를 거두거나, 무언가가 필요하거나, 무언가를 기대할 때 그녀에게 간단한 메모를 보내세요. 이는 매니저가 당신이 무엇을 하고 있는지 알도록 하는 훌륭한 방법일 뿐만 아니라, 우리는 영리한 엔지니어들이 마이크로매니징을 다루는 방법으로 이 기법을 극단적으로 활용하는 것을 보았습니다: 매니저가 계속 당신을 확인한다면, 그녀가 당신을 확인하는 빈도와 같은 빈도로 적극적으로 이메일을 보내는 것은 그녀가 물러서게 만드는 확실한 방법입니다.

이런 기법들은 이상적인 조직에 있을 때 잘 작동하지만, 조직이 이상적이지 않을 때는 어떨까요?

우리는 사람들을 신뢰하거나, 최소한 그들에게 의심의 여지를 주는 것을 크게 지지하지만, 오피스 정치꾼을 신뢰하는 것은 심각하게 커리어를 제한하는 행동이 될 수 있습니다.

오피스 정치꾼은 처음 만났을 때 발견하기 어려울 수 있는데, 그는 관계를 관리하고 사람들을 다루는 데 매우 능숙한 경향이 있기 때문입니다. 처음에는 꽤 친근할 수도 있습니다. 그는 보통 상급자 관리를 뛰어나게 하고, 동료들과 부하직원들을 자기 홍보의 수단으로 사용하는 것은 더욱 뛰어나게 합니다. 그는 다른 사람들을 비난하기를 빨리 하지만, 기회가 주어졌을 때 공로를 가로채는 것은 더욱 빠릅니다. 그는 보통 직접적으로 대립적이지는 않지만, 대신 당신이 그를 좋게 생각하도록 당신이 듣고 싶어 하는 말을 해주는 것을 선호합니다. 그가 당신을 이용하거나 조종할 수 없다면, 당신을 무시하거나, 당신을 위협으로 본다면 당신을 약화시키려 할 것입니다. 그와 한동안 일해본 후에는 그를 발견하기 쉽습니다: 그는 실제로 영향력을 미치는 것보다 영향력 있어 보이는 데 더 많은 시간을 씁니다.

우리는 오피스 정치꾼을 피하라고 조언합니다: 가능한 곳에서는 그를 우회하되, 조직에서 그보다 위에 있는 다른 사람들에게 부주의하게 그를 험담하지는 마세요. 그가 누구를 속였고 누가 그를 꿰뚫어 보는지 알기가 매우 어렵기 때문입니다. 만약 당신이 고개를 숙이고 흥미로운 기술을 구축하는 데 집중하는 것을 좋아하는 종류의 사람이라면, 오피스 정치꾼이 주변에 있을 때는 이 전략을 재고해볼 필요가 있을 것입니다. "게임을 하기"를 원하지 않아서 승진에 에너지를 쏟지 않는다면, 오피스 정치꾼이 당신보다 승진하는 것을 발견할 수도 있으며, 그 경우 당신은 이제 나쁜 매니저 그리고 오피스 정치꾼을 갖게 된 것입니다. 이에 대한 자세한 내용은 조직을 이용하기을 참조하세요.

회사가 성장함에 따라, 그들은 이익을 관리하고, 위험을 줄이고, 예측 가능성을 높이고, 조직 자체의 거대한 무게를 지탱하기 위한 노력으로 관료제와 프로세스를 개발합니다. 시간이 지나면서, 이 관료제는 회사가 성공하는 것을 방해하는 지점까지 성장할 수 있습니다. 나쁜 매니저들과 마찬가지로, 나쁜 조직들에 대해서도 많이 쓰여졌기 때문에, 우리는 개별 기여자들에게 가장 자주 영향을 미치는 조직적 문제들의 몇 가지 예만 검토하겠습니다.

대부분의 회사들이 엔지니어링 중심이 아니라는 것은 단순한 사실입니다. 즉, 엔지니어들은 일반적으로 기술적이지 않은 비즈니스 목표를 달성하기 위한 수단입니다. 이는 회사를 운영하는 사람들이 아마도 그들 시스템의 기술적 기반을 이해하지 못하고, 단지 비즈니스에 의해 그들에게 부과된 요구사항만 이해한다는 것을 의미하며, 그래서 그들은 엔지니어링에 비현실적인 요구를 하게 됩니다. 기술적으로 유능한 임원이 이런 종류의 회사에 들어가서 자신의 조직을 방어하기 위해 싸운다 하더라도, 그녀는 종종 비즈니스의 요구를 충족하기 위해 직원들의 건강과 정신을 희생할 의향이 있는 사람으로 교체되는 자신을 발견하게 될 것입니다. 일반적으로 당신은 이것을 비현실적인 마감일과 프로젝트를 제시간에 완료할 자격을 갖춘 기술 인력의 부족의 형태로 직접 보게 될 것입니다. 제품을 효과적으로 실행하기에 충분한 하드웨어를 확보하는 데 어려움을 겪거나, 몇 백 달러짜리 하드웨어 구매로 해결될 일을 팀이 몇 주 동안 다시 작성하는 데 보내는 것을 발견할 수도 있습니다. 이는 불행히도 엔지니어들을 가치 있게 여기지 않고 그들을 "작업 단위"나 "자원"으로 취급하며, 회사가 어떻게 운영되는지에 대해 그들에게 발언권을 주지 않는 회사의 전형입니다.

가장 심각하게 나쁜 조직들은 봉건제도를 닮은 경직된 명령과 통제 구조를 가지고 있습니다. 몇 년 전, 우리 친구 Terrence는 팀 간에 버그를 전달하는 데 엄격한 규칙을 가진 회사에서 일했는데, 결국 다른 팀이 Terrence의 제품이 몇 시간에 걸쳐 메모리 부족을 일으키는 버그를 만들었습니다. 이에 대해 책임이 있는 팀 멤버들에게 이메일을 보내거나, 그들의 커밋 로그나 소스 코드를 보는 대신, 그는 밤새 버그를 재현하고, 데이터를 수집하고, 자신의 케이스를 구축했습니다. Terrence는 이 이메일을 자신의 매니저에게 보냈고, 매니저는 그 이메일을 자신의 디렉터에게 보냈으며, 디렉터는 버그를 만든 팀의 디렉터에게 이메일을 보냈습니다. 이 디렉터는 그 팀의 매니저에게 이메일을 보냈고, 매니저는 자신의 팀에서 누가 해당 소프트웨어에 대해 책임이 있는지 알아냈습니다. 10일이 넘은 후, Terrence는 두 명의 매니저, 두 명의 디렉터, 그리고 세 명의 다른 엔지니어들과 함께 버그에 대해 논의하고 다음 출시에 맞춰 수정할 수 있는지에 대해 회의하는 자신을 발견했습니다. 터무니없게 들리나요? 슬프게도, 이런 종류의 일은 항상 일어납니다. 대조적으로, Fitz가 Google에서의 첫 주 동안 Gmail에서 오타를 발견했습니다. 그는 소스 코드를 열고, 오타를 수정한 다음, Gmail 팀에 패치를 이메일로 보냈고, 그들은 그에게 진심으로 감사했습니다.

많은 회사들은 조직 계층구조에 집착하는 사람들로 가득 차 있습니다.^[49] 이는 끝없는 권력 투쟁을 초래하며, 매니저들은 종종 엔지니어들이 다른 팀으로 이전하는 것을 막아서 자신의 팀이 가치 있는 기여자를 잃는 것을 보호하려 합니다. 회사와 엔지니어 모두에게 올바른 일이 이전을 허용하는 것일 때조차 말입니다.

당신의 회사가 당신을 못된 아이처럼 대한 적이 있나요? 지나치게 열성적인 회사 방화벽 때문에 무해한 외부 웹사이트에 접근할 수 없나요? 상세한 타임카드로 하루의 모든 순간을 세심하게 기록해야 하나요? 일부 조직들은 심지어 매주 작성하는 코드 줄 수와 같은 무의미하고 (보통 매우 부정확한) 방법으로 당신의 생산성을 측정하기까지 합니다. ^[50]

또 다른 조직들은 출시하는 제품의 수와 품질이 아니라 참석하도록 초대받는 회의의 수로 자신의 성공을 판단하는 직원들을 양성할 것입니다.

마지막으로, 당신의 회사는 집중력, 비전, 또는 방향성과 같은 중요한 것들이 부족할 수 있습니다. 이는 종종 너무 많은 주인들이나 "위원회에 의한 설계"의 결과이며, 이는 상충하는 명령들이 일반 직원들에게 내려보내지는 결과를 낳습니다. 그래서 당신은 일관된 방향이 아니라 점점 더 좁은 원을 그리며 움직이게 됩니다.

많은 나쁜 회사들이 이런 위반 행위들과 훨씬 더 많은 것들에 대해 유죄입니다. 그럼에도 불구하고, 이런 회사들은 사람들로 구성되어 있으며, 사람들이 당신을 도와주도록 하기 위해 활용할 수 있는 여러 팁과 요령들이 있습니다.

무엇보다도, 조직에서 당신이 무엇을 해낼 수 있는지 알아두세요—허가를 요청하는 것이 책임을 다른 사람에게 떠넘길 기회를 주기는 하지만, 누군가가 당신에게 "안 된다"고 말할 기회도 만들어냅니다. 상급자 중 한 명으로부터 명시적으로 승인을 받지 않고도 조직에서 무엇을 해낼 수 있는지 아는 것이 중요하지만, 가능한 한 회사에 옳다고 생각하는 일을 하라고 조언합니다.

용서를 구할 준비가 되어 있다 하더라도, 싸움을 현명하게 선택하세요. 무언가에 대해 당신의 케이스를 변호하거나 회사의 다른 누군가와 맞서야 할 때마다, 당신은 정치적 자본을 소비하고 있는 것입니다. 중요하지 않은 많은 싸움들에서 이기는 데 모든 자본을 소비한다면, 중요한 일들에 관해서는 계좌에 남은 것이 없다는 것을 발견하게 될 것입니다. 전략적이 되어서 중요한 것들이나 당신이 이길 어느 정도 가능성이 있다고 확신하는 것들을 위해 싸우세요. 이길 수 없다는 것을 알고 있는 싸움에 모든 자본을 날려버리는 것은 무의미하고, 스트레스를 주며, 아무런 좋은 이유 없이 커리어를 제한합니다. 자세한 내용은 정치적 은행 계좌를 참조하세요.

"용서를 구하는" 경로를 택하기로 결정한다면, 당신의 아이디어들—특히 더 위험한 아이디어들—에 대한 사운딩 보드로 사용할 수 있는 회사의 동료들과 친구들을 두는 것이 유용합니다.

이런 사람들은 회사에서 당신이 무엇을 해낼 수 있고 없는지, 그리고 어떤 아이디어들이 받아들여지지 않을지에 대해 좋은 감각을 가지고 있어야 합니다.

마케팅의 누군가가 Fitz에게 Google의 임원들 사이에서 자신의 Data Liberation 팀에 대한 인식을 높이라고 제안했을 때, Fitz는 사운딩 보드 동료들에게 아이디어를 던져보았습니다: Data Liberation 브랜드의 볼트 커터와 잠긴 굿즈 상자들(물론 열쇠는 안에 잠겨 있는)을 임원들에게 주는 것이었습니다. 그는 진행하기로 결정했고 큰 성공을 거두었습니다. 몇 년 후, Fitz가 좀 "선정적인" 굿즈를 인쇄하는 것을 고려하고 있을 때, 같은 사운딩 보드는 그 계획이 너무 위험하다는 우려를 표현했고 Fitz는 그 계획을 취소하기로 결정했습니다. 허가를 요청하지 않고 행동할 것이라면, 직감을 믿는 것이 좋지만, 신뢰할 수 있는 출처로부터의 두 번째 의견은 매우 귀중합니다.

회사에서 변화를 만드는 또 다른 전략은 풀뿌리 수준에서 당신의 아이디어가 받아들여지도록 하는 방법을 찾는 것입니다. 충분한 사람들이 당신의 아이디어를 받아들이거나 특정 제품을 사용하도록 할 수 있다면, 관료제가 당신을 짓밟기에는 종종 너무 늦을 것이고, 경영진은 그것을 알아차리고 받아들이거나 반대 행동을 취하도록 강요받을 것입니다(그리고 그것은 그들에게, 맞습니다, 짐작하셨겠지만, 정치적 자본을 소비시킵니다!). 이는 많은 엔지니어들이 수년간 사용한 전략으로, 예를 들어 자신들의 삶을 훨씬 더 즐겁게 만들기 위해 오픈 소스 도구들을 일상 워크플로우에 몰래 도입하는 데 사용했습니다.

특히 아이디어들은 매혹적인 것들입니다: 누가 공로를 인정받는지 신경 쓰지 않는다면 멀리 갈 수 있습니다! 때로는 사람들이 아이디어를 자신의 것으로 공로를 인정받을 수 있을 때만 아이디어를 퍼뜨린다는 것을 발견하게 될 것이므로, 무엇이 더 중요한지 결정해야 합니다: 당신이 공로를 인정받는 것인지, 아니면 아이디어가 퍼지는 것인지. 당신의 말이 다른 사람(아마도 경멸하는)의 입에서 나오는 것을 듣는 것이 고통스러울 수 있다는 사실에도 불구하고, 그것은 종종 아이디어가 여행하는 가장 수월한 방법입니다. 우리는 이런 일이 크고 작은 회사들에서 몇 번이고 일어나는 것을 보았습니다: 임원의 입에서 나오는 고상한 개념들과 아이디어들이 그녀의 조직 내 누군가로부터 시작된 것입니다. 이 경우 당신의 아이디어가—그렇지 않았다면 들리지 않았을—도달할 수 있는 광범위한 청중에 대해 생각해보세요!

개인과 마찬가지로, 회사에서 나쁜 습관을 없애는 것은 어렵습니다. Ben의 초기 선생님 중 한 분은 이런 말을 하곤 했습니다: "나쁜 습관을 단순히 멈추는 것은 불가능하다; 좋은 습관으로 대체해야 한다." 금연을 시도해본 적이 있는 사람이라면 누구나 이 현상을 잘 알고 있을 것입니다. 기업들도 마찬가지입니다—나쁜 습관을 성공적으로 없애려면, 그것을 대체할 더 나은 것을 찾으세요. 특정 주간 회의가 마음에 들지 않나요? 다른 종류의 회의나 대안적인 (더 효과적인) 의식으로 대체하세요. 쓸모없는 보고 프로세스가 마음에 들지 않나요? 그것에 대해 불평하지 말고; 무시하기에는 너무 매력적인 유용한 것을 작성하세요. 좋은 대체 습관을 찾았다면, 변화 회피의 관성을 극복해야 하므로, 몇 주 동안 새로운 의식을 "시도해보자"고 제안하는 것을 권합니다. 이렇게 하면 새로운 것이 덜 영구적이고, 덜 무섭게 보이며, 모든 사람이 새로운 의식을 좋아한다는 것이 밝혀지면, "시험" 기간이 끝날 때쯤에는 그들이 애초에 그것이 시험이었다는 것을 잊어버렸을 것입니다.

매니저든 개별 기여자든, 당신은 시간의 일부를 상향 관리에 써야 합니다. 이것이 의미하는 바는 당신의 매니저와 팀 외부의 사람들이 당신이 무엇을 하고 있는지 알 뿐만 아니라, 당신이 그것을 잘하고 있다는 것을 알도록 보장하려고 노력해야 한다는 것입니다. 어떤 사람들은 이런 "자신을 팔아넘기는" 방식을 불쾌하게 여기고, 그럴 수도 있지만, 이렇게 하는 것의 이익은 엄청납니다.

Chapter 6. Users Are People, Too에서 언급하겠지만, 가능할 때마다 적게 약속하고 많이 전달해야 합니다. 모든 추정치를 보수적으로 잡고 마감일을 늘리라고 주장하는 것은 아니지만, 가능한 한 전달할 수 없는 것들을 약속하는 것을 피하려고 노력하세요. 원하는 것보다 더 자주 "안 된다"고 말해야 한다 하더라도 말입니다. 지속적으로 마감일을 놓치거나 기능을 빼먹는다면, 회사의 다른 사람들이 당신을 신뢰할 이유가 줄어들 것이고 무언가를 완수할 사람을 찾을 때 당신을 건너뛸 가능성이 높습니다.

우리는 다른 거의 모든 것보다 제품 출시에 에너지를 집중하라고 권합니다. 제품을 출시하는 것은 회사에서 거의 다른 어떤 것보다도 신뢰성, 평판, 그리고 정치적 자본을 줍니다. 제품을 출시하는 것은 당신이 무언가를 성취하고 있다는 것을 보여주는 높은 가시성의 이벤트입니다. 코드베이스를 정리하고 리팩터링하는 데 많은 시간을 보내는 것이 유혹적일 수 있지만, 이런 종류의 방어적 작업에 시간의 절반 이상을 할애한다면, 상급자들을 포함하여 팀 외부의 누구에게도 거의 가치를 인정받지 못한다는 것을 경험으로부터 배웠습니다. 그러면 당신은 시간에 대해 보여줄 (정치적으로) 중요한 것이 거의 없는 다소 당황스러운 위치에 있는 자신을 발견하게 될 것입니다.^[52] 이는 인정받지 못하는 좋은 방법일 뿐만 아니라, 제품이 취소되는 좋은 방법이기도 합니다.

어떤 종류의 회사에서 일하든, 믿거나 말거나, 자신을 위한 일종의 운을 만드는 것은 그리 어렵지 않습니다. The Luck Factor의 저자인 Richard Wiseman^[53]은 사람들이 우연한 기회를 발견하는 능력을 테스트하기 위해 수행한 실험에 대해 썼습니다:^[54]

그는 계속해서 운이 좋은 사람들이 "우연한 기회를 만들고 알아차리는 데 능숙하다"고 언급합니다. 우리는 같은 원칙이 회사에서 기회를 만드는 데도 적용된다고 생각합니다: 법조문 그대로 일을 수행하고 다른 모든 것을 배제하고 오직 자신의 일을 완수하는 데만 집중한다면, 당신에게는 우연한 기회가 거의 없을 것입니다. 기회가 주어졌을 때 다른 사람들이 그들의 일을 완수하도록 도와준다면, 그것이 당신의 일의 일부가 아닐지라도, 그들이 호의를 되돌려줄 것이라는 보장은 없습니다(그리고 "눈에는 눈" 식의 기대도 있어서는 안 됩니다). 하지만 많은 사람들이 기회가 주어진다면 미래에 기꺼이 호의를 갚을 것입니다.

모든 회사는 조직도 밖에 존재하는 회색 시장 호의 경제를 가지고 있으며, 그런 호의들은 당신이 정치적 은행 계좌를 채우는 데 사용할 수 있는 주요한 것들 중 하나입니다. 보통 당신이 빠르고 쉽게 할 수 있으면서 회사에 도움이 되지만 다른 사람의 일인 것이 있으며, 이런 일들을 할 기회에 눈을 열어두고 있다면(많은 경우, 누군가가 직접 나와서 당신에게 무언가를 해달라고 요청할 것입니다), 이 호의 경제에서 당신의 은행 계좌에 약간의 크레딧을 얻게 됩니다. 이런 크레딧들을 일련의 작은 베팅으로 생각해보세요: 일부는 절대 당신에게 갚지 않을 것이고, 다른 것들은 본전을 갚을 것이며, 또 다른 것들은 엄청난 배당금을 지불할 것입니다. 어떤 베팅이 성과를 낼지 알기는 어렵지만, 시간이 지나면서 성과를 낼 한 가지는 사람들이 당신을 곤경에서 도와준 사람으로 기억할 것이라는 점입니다. 나중에, 당신이 곤경에 처해서 그들에게 전화를 걸 때, 그들이 도움을 찾아왔을 때 당신이 "내 일이 아니다"라는 뚱뚱한 대답을 했다면보다 상당히 더 기꺼이—심지어 열심히—당신을 도와줄 것입니다. "갚음"을 받지 못한다 하더라도 누군가를 돕는 과정에서 종종 새로운 것을 배우게 될 것이고, 다른 사람들을 돕는 것은 기분 좋은 일이므로, 약간의 시간과 노력 외에 잃을 것이 무엇이 있겠습니까?

호의 경제에 대한 가장 흥미로운 것 중 하나는 직장이나 회사를 떠날 때 당신의 은행 계좌가 단순히 비워지지 않는다는 것입니다—떠난 후에도 종종 회사의 사람들에게 도움을 요청할 수 있을 것입니다. 이것이 회사를 떠날 때 아무리 유혹적으로 보일지라도 다리를 태워서는 절대 안 되는 이유입니다.^[55]

대부분의 엔지니어들과 같다면, 승진하기 위해 필요한 것은 일을 잘하는 것뿐인 논리적인 승진 과정을 기대할 것입니다. 불행히도, 이런 세상은 가장 깨달은 회사들에서만 존재합니다. 대부분의 회사에서는 승진하기 위해 "승진 게임을 하는" 데 어느 정도의 노력을 기울여야 합니다(보통 일을 잘하는 것에 추가로)..

직장, 급여, 그리고 팀에 만족한다면, 승진 게임을 하지 않고 이미 있는 직책과 직급에서 정착하기로 선택할 수도 있습니다. 이는 많은 상황에서 당신을 취약하게 만들 수 있습니다—예를 들어, 회사가 재조직되어 새로운 팀으로 배치되거나, 나쁜 매니저를 만나거나, 오피스 정치꾼의 엄지손가락 아래 들어가게 되는 경우 말입니다.

조직에서 더 높은 위치에 올라갈수록(개별 기여자든 매니저든), 회사 내에서 당신의 운명에 대한 더 많은 통제권을 가질 수 있습니다. 현재 위치에서 편안할 때 승진을 위해 약간의 노력을 기울이는 것은 회사나 팀에 문제가 생겼을 때 당신의 안전과 행복에 투자하는 훌륭한 방법입니다. 당신의 성과들을 기록하고 자기 평가에 활용하세요. 이력서를 업데이트하고^[56] 매니저나 승진 위원회와 공유하세요. 승진 과정에 대해 읽고 매니저와 승진을 위해 체크해야 할 항목들에 대해 이야기하고, 체계적으로 모든 항목을 체크해 나가세요. 승진이 주관적이고 결정적이지 않다 하더라도, 당신에게 유리한 확률을 높이기 위해 할 수 있는 일이 많이 있습니다.

모든 회사는 쓰여지지 않았지만 권력과 영향력이 흐르는 "그림자" 조직도를 가지고 있습니다. 이 그래프의 노드를 구성하는 사람들의 유형은 몇 가지뿐입니다.

연결자들은 조직의 모든 구석에서 사람들을 아는 사람들이고, 팀의 누군가를 모른다면 당신을 위해 올바른 사람을 찾을 수 있습니다. 때로는 무언가를 완수하는 것이 단순히 대화할 올바른 사람을 찾는 문제이고, 연결자가 그 사람을 찾는 데 도움을 줄 수 있습니다.

고참들은 높은 직급이나 멋진 직책을 가지지 않을 수도 있지만, 오랜 시간 동안 있었기 때문에 일반적으로 많은 제도적 지식을 가지고 있고 많은 영향력을 행사합니다. 이들은 조직이 왜 특정한 방식으로 작동하는지 이해하려고 할 때나, 많은 사람들이 존경하는 지지자가 필요할 때 찾아가기 좋은 사람들입니다.

사람들은 대부분 이것을 농담으로 이야기하지만, 행정 비서들은 자신들이 일하는 임원들의 대리인이기 때문에 조직에서 엄청난 양의 권력과 영향력을 행사합니다. 더 중요한 것은, 그들이 보통 일들이 원활하게 돌아가도록 엄청난 양의 일을 하므로, 그들을 화나게 하는 것은 당신 자신(그리고 당신의 커리어)에게 위험합니다. 그리고 행정 비서에게 친절하게 대할 기회를 절대 놓치지 마세요—그들은 호의 경제의 초석입니다.

어떤 큰 회사에서든 충분히 오래 일하다 보면, 임원(또는 모르는 바쁜 사람)에게 무언가를 요청하기 위해 이메일을 보내야 하는 상황에 처하게 될 것입니다. 아마도 제품이나 팀을 위해 무언가가 필요하거나, 잘못을 바로잡으려고 할 것입니다. 어떤 경우든, 이는 아마도 이 사람과 처음으로 소통하는 것일 것입니다. 이런 상황에서, 거의 모든 사람이 같은 초보자 실수를 합니다: 횡설수설하고, 격분하고, 열변을 토합니다.

Fitz는 (Apple에서 일하던 당시) 14년도 더 전에 어머니께 불량 iMac을 사 드렸고, 동료의 조언에 따라 Steve Jobs에게 "짧은" 이메일을 보냈습니다.^[57] 이 이메일은 임원에게 도움을 효과적으로 요청하는 방법의 거친 프로토타입 역할을 했습니다:

날짜: 2001년 2월 1일 (목)

받는이: sjobs@apple.com

제목: 우리 하드웨어로 인한 끔찍한 고객 경험—제가 무엇을 할 수 있을까요?

이 문제를 해결하기 위해 제가 무엇을 할 수 있는지 조언해 주신다면 정말 감사하겠습니다. 이는 Apple과 저 모두에게 매우 곤란한 일입니다.

지난 어머니날에 어머니께 iMac을 사 드렸습니다—어머니는 뉴올리언스의 한 몬테소리 학교 교감으로, 학교에서는 오래된 Macintosh를 사용하고 계십니다. 어머니는 iMac을 무척 기뻐하셨고, 학교 실습실용 iMac을 더 사기 위한 예산까지 확보하셨습니다.

하지만 제가 사 드린 딸기색 iMac은 완전한 불량품으로 드러났습니다.

현재 상황이 이렇습니다. 어머니는 제가 못된 장난을 친 줄 아시고, 아는 모든 분께 자신의 iMac이 고물이라고 말씀하고 계십니다. 그리고 제가 아는 Apple 직원 누구도 이 문제를 어떻게 해야 할지 모릅니다.

다른 하나를 새로 사는 것 말고, 어머니께 정상 작동하는 iMac을 드릴 수 있는 방법이 있을까요?

존경을 담아,

-Fitz

20시간도 채 지나지 않아 Steve 밑에서 일하는 누군가에게서 Fitz에게 전화가 왔고, 2주 뒤 어머니는 새 iMac(더는 불량이 아닌)을 받으셨습니다.

여기 큰 비밀이 있습니다: 잘못된 것을 바로잡을 기회가 주어지면, 권력 있는 위치의 사람들은 좋아서 옳은 일을 하려 합니다—바쁜 임원들조차도 말입니다(많은 이들이 잘못된 것을 바로잡는 것을 즐기고, 절대적으로 모든 이들이 약간의 추가 정치적 자본을 얻는 가치를 이해합니다). 불행하게도, 이런 사람들의 이메일 받은 편지함은 끝없는 분산 서비스 거부 공격처럼 보이며, 처음 보는 사람에게서 단락 구분도 없이 3,000단어짜리 텍스트 벽이 도착하면, 15단어쯤 읽고 Delete 키를 누른 뒤 다음 메일로 넘어갈 가능성이 큽니다.

하지만 반대로, 이메일을 10초 만에 읽고 마법 지팡이를 휘둘러(즉, 부하 중 한 명에게 실행하라고 메일을 보내) 문제를 해결할 수 있다면, 아마 그렇게 할 것입니다. 몇 초만 위임하는 데 쓰고, 그 대가로 당신으로부터 큰 정치적 자본을 얻게 됩니다.

수년간의 시행착오 끝에, 더 짧은 이메일일수록 답장을 받을 가능성이 높다는 것을 깨달았습니다.

우리는 이것을 "세 가지 핵심 항목과 실행 요청" 기법이라고 부르며, 처음 연락하는 거의 누구에게든 무언가를 요청할 때 실제 행동을 이끌어내거나—최소한—답장을 받을 가능성을 비약적으로 높여줍니다.^[58] 임원에게만 해당되는 것이 아닙니다.

좋은 "세 가지 핵심 항목과 실행 요청" 이메일은 (많아도) 세 가지 핵심 항목으로 현재 사안을 요약하고, 하나—오직 하나—의 실행 요청만 담습니다. 그게 전부입니다—쉽게 전달될 수 있는 이메일을 써야 합니다. 장황하게 쓰거나 완전히 다른 네 가지를 한 이메일에 넣으면, 상대는 답할 항목 하나만 고를 것이고, 그건 대개 당신이 가장 중요하지 않다고 여기는 항목일 것입니다. 더 나쁜 건, 인지적 부담이 너무 커서 아예 메일이 버려질 수도 있다는 겁니다.

핵심 항목들은 짧은 문장이어야 합니다(각 항목은 줄바꿈 없이 한 줄에 들어가야 합니다). 실행 요청은 가능한 한 짧아야 합니다. 누구에게서든 답장을 원한다면, 상대가 본문 인라인으로 답하기 쉽게 만드세요. 한두 단어로 답할 수 있으면 가장 좋습니다. 한 문단에 여섯 개 질문을 하지 말고—문단당 한 질문, 이상적으로는 이메일당 한 질문으로 제한하세요. 마지막으로 이메일에는 HRT가 가득해야 합니다: 공손하고, 존중하며, 문법과 철자 오류가 없어야 합니다. 배경 설명을 꼭 포함해야 한다면 이메일 맨 끝(심지어 서명 뒤)에 두고, "자세한 내용" 또는 "배경"이라고 명확히 표시하세요.

돌이켜보면, 우리는 Fitz의 프로토타입 이메일이 조금 장황했다고 생각합니다—오늘 우리가 쓴다면, 아마 다음과 같은 형태에 더 가까울 것입니다:

날짜: 2001년 2월 1일 (목)

받는이: sjobs@apple.com

제목: 나쁜 고객 경험—도와주실 수 있나요?

어머니는 아는 모든 분께 자신의 iMac이 고물이라고 말씀하시고, 제가 아는 Apple 직원 누구도 이 문제를 어떻게 해야 할지 모릅니다.

어머니께 정상 작동하는 iMac을 드릴 수 있는 방법이 있을까요?

존경을 담아,

-Fitz

이렇게 다시 쓴 이메일은 장식적인 설명을 많이 덜어냈지만, 이제 바쁜 임원도 10초 안에 읽을 수 있습니다.

우리의 커리어 과정에서, 우리는 이런 모든 기법들을 반복해서 사용하여 일을 완수했습니다. 하지만 때로는 세상의 모든 팁과 요령들이 직장을 고치는 데 충분하지 않을 수 있습니다.

만약 배가 고파서 식당을 찾고 있다면, 길에서 보이는 식당의 모습이 정말 중요합니다. 역겹거나 매력적이지 않으면 아예 들어가지 않습니다. 따뜻하고 친근하거나 주인이 친절하면 공정한 기회를 줄 의향이 생깁니다. 제품의 잘 설계된 첫 사용감이 주는 감정적 충격을 과소평가하지 마세요. iPad나 Nest 온도조절기를 개봉해본 적이 있다면 우리가 무슨 말인지 정확히 알 것입니다.

초보자에게 당신의 제품은 어떤 모습일까요? 환영받는 느낌을 주고, 탐색을 장려하나요? 반대로 소프트웨어 첫 세션을 시작하는 전문가에게는 익숙하고 합리적으로 보이나요? 첫눈에, 당신의 앱은 즉각적인 생산성을 외치나요? 아니면 가파른 학습 곡선과 끝없는 눈물을 예고하나요? 더 구체적으로, 사용자가 소프트웨어를 실행한 후 첫 30초 동안 무엇을 경험하나요? 단순히 지적인 답변(“선택 메뉴와 로그인 박스를 본다”)만 하지 말고, 감정적인 답변도 해보세요. 새로운 사용자가 1분 후에 어떻게 느끼나요? 힘을 얻나요, 아니면 그저 혼란스러우나요? 그 느낌을 개선하기 위해 무엇을 할 수 있을까요? 한 단계 물러서서 제품 웹사이트를 보세요. 좋은 상점가처럼 전문적이고 매력적으로 보이나요? 소프트웨어가 진지하게 받아들여지려면 이런 것들을 진지하게 받아들여야 합니다.

많은 프로그래머가 미디어 업계를 싫어합니다. 그냥 다른 모습의 마케팅일 뿐이라고 여기죠. 업계 잡지나 리서치 회사가 문을 두드리면 많은 회사가 모든 걸 제쳐두고 그들의 요청에 굴복합니다. 좋은 (또는 나쁜) 리뷰가 제품 인식을 좌우할 수 있다는 걸 알기 때문입니다. 하지만 엔지니어들은 이런 권력과 복종을 못마땅해하는 경향이 있습니다.

예를 들어, Apache 소프트웨어 재단(ASF) 구성원들이 분석가와 상호작용하는 데 문제가 있었던 때가 있었습니다. 분석가가 ASF에 Apache HTTPD 서버를 설명하는 업계 표준 백서를 요청하면, 전형적인 비아냥거리는 대답은 "다른 사람들처럼 웹사이트의 문서를 읽어보세요"였습니다. 이런 반응은 오픈 소스 개발자들의 실력주의에 대한 깊은 신념을 만족시키긴 했지만, 전체적으로는 "특히 기업 사용자들 사이에서" 대중 인식에 역효과를 낳았습니다. 결국 ASF의 "PR 담당자"가 커뮤니티 구성원들에게 이런 태도에 대해 재교육하고 분석가들과 더 생산적으로 일하도록 노력했습니다. 아무리 짜증나더라도 수동공격적으로 시스템과 싸우는 것은 말이 안 됩니다. 레스토랑 리뷰어에게 줄 맨 뒤로 가라고 말하는 것과 다를 바 없습니다. 리뷰어가 특별 대우를 받아야 할까요? 아마 아닐 겁니다. 하지만 원칙의 문제로 그에게 복수할 가치가 있을까요? 절대 아닙니다. 과정에서 자신만 해칠 뿐입니다. 싸울 곳을 신중히 선택하세요.