[구글엔지니어] Ch05 요약 및 토론

Ch 05. 팀 이끌기

구글은 리더 역할을 두 가지로 구분

• 관리자(manager) : 사람을 이끔
• 테크 리드(tech lead) : 기술 관련 책임을 짊

5.1 관리자와 테크 리드

5.1.1 엔지니어링 관리자

구글은 엔지니어링을 아는 사람만이 소프트웨어 관리자가 될 수 있도록 한다.

→ 소프트웨어 경험이 있는 관리자를 고용하거나, 기존 소프트웨어 엔지니어를 관리자로 훈련시킨다.

거시적인 측면에서 엔지니어링 관리자는 자신이 관리하는 팀의 구성원 모두(테크 리드도 포함) 성과(performance), 생산성(productivity), 행복(happiness)을 책임져야 한다. 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 한다.

5.1.2 테크 리드

테크 리드는 제품의 기술적인 면, 즉 기술과 관련된 결정과 선택, 아키텍처, 우선순위, 성능과 일반적인 프로젝트 관리를 책임진다. 테크 리드는 엔지니어링 관리자와 긴밀히 협조하여 맡겨진 제품을 개발하는 데 필요한 팀원을 확보하고 엔지니어들의 기술 스펙트럼과 기술 수준을 최대한 활용해 목표를 완수하게끔 이끌어야 한다.

대부분의 테크 리드는 개인 기여자이기도 해서 때로는 직접 나서서 빠르게 일을 처리할지, 아니면 속도는 더디더라도 다른 팀원에게 위임할지를 판단해야 한다. 팀의 규모와 역량이 커질 수록 위임하는 편이 나을 때가 많다.

5.1.3 테크 리드 매니저

엔지니어링 관리자가 기술적인 지식도 다양하게 알고 있어야 하는 소규모의 초기 팀에서는 기본적으로 테크 리드 매니저를 두는 경우가 많다. 경력이 오래된, 특히 최근까지 개인 기여자였던 사람에게 맡긴다.

완전히 번아웃되지 않고서 두 역할(엔지니어링 매니저, 테크 리드)을 동시에 수행하기란 너무 어렵다. TLM 역할은 만만치 않아서 자신의 일, 위임, 사람 관리 사이에서 균형을 잡는 요령을 배워야 한다. 그래서 백전노장 TLM으로부터 고차원적인 멘토링과 지원을 받아야 하는 것이 보통이다.

5.2 개인 기여자에서 리더로

주어진 역할을 성공적으로 완수한 사람일수록 본인이 리더가 되려 하지 않더라도 리더의 자리에 가는 경우가 많다.

5.2.1 두려워해야 할 건 오직… 전부다

많은 사람들이 ‘관리자’를 싫어하는 이유

• 개인 기여자 → 하루의 끝, 내가 작성한 코드나 문서 보면서 ‘내가 한 일이야’ 라는 생각
• 관리자 → 하루의 끝, ‘오늘 내가 한 일이 하나도 없군’이라고 생각하기 쉬움

관리 업무를 수량화하기는 위젯 제작보다 까다롭다. 하지만 관리를 통해 팀에 활기를 불어넣고 생산성을 높일 수 있다.

피터의 법칙 : 위계 조직에서 직원들은 ‘자신의 무능력이 드러나는 직급’까지 승진하는 경향

→ 구글은 이 법칙을 피하기 위해 다음 직급으로 승진시키기 전에 현 수준 이상의 일을 일정 기간 맡겨본다.

5.2.2 섬기는 리더십

‘관리’ 병을 치료하려면 섬기는 리더십(Servant Leadership)을 자유롭게 응용할 수 있어야 한다. 리더로서 해야 할 가장 중요한 일은 팀을 떠받드는 것이다.

섬기는 리더로서 여러분은 겸손, 존중, 신뢰의 분위기를 조성하려 힘써야 한다. 예컨대 팀원이 혼자서는 제거할 수 없는 관료적 장애물을 치워주고, 팀이 합의에 이르도록 도와주고, 누군가 늦게까지 야근할 때는 저녁을 사주는 일이 될 수도 있다.

