들어가기 앞서
앞 글에서 1~4장을 다뤘다. 효과성은 능력이 아니라 사고방식이고, 리더가 그걸 정의하고 맡기고 키운다는 '개념 편'이었다. 5~7장은 그 사고방식을 현장에 옮기는 '실전 편'이다. 효율성을 갉아먹는 안티패턴을 카탈로그로 훑고(5장), 개인 기여자에서 매니저로 넘어가는 전환을 다루고(6장), 마지막으로 매니저를 넘어 리더로 자신을 확장하는 길(7장)로 끝난다.
분량이 꽤 되니 1~4장처럼 장별로, 대신 핵심은 빠뜨리지 않고 정리한다.
5장. 일반적인 효율성 안티패턴
5장은 효율성을 갉아먹는 안티패턴 17개를 모아 '증상 → 문제 → 해결책' 순으로 정리한 카탈로그다. 흥미로운 건 출발점이다. 대부분의 안티패턴은 나쁜 의도가 아니라 좋은 의도에서 시작한다. 더 잘 돕고, 더 완벽하게 하고, 더 깊이 알려는 욕구. 그 장점이 통제되지 않고 과해질 때 단일 장애점, 번아웃, 지식 사일로, 사기 저하로 번진다. 그래서 이 장은 남을 흉보는 목록이라기보다, 리더가 자기 행동을 냉정히 비춰 보는 거울에 가깝다.
책은 안티패턴을 발생 원인에 따라 네 유형으로 나눈다. 원인을 알아야 누가 고쳐야 하는지가 보이기 때문이다.
효율성 안티패턴 17개, 발생 원인별 4유형 (유형마다 고치는 주체가 다르다)
[개인적] 개인의 성향에서 출발 → 당사자가 직접 바로잡는다
[관행] 프로세스의 결함 → 팀 전체가 표준을 만든다
[구조적] 팀 구성·역할의 문제 → 구조를 다시 짠다
[리더십] 리더 자신의 행동 → 자각, 때로는 상급자가 중재
Plain Text
복사
개인적 안티패턴: 장점이 과해질 때
개인의 성향에서 시작해 개인에게서 끝난다. 처음엔 효율적으로 보이지만 결국 팀 역학을 갉아먹고, 정작 당사자는 자기 기여가 유익하다고 믿는다. 그래서 보통 당사자가 직접 바로잡아야 한다. 다섯이 있다.
전문가(The Specialist)는 특정 모듈만 완벽히 아는 사실상의 수호자다. 누가 그 부분을 물으면 늘 그 사람이 호명되고, 남들은 건드리기를 두려워한다. 문제는 이게 의도가 아니라 상황의 산물이라는 점이다. 같은 모듈에 여러 스프린트 배치되다 보니 어느새 단일 장애점이 됐을 뿐이다. 해법은 전문가를 없애는 게 아니라, 모든 전문가에게 60~80% 수준의 백업 인력을 붙이고 전문가는 리뷰어로 돌리는 것이다. 제너럴리스트(The Generalist)는 정반대다. 너무 넓고 얕게 손대 어느 분야도 깊이가 없다. 의지는 훌륭하지만 '유능하다는 착각'에 그친다. 책이 권하는 건 폭과 깊이를 함께 갖춘 T자형 인재다. 세로 막대는 한 영역의 전문성, 가로 막대는 여러 영역에서 협업하는 능력이다.
강박적인 수집가(The Hoarder)는 스프린트 내내 조용히 작업을 쌓아두다 하나의 거대한 PR로 제출한다. 거대 PR은 리뷰가 부실해지고 통합이 지옥이 된다. 동기는 보통 '제대로 된 기여를 보여주고 싶어서'이거나 '완성도 낮다는 평가가 두려워서'다. 저자의 팀에 있던 존이 그런 경우였다. 뛰어난 실력자였지만 홀로 고립돼 일했고, 크로미움 핵심 모듈을 혼자 맡아 남들이 이해하기 어려운 코드를 만들었다. 저자가 건넨 말이 그를 바꿨다. "코드는 작성하는 것보다 읽히는 경우가 더 많다. 코드는 혼자만의 퍼즐이 아니라 팀을 위한 이야기여야 한다." 존은 협업하는 사람이 됐고, 지나치게 기술적인 설명 습관은 '똑똑한 고등학생에게 말하듯' 다듬었으며, 지식 공유가 자기 가치를 떨어뜨릴까 두려워하다가 후배를 멘토링하며 '지식 공유는 내 중요성을 줄이는 게 아니라 배가시킨다'는 걸 깨달았다. 오늘날 그는 테크 리드를 넘어 동료들의 멘토가 됐다.
남은 둘은 끈질긴 조언자(The Relentless Guide)와 사소한 개선자(The Trivial Tweaker)다. 조언자는 부탁하기도 전에 완벽한 답을 떠먹여, 팀이 스스로 문제를 푸는 힘을 키우지 못하게 하고 본인은 번아웃에 빠진다. 개선자는 가장 감지하기 어려운데, 영향 없는 자잘한 변경에 끝없이 매달린다. 특히 안정된 코드를 그 작동 원리도 모른 채 '리팩터링'이라는 구실로 건드리면 멀쩡하던 곳에서 새 문제가 터진다.
관행에서 비롯된 안티패턴: 누구의 잘못도 아닌 문제
이건 개인이 아니라 프로세스의 결함이다. 그래서 개인에게 책임을 물을 수 없고, 리더 주도로 팀 전체가 표준을 세워야 풀린다. 넷이 있다.
최후의 영웅담(Last-minute heroics)은 출시 직전 누군가의 영웅적 벼락치기로 위기를 넘기고 두고두고 회자되는 장면이다. 문제는 그게 매번 되풀이된다는 데 있다. 매 출시마다 이름 없는 영웅에 의존한다면, 그건 미담이 아니라 프로세스 결함의 신호다. 영웅담은 일시적 안도감을 줄 뿐 숨은 기술 부채를 쌓는다. 답은 영웅이 아니라 체크포인트와 우선순위 백로그, 유지 가능한 페이스 같은 평범한 프로세스다.
종잡을 수 없는 PR 프로세스는 네 가지 증상으로 나타난다. 검토 없이 승인하는 자동 거수기, 자기 PR을 셀프 병합, 작성자와 검토자를 오가며 늘어지는 장수 PR, 마감 직전 몰리는 PR. 흥미로운 건 책이 인용한 구글의 코드 리뷰 연구다. 십수 년에 걸친 수백만 건의 리뷰를 분석했더니, 변경 1건당 검토자는 중간값 1명이고 2명 이상 필요한 크고 복잡한 변경은 전체의 25% 미만이었다. 작은 변경의 첫 피드백까지는 보통 1시간 미만. 좋은 리뷰 프로세스는 무겁고 깐깐한 게 아니라 가볍고 빠른 것에 가깝다.
나머지 둘은 장기간에 걸친 리팩터링과 적당히 넘어가는 회고다. 리팩터링은 '지금이라면 더 잘 짤 수 있다'며 시작했다가 완벽주의나 지식 부족으로 끝없이 늘어진다. 마무리 시점을 못 박고 시간 제한을 두는 게 핵심이다. 회고는 건너뛰거나, 짧게 하거나, 만장일치로 끝내거나, 조치 없이 흩어지면 의미를 잃는다. Start/Stop/Continue나 5 Whys 같은 틀로 근본 원인까지 파고들어야 진짜 회고다.
구조적 안티패턴: 사람이 아니라 구조의 문제
팀 구성과 역할에서 비롯되는, 팀의 장기 생존을 위협하는 문제다. 둘이 있다. 고립된 집단(Isolated clusters)은 큰 팀 안에 소집단이 생겨 토론도 PR 리뷰도 그 안에서만 도는 것이다. 친한 사이의 거수기식 승인이 굳으면 시야가 좁아지고 편견이 낀다.
지식 병목(Knowledge bottlenecks)은 핵심 지식이 소수에게 갇혀 버스 지수가 낮아지는 상황이다. 저자도 크롬 팀 초창기에 겪었다. 코드베이스가 복잡해지며 몇몇이 특정 컴포넌트 지식을 독점했고, 그들이 자리를 비우면 큰 병목이 됐다. 문서화, 코드 소유권 공유, 내부 테크 토크, 교차 훈련, 신참과 고참 페어링으로 사일로를 부수자 결과가 인상적이었다. 인원은 그대로인데 팀의 역량은 기하급수적으로 늘었다. 버스 지수는 높을수록 좋다. 프로젝트가 위기에 빠지려면 엄청나게 많은 사람이 동시에 빠져야 한다는 뜻이니까.
리더십 안티패턴: 거울을 들 차례
마지막 유형은 리더 자신이다. 가장 불편하지만 그래서 가장 중요하다. 여섯이 있다.
과도하게 세세한 관리(마이크로매니징)는 완벽주의 병목, '왜'는 없이 '어떻게'만 지시하는 권위적 태도, 정보를 막는 문지기 노릇으로 나타난다. 책의 처방이 좋다. 리더는 정보를 차단하는 불투명한 벽이 아니라 유리 장벽이 되어야 한다. 중요한 외부 요인은 투명하게 보여주되, 불필요한 잡음으로부터는 팀을 보호하라는 것이다. 범위 관리 실패(Scope mismanagement)는 끝없는 변경 요청에 백로그가 폭증하는 것이다. 변경 요청 자체는 정상이지만, 리더는 그게 '무분별한 수용'으로 변질되는 시점을 알아야 한다. PMI가 발표한 한 사례에서는 원래 18~24개월짜리 문서 이미징 시스템이 4년이나 걸렸다. 사용자 50명이 제각기 요구사항을 던졌는데 정작 사용자들끼리도 합의가 없었고, 양쪽 매니저 누구도 범위를 잡아주지 않았기 때문이다.
과도한 계획(Planning overkill)은 모든 세부를 미리 고민하려다 마비되는 것이다. 한 팀이 할인율 계산 기능을 만들며 온갖 시나리오를 몇 주씩 분석해 극도로 복잡한 구조를 짰는데, 정작 이해관계자는 '모든 제품에 일괄 할인' 정도의 단순한 걸 기대했을 수도 있다. 켄트 벡의 말이 답이다. "한 번의 반복으로 얻는 데이터가 수개월의 추측보다 가치 있다."
남은 셋은 회의적인 리더십, 소극적 리더십, 과소평가다. 회의적인 리더십은 근거 없는 불안으로 사소한 것까지 의심해("왜 리액트죠? 뷰가 더 가볍지 않나요?") 팀의 시간을 우려 달래기에 쓰게 만든다. '신뢰하되 검증하라'는 건전한 회의주의는 좋지만, 두려움을 공격적으로 드러내면 자율성이 무너진다. 소극적 리더십은 더 교묘하다. 하버드 비즈니스 리뷰는 이 방관자형 리더를 '가장 흔한 무능한 리더 유형'으로 꼽는데, 노골적으로 파괴적이지 않아 잘 들키지도 않는다. 못하고 있는 걸 알면서도 "진짜 잘하고 있어!"라고만 말하는 관리자가 그렇다. 마지막 과소평가는 좋은 행동을 제때 인정하지 않는 것이다. 인정받지 못한 모범 행동은 관행으로 자리 잡지 못하고, 묵묵히 일하는 성실한 팀원일수록 투명인간 취급받는다고 느낀다.
6장. 효과적인 매니저
개인 기여자에서 매니저로: 무게중심이 옮겨간다
'나'의 성과 → '우리'의 성과
스타 플레이어 → 코치
코딩 (즉시 결과) → 사람 (지연된 영향)
기술의 깊이 → 소통·전략·사람
Plain Text
복사
'나'에서 '우리'로
대부분의 엔지니어링 매니저는 엔지니어로 출발한다. 그래서 6장의 첫 메시지는 전환이 '승진'이 아니라 '사고방식의 변화'라는 것이다. 무게중심이 기술에서 사람으로 옮겨간다. 저자의 표현으로는 '나(I)'에서 '우리(We)'로, 그리고 스타 플레이어에서 코치로.
신임 매니저 프리야가 그 전환을 보여준다. 처음 며칠은 맡았던 코딩을 내려놓기가 고통스러웠고, 팀의 기술 세부에 다시 뛰어들고 싶은 유혹에 시달렸다. 그러다 깨달았다. 자기 역할은 모든 문제를 푸는 스타 플레이어가 아니라 탁월한 팀을 길러내는 코치라는 것을. 이후 그는 자신의 경험 부족을 공개적으로 인정하고, 노련한 엔지니어와 신참을 짝지어 서로 배우게 하고, 솔직하게 말할 수 있는 심리적 안전감에 집중했다.
전환이 어려운 이유 하나는 만족감의 성격이 바뀌기 때문이다. 코딩은 결과가 즉시 보이지만, 1:1로 팀원의 걱정을 덜고 동기를 심은 효과는 성과로 이어지기까지 시간이 걸린다. 즉각적 성취감 대신 지연된 영향력을 기다리는 인내심, 그게 매니저의 일이다.
새 역할에 안착하기
새 역할의 출발은 도전적이다. 자신이 무능하다고 느끼는 가면 증후군은 흔하고, 책은 그동안의 성취와 긍정적 피드백을 기록해 두고 의심이 들 때 꺼내 보라고 권한다. 첫 주에는 전속력을 기대하면 안 된다. 신뢰는 시간에 걸쳐 쌓이니까. 대신 1:1로 팀원을 한 명씩 알아가고, 프로젝트와 기술 스택을 파악하고, 즉시 풀 수 있는 '빠른 승리'로 작은 성취를 만드는 게 좋은 출발이다.
안착했으면 시간 관리가 발목을 잡는다. 매니저의 하루는 회의와 이메일과 갑작스러운 방해로 쪼개지기 쉽다. 책이 권하는 건 하루를 시간 블록으로 나눠 집중 업무, 회의, 행정 작업에 배정하는 타임 블로킹이다. 비슷한 작업은 묶어 처리하고(컨텍스트 스위칭은 비싸다), 이메일은 계속 확인하지 말고 정해진 시간에만 본다. 그리고 두 가지를 배워야 한다. 팀을 믿고 위임하는 법, 그리고 우선순위에 맞지 않는 일에 '아니오'라고 말하는 법이다. 주간, 월간으로 달력을 되짚어 내 시간이 정말 전략적 우선순위에 쓰였는지 확인하는 것도 잊지 말아야 한다.
여기서 기대치 설정이 따라온다. 매니저가 먼저 자기 역할과 기대치를 분명히 알아야 팀원에게도 명확히 설명할 수 있다. OKR이든 SMART든 틀은 무방하고, 핵심은 각자의 목표를 조직의 더 큰 그림에 연결하는 것이다. 4장에서 본 대로 영향력은 강력한 동기다. 자기 일이 큰 목표에 어떻게 닿는지 알면 책임감이 커진다.
사람을 이끄는 일
이 장의 무게중심은 결국 사람이다. 그 시작은 의사소통인데, 책이 가장 강조하는 건 일관성이다. 팀 회의에서 한 말과 지라에 할당한 업무가 어긋나면 팀원은 혼란에 빠지고, 그게 반복되면 주어진 정보를 믿지 않게 된다. 그래서 회의, 1:1, 메신저, 이메일, 심지어 몸짓 언어까지 수단은 달라도 전하는 원칙은 일관돼야 한다.
그중에서도 1:1은 매니저의 핵심 자리다. 요령은 즉답하지 않는 것이다. 해결책을 바로 떠먹이는 대신 개방형 질문으로 스스로 풀게 해 자립심을 키운다. 현재 업무뿐 아니라 목표와 포부도 묻고, 매번 "장애물 극복을 어떻게 도울까요?"를 빠뜨리지 않는다. 채널도 성격에 맞게 골라 쓴다. 공식 기록은 이메일, 빠른 질의응답은 메신저, 진척 추적은 업무 관리 도구. 중요한 피드백은 공개 메시지가 아니라 1:1로, 팀 구조 변경 같은 민감한 소식은 상세 이메일 전에 짧은 회의로 먼저 알린다.
인력 관리도 빼놓을 수 없다. 채용에서 책이 던지는 조언은 단순하다. 급히 공석을 채울 때는 능력보다 태도다. 좋은 팀 플레이어가 못 되는 사람은 결국 걸림돌이 된다. 성과 평가에서는 지표 너머의 경력 목표와 포부를 꼭 논의한다. 그리고 사람을 붙잡는 데서 책은 두 가지 면담을 구분한다. 떠난 사람에게서 개선점을 듣는 퇴사 면담, 그리고 아직 있는 사람에게 미리 우려를 묻는 재직 면담이다. 이직을 줄이는 건 후자다. 사람을 키우는 건 멘토링과 코칭인데, 외부 채용보다 내부 육성이 문화 적합성도 좋고 생산성에 닿는 시간도 짧다.
불확실성 속에서 팀을 끌고 가기
잘 뽑은 팀이라도 매 순간의 상호작용은 예측 불가다. 까다로운 프로젝트와 사람 사이의 갈등이 늘 따라온다.
도전적 프로젝트에 대해 책은 에밀리의 사례를 든다. 그는 요구사항이 수시로 바뀌고 과거의 기술 난관으로 팀이 지친, 악명 높은 복잡 프로젝트를 맡았다. 그가 한 건 화려한 기술이 아니라 투명한 소통과 결단이었다. 다사다난한 과거에 주눅 들지 않는 자신감을 팀에 심고, 끝까지 함께 헤쳐 나갔다. 실무적으로는 애자일로 유연성을 확보하고, 범위를 정기적으로 검토하고, 처음 쓰는 기술은 프로토타입으로 위험을 먼저 줄인다. 여기서 한 문장이 핵심이다. 모든 문제가 중요한 건 아니다. 심각성과 악영향 가능성으로 우선순위를 매겨 진짜 중요한 것부터 처리해야 한다.
갈등은 대개 성격이나 업무 방식, 목적 해석의 차이에서 온다. 책의 예가 인상적이다. 매우 체계적인 사람과 유연하고 창의적인 사람이 부딪힐 때, 방치하면 갈등이지만 열린 자리에서 풀면 상호 보완이 된다. 창의적인 사람은 혁신적 해결책을 내고, 체계적인 사람은 그 해결책이 모든 요구사항을 충족하도록 챙긴다. 차이를 없애는 게 아니라 차이를 맞물리게 하는 것이다.
멈추지 않는 성장
마지막으로 성장이다. 성장 촉진은 역설적으로 어렵다. 바쁠 땐 시간이 없고, 한가할 땐 무엇이 가치 있을지 모른다. 그래서 책은 양쪽 다 대비하라고 한다. 한가한 시간엔 지난 개발 주기에서 발견한 문제를 푸는 미니 프로젝트를, 바쁜 시기엔 하루 10~15분이라도 자기 개발 시간을 제도화하는 것이다. 매니저 자신의 성장에는 네트워킹이 있다. 필요할 때만 연락하는 게 아니라 분기에 한 번은 행사에, 매월 한 번은 커피나 온라인 미팅으로 관계를 이어가라는 것. 네트워킹은 전화번호부가 아니라 팀 성과를 높이는 의미 있는 관계에 가깝다.
저자가 장을 닫으며 남기는 말이 이 장 전체를 요약한다. 매니저의 성공은 개인의 탁월함이 아니라, 뛰어난 집단을 지휘하고 고무하는 능력에 달려 있다.
7장. 효과적인 리더로 나아가기
리더십과 관리는 다르다, 그러나 둘 다 필요하다 (존 코터)
[리더] 변화와 움직임 → 방향 설정 · 사람 결집 · 동기 부여
├─► 하나의 조직 성공
[매니저] 질서와 일관성 → 계획 예산 · 조직 인력 · 통제 문제
───────────────────────────────────────────────────────
두 갈래가 맞물릴 때 비로소 하나의 성공이 된다 (최고의 매니저는 둘을 통합한다)
Plain Text
복사
리더십은 관리가 아니다
매니저까지 왔으면 마지막 질문이 남는다. 좋은 매니저면 충분한가. 7장의 답은 '리더십은 관리와 다르다'이다. 리더십과 관리 연구의 대가 존 코터의 구분을 빌리면, 리더십은 변화와 움직임을 만들고 관리는 질서와 일관성을 만든다. 둘은 배타적이지 않다. 오히려 최고의 매니저는 둘을 통합한다. 리더가 비전으로 방향을 설정하고 사람을 결집하고 영감을 준다면, 매니저는 계획과 예산을 짜고 조직을 정렬하고 문제를 통제한다. 한쪽만으로는 부족하다.
세 갈래의 리더십 역할
경력이 쌓이면 보통 기술 트랙과 관리 트랙 사이에서 길이 갈린다. 책은 세 역할을 구분한다. 테크 리드는 기술 설계와 방향을 책임지는 실무 리더이고, 엔지니어링 매니저는 인력 관리와 프로젝트 성공을 책임지며, 테크 리드 매니저(TLM)는 둘을 겸한다. 큰 조직에서는 이 역할들이 나뉘고, 작은 팀에서는 한 사람이 다 짊어진다. TLM의 직속 부하 수가 더 적은 것도 그래서다. 둘 다 잘하려면 어느 쪽도 소홀히 할 수 없으니까.
엔지니어링 매니저의 역할을 두고 책은 조엘 스폴스키의 표현을 인용한다. 매니저의 최우선 과제는 '추상화된 개발 계층'을 만드는 것. 개발자가 방화벽 해제나 리포지토리 접근 같은 인프라 잡무에 직접 노출돼 있다면 그 추상화는 실패한 것이다. 잡무를 가려 개발자가 코드에 집중하게 해주는 것, 그게 매니저의 일이다.
리더를 만드는 자질
리더십은 직함에서 나오지 않는다. 책은 자질을 두 층으로 나눈다. 먼저 핵심 특성 셋. 기술 전문성, 변화에 적응하는 기민함, 그리고 의사소통이다. 셋 중에서도 의사소통이 가장 필수적인데, 책은 7C라는 체크리스트를 권한다. 명확성, 간결성, 구체성, 정확성, 일관성, 완전성, 정중함. 저자 자신도 큰 출시를 준비하며 제품과 마케팅과 홍보를 다 챙겨놓고 정작 데브렐 팀에 알리는 걸 빠뜨린 실수를 고백한다. 소통의 구멍은 누구에게나 난다.
그 위에 바람직한 특성 열 가지가 얹힌다. 자발적 동기부여, 추진력, 성실성, 공정성, 겸손, 용기, 책임감, 영향력, 타인에 대한 배려, 자기 인식. 책은 각 특성마다 자가 진단 질문을 붙이는데, 마지막 자기 인식만은 결이 다르다. 스스로에게 '나는 자기 인식이 높은가'를 묻는 건 무의미하기 때문이다. 유일하게 의미 있는 질문은 이것이다. 내가 매긴 내 강점과 약점이, 남들이 보는 나와 일치하는가. 일치하면 높은 것이고, 어긋나면 갈 길이 멀다. 자기 인식은 거울이 아니라 남의 눈으로만 잴 수 있다.
리더십을 발휘하는 법
마지막은 실천이다. 책은 네 축으로 정리하는데, 핵심만 추리면 이렇다.
리더십 방식에는 정답이 없다. 비전으로 변화를 이끄는 변혁적, 팀을 의사결정에 참여시키는 민주적, 팀의 요구를 앞세우는 서번트 리더십이 있고(저자는 자신을 서번트에 가깝다고 밝힌다), 진짜 기술은 이것들을 상황에 맞게 갈아 쓰는 상황적 리더십이다. 복잡한 신기능 초기엔 변혁적으로 비전을 점화하고, 문제에 부딪히면 서번트로 전환해 장애물을 치우는 식이다.
전략 수립에서 책이 거듭 강조하는 건 무자비한 우선순위 매기기다. '원하는 성과에 가장 중요한 업무는 무엇인가'가 우선순위를 정하기 전 가장 중요한 질문이고, 효과적 리더는 비전에 맞는 전략 서너 개만 골라 거기 집중한다. 핵심은 '아니오'라고 말하는 용기다. 단순한 거부가 아니라 전략적으로 필요한 거절.
역할 수행과 자세는 앞 장들의 개념이 다시 모이는 자리다. 심리적 안전감(4장)을 리더가 앞장서 만들고, 다양성(1장)을 혁신의 필수 요소로 이끌고, 직관 대신 데이터로 결정하고, 신뢰와 자율성(1장)을 주되 '가드레일'이라는 경계선을 함께 둔다. 그리고 무엇보다 행동 모델링, 팀에게 보고 싶은 가치를 리더가 몸소 보여주는 것이다. 변화에 대응하는 틀로는 4A를 제시한다.
적응형 리더십의 4A (서로 맞물려 순환한다)
예측(Anticipation) 변화를 미리 내다본다
설명(Articulation) 비전과 방향을 설득력 있게 전한다
적응(Adaptation) 전략을 상황에 맞게 바꾼다 (4A의 핵심)
책임(Accountability) 행동과 결정과 성과를 책임진다
Plain Text
복사
이 모든 걸 관통하는 한 장면이 마크의 이야기다. 코딩과 문제 해결의 스타였던 마크는 매니저가 되고도 코딩, 관리, 검토, 기획까지 전부 직접 하려다 명백히 무리했고, 그 여파가 팀 사기로 나타났다. 저자가 개입해 가르친 건 위임과 무자비한 우선순위, 그리고 직접 코딩 대신 팀원을 멘토링해 풀게 하는 멘토의 사고방식이었다. 마크가 배운 교훈이 7장 전체의 핵심이다. 모든 일을 스스로 처리해야 한다는 관념을 버려야 한다. 진짜 중요한 기술은 타인의 탁월함을 이끌어내는 것이다. 이게 '리더로서 자신을 확장한다'는 말의 본뜻이다.
책을 닫으며: 효과성은 사고방식이다
7장 마지막에서 책은 한 문장으로 모든 걸 모은다. 효과성은 사고방식이자 마음가짐이다. 팀의 효과성을 키우는 유일한 방법은 전략과 행동과 태도로 그것을 직접 실천하고 보여주는 것이다.
1장부터 7장까지를 되짚으면 길은 하나로 이어진다. 적합한 인재를 모으고, 효율과 효과와 생산성을 구분해 측정하고, 피해야 할 안티패턴을 알아채고, 매니저로 전환하고, 마침내 리더로 자신을 확장하는 여정. 효과성은 기법의 합이 아니라 사고방식이고, 리더가 그걸 몸소 살아낼 때 비로소 팀 전체로 번진다. 그게 '무엇이 1등 팀을 만드는가'에 대한 이 책의 최종 답이다.