5.3 엔지니어링 관리자

5.3.1 관리자는 밥맛이야

과거, 당근과 채찍 방식의 관리자가 인정받던 시절 있었다.

현재, 대규모 코드베이스를 다루는 소프트웨어 엔지니어는 새 인력이 원래 팀원만큼 속도를 내는데 몇 달도 부족할 수 있다.

대체하기 쉬운 조립라인 근로자와 달리 소프트웨어 엔지니어에게는 생각하고 창조할 자양분과 시간과 공간이 필요

5.3.2 오늘날의 엔지니어링 관리자

관리자와 직원이 부모 - 아이 관계처럼 되기가 쉽다.

겸손, 존중, 신뢰의 틀에서 생각 → 관리자가 직원을 신뢰한다는 분명한 신호를 주면 직원은 신뢰에 부흥해야 한다는 긍정적인 압박을 느낀다.

전통적인 관리자는 일을 어떻게(how) 처리할지를 고민하는 반면, 훌륭한 관리자는 무슨(what)일을 처리할지를 고민한다. 그리고 어떻게는 팀을 믿고 맡긴다.

5.4 안티패턴

5.4.1 안티패턴: 만만한 사람 고용하기

당신이 좌지우지할 수 있는 사람을 고용해서 누구도 당신의 권위와 위치를 위협하지 못하게 한다면, 직접 처리해야 할 일이 그만큼 늘어날 것

→ 당신보다 똑똑하고 당신을 대체할 역량을 갖춘 사람을 적극적으로 뽑아야 한다. 당신의 권위에 도전한다고 받아들일 것이 아닌, 반대로 팀을 하나 더 꾸릴 기회라고 생각하자.

5.4.2 안티패턴: 저성과자 방치하기

한 두 명의 저성과자 때문에, 팀은 실패하고 결국 해체된다. 기대를 충족해주지 못하는 사람을 다루는 것이 가장 고난이도 과제이다. 적응할 시간이 부족했어서 혹은 충분히 열심히 하지 않아서 기대에 못 미친 사람도 있을 것이다. 하지만 들인 시간과 노력에 상관없이 어떠한 수를 써도 맡겨진 임무를 완수하지 못하는 사람도 있다.

‘희망은 전략이 아니다.’ 구글의 SRE 팀의 좌우명

저성과자의 역량이 높아지기를 혹은 어디론가 떠나기를 희망하는 사이, 팀의 다른 고성과자들은 저성과자들을 밀고 당겨주느라 귀중한 에너지를 낭비하고 팀의 사기는 서서히 떨어져간다. 우리가 못 본 척 하더라도, 저성과자의 존재는 팀원 모두가 알고 있다.

저성과자를 방치하는 일은 새로운 고성과자가 팀에 합류하는 것을 막기도 하며, 그나마 있던 팀내 고성과자를 떠나게도 한다. 그러다 보면 결국 스스로의 힘으로는 떠날 수 없는 저성과자로만 구성된 팀이 남게 된다.

저성과자를 지도하는 효과적인 방법

• 겸손, 존중, 신뢰가 바탕이 되어야 한다.
• 기간을 정하고 (두 달 정도) 아주 구체적인 목표를 제시한다.
  • 작고 점진적이고 측정할 수 있는 목표
• 그 팀원과 매주 만나서 진척상황을 확인하고 다음 마일스톤에서 기대하는 바를 명확히 정의했는지, 성공과 실패를 바로 구분할 수 있는지 확인한다.
  • 잘 따라오지 못한다면 결단을 해야 한다.
  • 이 시기에 저성과자 팀원은 미래가 보이지 않음을 인정하고 스스로 그만두거나, 독하게 마음을 다지고 기대에 부흥하기 위해서 노력한다.

5.4.3 안티패턴: 사람 문제 무시하기

대부분의 관리자가 기술 업무를 수행하다가 승진하였기 때문에 사람의 문제는 소홀히 하는 경향이 있다.

5.4.4 안티패턴: 만인의 친구되기

부드럽게 끌어주는 리딩과 우정을 혼동하지 말 것

팀과의 친밀한 우정 없이도 혹은 완고한 독불장군이 되지 않고서도 팀을 이끌고 합의를 끌어낼 수 있음을 기억하라.

5.4.5 안티패턴: 채용 기준 타협하기

A급 인재는 A급 인재를 뽑고, B급 인재는 C급 인재를 뽑는다. - 스티브 잡스

적합한 사람을 찾는 데 드는 비용(리크루터 수당, 채용 광고 비용, 신중을 기하기 위한 레퍼런스 확인 등)은 애초에 뽑지 말았어야 할 직원을 관리하는 비용에 비하면 아무것도 아니다. 적합하지 못한 사람을 채용하면 팀 생산성 손실, 팀 스트레스, 직원 관리에 허비되는 시간, 마지막으로 해고 서류 작업과 스트레스 등의 비용을 치뤄야 한다.

5.4.6 안티패턴: 팀을 어린이처럼 대하기

사람들은 자신을 대하는 방식대로 행동하는 경향이 있다.

마이크로매니징을 하거나, 단순히 팀원들의 능력을 존중하지 않고 자신의 일에 책임질 기회를 주지 않으면 → 팀원들은 어린이나 죄수처럼 행동할 수도 있다.

5.5 올바른 패턴

5.5.1 자존심 버리기

어떤 팀이든 자존심이 너무 강한 사람은 다루기 어렵다. 그 사람이 하필 리더이면 더 골치 아프다.

신뢰는 ‘자존심 버리기’의 한 축이다. 팀을 믿어라. 팀원들의 능력과 기존에 이룬 성과들을 존중하라.

리더 역할이 처음인 사람은 대부분 모든 시안을 올바르게 결정하고, 모든 것을 알고, 모든 질문에 답해야 한다는 강박으로 스스로를 옭아맨다. 장담컨데, 여러분은 때론 잘못된 결정을 내릴 것이며 모든 문제의 답을 알고 있지도 못한다. 그럼에도 스스로가 완벽한 듯 행동한다면 팀원들의 존경을 빠르게 잃어갈 것이다.

5.5.2 마음 다스리기

업무와 관련된 복잡한 세부 내용과 장애물들을 여러분이 인지하고 있음을 팀도 알게 하되 덜 회의적인 태도를 취하는 게 좋다.

리더는 항상 무대 위에 있다. 공식적인 리더의 위치에 있다면 주변 사람들이 여러분의 일거수일투족을 항시 두 눈 똑바로 뜨고 쳐다보고 있다는 뜻이다.

팀원이 여러분에게 조언을 구한다는 것은 마침내 무언가를 해결해 줄 기회가 찾아온 것이다. 하지만 ‘직접 해결하기’는 가장 마지막에 택해야 하는 전략이다. 조언을 구하는 사람은 보통 ‘여러분이 나서서’ 해결 해주길 원하는 것이 아니다. 스스로 문제를 해결하는 걸 도와주길 바란다.

5.5.3 촉매자 되기

팀 리더가 하는 가장 일반적인 일은 합의를 이끌어 내는 것이다. 시작부터 끝까지 과정을 주도할 수도 있고 올바른 방향으로 가속이 붙도록 톡 밀어만 줄 수도 있다.

5.5.4 장애물 치우기

어떤 경우든 팀이 다시 움직일 수 있도록 도와주는 것이 일반적인 리더십 기술이다. 때로는 팀원 차원에서 극복하기 불가능한 장애물도 리더라면 손쉽게 걷어낼 수 있다. 그래서 여러분이 그런 장애물들을 치워줄 수 있고 또 기꺼이 그러길 원한다는 사실을 팀원 모두가 인지하도록 만들어야 한다.

5.5.5 선생이자 멘토 되기

멘토에게 요구되는 세가지

1. 팀의 프로세스와 체계에 대한 경험
2. 다른 이에게 무언가를 설명해주는 능력
3. 멘티에게 도움이 얼마나 필요한지를 측정하는 능력

멘티에게 최대한 정보를 제공하는게 좋은가? 설명이 과하거나 이야기를 끝도 없이 쏟아내면 듣는 척만 할 것.

5.5.6 명확한 목표 세우기

목표를 명확히 세우고 팀이 제품을 한 방향으로 끌게 하는 가장 쉬운 방법은 팀이 이루어야 할 임무를 구체적인 문장으로 적어놓는 것이다. 팀이 방향과 목표를 정하도록 도왔다면 한 걸음 물러서서 더 많은 자율권을 준 뒤 모두가 올바르게 가고 있는지 주기적으로 확인한다.

5.5.7 정직하기

여러분은 종종 팀에 말 못 할 정보가 흘러들어오는 위치에 있기 때문에, 혹은 팀이 듣고 싶어 하지 않는 걸 말해야만 하는 위치에 있기 때문에 ‘정직하라’라고 언급해 둘 필요가 있다.

칭찬 샌드위치 : 당신은 팀의 탄탄한 구성원이자 가장 영리한 엔지니어 중 하나에요. 그래서인지 당신의 코드는 복잡하고 다른 팀원 누구도 이해하기가 거의 불가능하군요. 하지만 잠재력이 크니 여기 쩌는 티셔츠를 하나 드리겠습니다.

→ 우리는 칭찬 샌드위치를 사용하지 말 것을 강하게 권한다. 겉에 둘러진 칭찬 때문에 핵심 메시지, 즉 실제로는 고쳐져야 할 점을 지적한 것임을 제대로 인지하지 못하는 사람이 대부분이기 때문이다.

5.5.8 행복한지 확인하기

훌륭한 리더 → 수시로 팀원들의 복지를 챙기고, 그들이 하는 일을 인정해주고, 일에 만족하는지 확인

---

Discussion

H. 테크 리드가 리더 역할을 하면서, 피쳐 개발도 해야 되는 것으로 보이는데, 매니징을 하면서 피쳐 개발을 동시에 가져가는 것이 리소스 배분이 어떻게 가능한지??

G. 개인 의견. 워킹 타임의 5할 이상은 매니징에 써야 한다. 각 테크 리드가 피쳐 개발을 많이 맡는 것은 옳지 않다.

S. 팀의 성과가 가장 많이 나는 방향으로 의사 결정. 팀이 작을 수록 본인이 직접 하는 것이 더 나은 방향인 경우가 많다. 그 사람만 할 수 있는 일을 해야 함. 우선순위는 매니징이 피쳐 개발보다 높다.

• e.g V4 마이그레이션이 코앞인데, 매니징만 하는 것이 옳은가? → 이 일이 어떻게든 잘 되게 하는 것이 중요.

Judy. 스쿼드는 목적조직 → 엔지니어링 매니저 역할이 크다. 테크 리드는 기술적인 부분에 대한 고민을 해야 한다?

H. 구성원들의 행복 관리가 기술적인 내용 다루는 것보다 더 어려운 것 같다. 기술적인 만족? 채워질 부분들을 누구한테 이야기를 해야 할지 모호하다.

S. 누구에게든지 이야기를 하면 도움을 받을 수 있을 것.

S. 70%만 해라. 리더를 잘 하는 사람은 드물다.

G. 피터의 법칙 → 일을 맡겼을 때 만약 잘 못하면 회사는 그 리더를 어떻게 대해야 할까?

S. 포지션을 승진해서 얻는 value는 생각보다 크지는 않다(?) 금전적인 보상이 적은 경우도 많다.

J. 개발과 매니징은 스탯이 다르다. 한국에서는 개발을 잘하면 관리자를 시킨다(?)

S. 개발 잘 하는데 매니징에 소질이 없고, 관심이 없으면 → 리드 아키텍트로 임명

S. 굉장히 신중하게 리더십을 임명한다.

J. 마음써서 해 주는 관리 → 이런 건 평가에서 증명할 수가 없다. 리더의 passive로 여겨지기 쉽다.

S. 밥 사주라는게 진짜 밥을 사준다는 의미도 있지만, 그걸 인정해주고 알아주라는 뜻.

A. IC → Leader : 나보다 잘 하는 사람이면 존중하기도 쉽고, 따라가기도 쉽다. 좋은 리더랑, 개발자는 다르다. 좋은 축구 선수가 항상 좋은 감독이 되는 것은 아니다. 회사 차원에서 리더로 데려가고 싶은 사람은 교육이 이루어져야 하지 않을까?

S. 권한과 책임이 많은 사람 → 첫 번째 기준이 의사결정능력.

A. 클루지

• blink : 순간적으로 빨리 무슨 상황인지 판단해서 결정. 빠른 시간에 좋은 결정을 내리는 것은 어렵다.
• 심사숙고하고 고려. 시간과 에너지 많이 든다.

S. 시간이 길어져야 의사결정을 잘한다 X

S. 의사결정에 필요한 정보의 수준 파악. 있으면 결정, 없으면 빠르게 수집

• 판단할 수 있으면 바로 판단
• 판단할 수 없으면 정보를 수집
• 정보가 있는데 시간을 끄는 건 좋지 않다.

H. 빠르게 결정을 내려 주었더니, 부정적인 피드백을 받은 경험도 있다.

A. 빠른 대답이 나쁜 이유 중 하나.

• 그 자리에서 안 된다 vs 3~5 시간 후 안된다.
• 거절의 몰입도가 다르다.

S. 라포의 깊이에 따라서 라포가 깊으면 빨리빨리 이야기를 하고, 아니면 라포 형성에 더 집중.

S. 어려운 이야기를 어느정도까지 할 수 있는지를 바탕으로, 라포가 얼마나 형성되었는지를 확인.

G. 개발자들이 Show And Tell, BBS 같은 곳에서 본인이 아는 걸 다 쏟아내려고 함. 20%만 이해한다면, 20%를 잘 이해하게 설명해야 하는데 많은 개발자들은 이걸 잘 못한다.

H. 독자가 얻고 싶은 것이 뭘까? 하고 싶은 이야기는 많았지만 다 걷어내고, 핵심에만 집중하였다.

A. 잘 설명해 주는게 더 도움이 될 때가 있다. 초등학생, 중학생이 이해할 수 있게 하는 게 메타인지가 높다고 생각.

S. 처음에 로드맵을 정할 때는 일부러 길게 한다. 정보 레벨이 서로 동일한 수준에서 이야기 하는 걸 좋아한다.

G. 눈높이에 맞춰서 이야기 하는 것도 교육으로 가능하다. 그 전까지는 하드 스킬만 팠다면, 같이 일하기 힘들다는 피드백을 들은 이후로는 소프트 스킬에 대한 공부를 많이 하려고 노력한다.

J. 정보를 전달할 때 이 사람의 지식양이 얼마인지 모르니까, 쉬운 부분부터 설명하다가 무시한다는 듯한 피드백을 들은 적이 있다.

S. 주변의 평가에 신경을 쓰지 않는 사람들이 커리어가 빨리 크더라. 평가가 아닌 성과에 집중.

G. OKR은 평가를 위한 제도가 아니다. 개인의 성장을 측정하기 위한 도구였는데 한국에 와서 변질된 부분이 없지 않아 있어.

S. 구성원들중에 누가 코드 잘 짜는지, 누가 CS 지식 높은지 서로 다 알고 있다. 단지 말을 안 하는 것일 뿐.

G. 평가를 한 일이 끝날 때 마다 그 때 그 때 가진다. 1년을 평가 주기로 가져가는 것은 너무 길다.

J. 틈틈이 이 사람이 잘 했던 것들을 다 기억을 한다. 단점은 잘 기억이 나지만, 장점은 기억이 잘 나지 않기 때문이다.

S. 주로 이야기 나오는 것 : 내가 1년동안 한 것으로 평가를 받아야지?

• 내가 내년에 어떻게 할거야 에 대한 근거를 올 해 만드는 것
• 경영자는 미래에 대한 기대가 크다.