<div id="readability-page-1" class="page"><p><cite>Berno</cite>
                  <span> 2022. 6. 5. 15:37</span>
                </p><div>
                                <blockquote data-ke-style="style3">
  내 첫 회사를 퇴사한 지금 팀장의 입장과 팀원의 입장에서 이 글을 읽으며 많은 생각이 들었다. 
</blockquote>
<h3 data-ke-size="size23"><p>0. 들어가며</p></h3>
<p data-ke-size="size16">이번 장은 궁극적으로 ‘책임지는 사람’의 시선으로 이야기를 진행한다.</p>
<h3 data-ke-size="size23"><br>1. 리더와 매니저</h3>
<div data-ke-size="size16"><p>구글은 리더 역할을 두 가지로 구분해 생각한다. 관리자(manager)는 사람을 이끌고 테크 리드(tech lead)는 기술과 관련된 책임을 진다. </p></div>
<h3 data-ke-size="size23">2. 우리에게 선장이란</h3>
<p data-ke-size="size16">선원이 아무리 많다 한들 선장이 없는 배는 그저 길을 잃은 조각배에 지나지 않다. 소프트웨어에서도 선장이 없다면 엔지니어들은 값진 시간을 허비한다.</p>
<h3 data-ke-size="size23"><br>3. 관리자와 테크 리드(혹은 둘 다)</h3>
<p data-ke-size="size16">모든 팀에서는 리더가 있지만 리더를 모셔오는 방법이 다를 수 있다. 팀에서 경험이 많은 팀원을 리더로 하거나 외부에서 리더를 모셔오기도 한다. 신생 팀의 경우 관리자와 테크 리드 역할을 한 사람이 맡게 되는데 이를 테크 리드 매니저(tech lead manager)라 한다. 엔지니어링 관리자에 대해 말해보자.<br>많은 회사에서 소프트웨어 엔지니어링에 거의 무지하더라도 훈련된 인사 관리자에게 팀의 운영을 맡긴다. 하지만 구글은 엔지니어링을 아는 사람만이 소프트웨어 엔지니어링 관리자가 될 수 있다. 관리자는 자신이 관리하는 팀의 구성원 모두(테크 리드도 포함)의 성과(performance), 생산성(productivity), 행복(happiness)을 책임져야 한다. 그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 한다. 하지만 사업적 요구와 개별 팀원의 요구가 항상 일치하는 것은 아니어서 관리자는 이따금 난처한 상황에 놓이게 된다. 테크 리드에 대해 말해보자.<br>테크 리드는 제품의 기술적인 면, 관련한 결정과 선택, 아키텍처, 우선순위, 성능과 일반적인 프로젝트 관리를 책임진다. 테크 리드는 관리자와 긴밀히 협조하며 맡겨진 제품을 개발하는 데 필요한 팀원을 확보하고 엔지니어들의 기술 스펙트럼과 기술 수준을 최대한 활용해 목표를 완수하게끔 이끌어야 한다. 테크 리드는 본인 스스로가 작업을 하는 경우가 있고 일을 위임하는 경우가 있는데 사이즈가 큰 경우 다른 팀원에게 위임하는 편이 나을 때가 많다. 테크 리드 매니저에 대해 말해보자.<br>완전히 번아웃되지 않고서 두 역할을 동시에 수행하기는 너무도 어렵다. 그래서 각각에 집중하는 전문가를 독립적으로 두는 편이 좋다.<br>테크 리드 매니저의 역할은 두 역할을 동시에 수행하기에 상당히 힘들다. 자신의 일, 위임, 사람 관리 사이에서 균형을 잡는 요령을 배워야 한다.</p>
<h3 data-ke-size="size23"><br>4. 팀원에서 리더로</h3>
<div data-ke-size="size16"><p>누군가는 선장을 해야 하고 어느 방향으로 가야 할지 정해야 한다. 개발 업계에서 어쩌다 보니 리더가 되어 있는 상황은 아주 흔하다. 문제는 리더가 되기 기피하는 가장 큰 이유는 소프트웨어 개발 분야에서는 코딩할 시간이 크게 줄어든다는 점이다. 물론 누군가는 해야 할 일이고 관리자 업무를 했다는 것이 일을 안 했다는 것은 아니다. 간혹 관리직에 있으며 코드 한 줄 만들지 못한 하루를 보낸 사람은 일을 하나도 하지 않았다고 스스로 자책을 하는 경우가 있지만 이건 정말 큰 착각이다.</p><p>관리자들에게는 특히 일종의 질병이 있는 것처럼 보인다. 선임 관리자가 자신에게 했던 끔찍한 일들을 새까맣게 잊고 자신도 어느덧 똑같은 식으로 사람들을 ‘관리’하게 되는 병이다.<br>이 ‘관리’병을 치료하려면 섬기는 리더십(Servant Leadership)을 자유롭게 응용할 수 있어야 한다. 리더로서 우리는 겸손, 존중, 신뢰의 분위기를 조성하려 힘써야 하고 그 결과로 팀의 기술적 건강뿐 아니라 사회적 건강도 챙겨야 한다.</p></div>
<h3 data-ke-size="size23">5. 엔지니어링 관리자</h3>
<p data-ke-size="size16">이 문장을 기억하자.</p>
<blockquote data-ke-style="style1">
  전통적인 관리자는 일을 어떻게 처리할지를 고민하는 반면 훌륭한 관리자는 무슨 일을 처리할지 고민하고 어떻게는 팀을 믿고 맡긴다. 
</blockquote>
<p>성공적인 테크 리드와 엔지니어링 관리자로 만들어주는 패턴 중 안티 패턴을 살펴보자. </p>
<h3 data-ke-size="size23">5-1. 만만한 사람을 고용하기</h3>
<p data-ke-size="size16">만만하다는 것은 실력도 고만고만하다는 것이고 비약적으로 나보다 무능력하다는 의미일 수 있다. 우리는 더 나은 팀을 만들기 위해 우리를 대체할 수 있는 역량을 가진 사람을 적극적으로 뽑아야 한다.</p>
<h3 data-ke-size="size23"><br>5-2. 저성과자 방치하기</h3>
<p data-ke-size="size16">저성과자를 방치하는 일은 새로운 고성과자가 팀에 합류하는 것을 막기도 하며 그나마 있던 팀 내 고성과자를 떠나게도 한다. 그러다 보면 결국 스스로의 힘으로 떠날 수 없는 저성과자로만 구성된 팀이 남게 된다.</p>
<h3 data-ke-size="size23"><br>5-3. 사람 문제 무시하기</h3>
<div data-ke-size="size16"><p>관리자는 사회적 문제와 기술적 문제 이 두 가지에 신경을 써야 한다. 구글의 관리자들은 일반적으로 기술 측면에 강점을 가지고 있다. 그리고 대부분의 관리자가 기술 업무를 수행하다 승진하였기 때문에 사람의 문제는 소홀히 하는 경향이 있다.</p></div>
<h3 data-ke-size="size23">5-4. 만인의 친구 되기</h3>
<p data-ke-size="size16">처음 리더가 되는 경험은 대부분 자신이 속한 팀의 관리자나 테크 리드로 승진하며 시작된다. 부드럽게 끌어주는 리딩과 우정을 혼동하면 안 된다. 우리에게는 팀원들의 경력을 좌지우지할 힘이 있기 때문에 인위적이고 낯선 여러분의 행동에서 팀원들은 오히려 압박을 느낄 수 있다.</p>
<h3 data-ke-size="size23"><br>5-5. 채용 기준 타협하기</h3>
<p data-ke-size="size16">스티브 잡스가 한 말 중 이런 말이 있다.</p>
<blockquote data-ke-style="style1">
  A급 인재는 A급 인재를 뽑고, B급 인재는 C급 인재를 뽑는다.
 <br> 
</blockquote>
<h3 data-ke-size="size23">5-6. 팀을 어린이처럼 대하기</h3>
<div data-ke-size="size16"><p>우리가 팀을 신뢰하지 못함을 보여주는 가장 대표적인 예가 팀원들을 어린이처럼 대하는 것이다. 사람들은 자신을 대하는 방식대로 행동하는 경향이 있다고 한다. 어린이나 죄수처럼 대하면 그들이 어린이나 죄수처럼 행동한다고 한다. 마이크로 매니징을 하거나 단순히 팀원들의 능력을 존중하지 않고 자신의 일에 책임질 기회를 주지 않으면 우리는 팀원을 어린이처럼 대하는 것과 다를 바 없다. 실제로 특정 팀원을 믿지 못해서 마이크로 매니징 할 수밖에 없는 상황이 고착화된다면 우리가 채용을 잘못한 것이다.</p><p>위에서 안티 패턴들을 알아봤으니 이제 올바른 패턴도 알아보도록 하자.</p></div>
<h3 data-ke-size="size23">5-7. 자존심 버리기</h3>
<div data-ke-size="size16"><p>2장에서 겸손, 존중, 신뢰를 처음 이야기하였는데 팀 리더에게 특히 중요한 덕목이다. 신뢰는 ‘자존심 버리기’의 한 축이다. 팀을 믿어라. 팀원들의 능력과 기준에 이룬 성과들을 존중해야 한다는 뜻이다. 새로 합류한 팀원이라도 마찬가지다. 장담하건대 우리는 때론 잘못된 결정을 내릴 것이며 모든 문제의 답을 알고 있지도 못한다. 그럼에도 스스로가 완벽한 듯 행동한다면 팀원들의 존경을 빠르게 잃어갈 것이다. 자존심 버리기의 가장 중요한 부분은 ‘실수했다면 사과하기’이다. 말로만 하는 것이 아닌 진심을 담아야 한다.</p></div>
<h3 data-ke-size="size23">5-8. 마음 다스리기</h3>
<div data-ke-size="size16"><p>더 많은 사람을 이끌수록 감정은 억누르고 평정심을 유지해야 한다. 사람들은 의식적으로든 무의식적으로든 사소한 일 하나까지 어떻게 행동하고 반응해야 할지에 관한 단서를 윗사람, 즉 우리로부터 얻기 때문이다.</p></div>
<h3 data-ke-size="size23">5-9. 촉매자 되기<br></h3>
<div data-ke-size="size16"><p>팀 합의 이루기는 비공식 리더가 자주 사용하는 리더십 스킬이다. 실질적인 권한 없이도 이끌 수 있는 방법이기 때문이다. 권한이 있다면 직접 지시하고 방향을 정해줄 수 있지만 합의를 끌어내는 것보다는 전반적으로 효과가 약하다.</p></div>
<h3 data-ke-size="size23">5-10. 장애물 치우기<br></h3>
<p data-ke-size="size16">해야 할 일이 무엇인지 팀 내 합의를 이루었지만 장애물에 막혀 꼼짝달싹 목 하는 경우가 있다. 기술적인 문제일 때도, 조직 차원의 문제일 때도 있다. 어떤 경우든 팀이 다시 움직일 수 있도록 도와주는 것이 일반적인 리더십 기술이다. 단편적인 예로 그 팀의 관리자가 자바 전문가는 아니지만 자바에 대해 문제가 생겼을 경우 다른 자바 전문가와 연결을 해줄 수 있다. 선생이자 멘토 되기<br>테크 리드로서 가장 실천하기 어려운 일을 뽑으라면 ‘내가 하면 20분이면 끝날 일을 세 시간씩 매달려 있는 주니어 팀원 지켜보기’를 빼놓을 수 없다. 훌륭한 멘토라면 성장하는 팀에 발맞춰 멘티가 배우는 데 쓰는 시간과 제품 개발에 기여하는 시간의 균형을 잘 잡아줘야 한다. 멘티에게 최대한의 정보를 제공하는 게 좋은 것도 아니다. 설명이 과하거나 이야기를 끝도 없이 쏟아낸다면 멘티는 그냥 듣는 척만 하고 한 귀로 흘릴 것이다.</p>
<h3 data-ke-size="size23"><br>5-11. 명확한 목표 세우기<br></h3>
<div data-ke-size="size16"><p>팀이 한 방향으로 빠르게 전진하기를 원한다면 리더가 설정한 방향을 모든 팀원이 이해하고 동의해야 한다. </p></div>
<h3 data-ke-size="size23">5-12. 정직하기<br></h3>
<p data-ke-size="size16">팀이 듣고 싶어 하지 않는 걸 말해야만 하는 위치에 있기에 ‘정직하라’라고 할 필요가 있다. 팀원이 찾아와 우리가 말할 수 없는 것에 대해 묻는다면 ‘답은 알지만 내 마음대로 얘기해줄 수는 없다’ 정도로 답하는 것이 괜찮다. 대부분의 관리자용 교재에서 말을 해야 하지만 말하기 곤란한 경우 칭찬 샌드위치 방식으로 충격을 완화하라고 가르친다. 칭찬 샌드위치는 다음 예시를 통해 이해할 수 있다.</p>
<blockquote data-ke-style="style1">
  당신은 팀의 탄탄한 구성원이자 가장 영리한 엔지니어 중 하나예요. 그래서인지 당신의 코드는 복잡하고 다른 팀원 누구도 이해하기가 거의 불가능하군요. 하지만 당신의 잠재력이 크니 여기 저는 티셔츠를 하나 드리겠습니다. 
</blockquote>
<div data-ke-size="size16"><p>하지만 우리는 칭찬 샌드위치를 사용하지 말 것을 강하게 권고한다. 겉에 둘러진 칭찬 때문에 핵심 메시지, 즉 실제로는 고쳐야 할 점을 지적한 것임을 제대로 인지하기 못하는 사람이 대부분이기 때문이다. 상대가 비판을 듣자마자 방어적으로 변하지 않길 원한다면 친절과 공감이 아주 중요하다.<br>직접적인 피드백이나 비판을 전할 때는 메시지를 정확하게 왜곡 없이 전달하는 게 핵심이다.</p></div>
<h3 data-ke-size="size23">5-13. 행복한지 확인하기<br></h3>
<p data-ke-size="size16">리더로서 팀의 생산성을 장기적으로 더욱 끌어올리려면(이탈하는 팀원 줄이기 포함) 팀원들이 행복해하는지를 확인하는 데도 시간을 써야 한다. 한 테크 리드 매니저는 지저분하고 표 안 나는 일, 하지만 꼭 해야만 하는 일들을 스프레드시트에 정라 한 다음 모든 팀원에게 고르게 분배되도록 관리했다. 또 다른 테크 리드 매니저는 팀이 일한 시간을 측정하여 이따금 대체 휴가를 주거나 팀 소풍을 보내주었다. 번아웃과 피로 누적을 피하는 방법이다. 또 다른 리더는 팀원들과의 서먹함도 줄일 겸 일대일 면담을 하며 기술적인 이야기를 나누곤 했다. 그런 다음 업무를 수행하는 데 부족한 것은 없는지 일일이 챙겨주었다.</p>
<blockquote data-ke-style="style1">
  팀원이 행복한지 체크하는 가장 쉬운 방법은 일대일 면담을 하며 마지막에 ‘뭐 필요한 거 없어요?’라고 묻는 것이다. 
</blockquote>
<div data-ke-size="size16"><p>리더라면 회사 밖에서도 팀의 행복에 신경 써주는 게 좋다. 경력 관리 챙겨주기도 팀원 행복 추적에 큰 비중을 차지한다. 일 잘하는 리더가 되려면 팀원들이 이 모든 걸 성취하게 할 방법을 고민하고, 또 이런 고민을 하고 있음을 팀원들이 알게 해야 한다. 가장 중요한 것은 이러한 막연한 목표들을 구체적으로 명시해두는 것이다. 행복도 추적은 단순히 경력을 모니터링하는 데서 그치지 않고 각자에게 스스로를 성장시킬 기회를 만들어주고, 하는 일을 인정해주고, 그 여정에서 약간의 재미를 느끼게 해줘야 한다. 구글이 리더들에게 권장하는 그 외 조언과 요령</p></div>
<h3 data-ke-size="size23">5-14. 위임하되 곤란한 일은 직접 처리하기<br></h3>
<div data-ke-size="size16"><p>팀원에서 리더 역할로 이동할 때 가장 어려운 일 하나가 균형 잡기이다.</p></div>
<h3 data-ke-size="size23">5-15. 우리를 대신할 사람 찾기<br></h3>
<div data-ke-size="size16"><p>뛰어난 팀원으로 남고 싶어 하는 사람도 있으며 이 역시 전혀 문제 될 게 없다는 사실을 잊으면 안 된다. 우리는 수많은 회사가 가장 뛰어난 엔지니어를(본인의 의사에 반하더라도) 관리직으로 내모는 모습에 어이없어하곤 한다. 팀 최고의 엔지니어를 내쫓고 평균 이하의 관리자를 채용하는 것과 같은 행위이다.</p></div>
<h3 data-ke-size="size23">5-16. 파도를 일으켜야 할 타이밍 알기<br></h3>
<div data-ke-size="size16"><p>불가피하고 빈번하게 머릿속에서 ‘무시하고 그냥 지켜봐!’라고 소리치는 상황에 맞닥뜨리는 상황이 온다. 팀에 필요한 기술 수준을 갖추지 못한 엔지니어 때문일 수도 있고 사사건건 열차를 막아서는 사람 때문일 수도 있다. 지금이 바로 직접 나서서 가장 거센 파도를 일으켜야 할 때이다. 이런 문제가 저절로 해결된 가능성은 극히 희박하다. 오히려 오래 끌수록 팀에 더 안 좋은 영향을 미치게 되고 불면증에 시달리는 밤만 늘어날 것이다. 기다려봤자 운명의 시간이 늦어질 뿐이고 그 과정에서 막대한 피해를 입을 것이다. 빨리 조치를 취해야 한다.</p></div>
<h3 data-ke-size="size23">5-17. 혼란으로부터 팀 보호하기<br></h3>
<div data-ke-size="size16"><p>회사는 원래부터 혼란스러웠고 다만 우리가(전임 관리자가) 팀원들을 혼란으로부터 보호해주고 있었고 우리도 그래야 한다.</p></div>
<h3 data-ke-size="size23">5-18. 팀에 공중 엄호해주기<br></h3>
<div data-ke-size="size16"><p>가능한 한 많은 정보를 팀과 공유하되 팀에 실제로 영향을 줄 가능성이 거의 없는 조직 차원의 광기로 팀 업무가 방해받지 않도록 해주어야 한다.</p></div>
<h3 data-ke-size="size23">5-19. 팀이 잘하고 있으면 칭찬하기<br></h3>
<div data-ke-size="size16"><p>누군가 일을 잘못 처리했을 때 알려주는 것처럼 잘 처리했을 때도 꼭 알려주어야 한다. 기대 이상으로 잘 해냈다면 당사자는 물론 팀 전체에 알려주자. 꼭!!!</p></div>
<h3 data-ke-size="size23">5-20. 실패해도 쉽게 되돌릴 수 있는 일에는 ‘해보세요’라고 말하기<br></h3>
<div data-ke-size="size16"><p>새로운 것을 시도하길 원하는 모험적인 팀원에게 최고의 리더가 자주 활용하는 기술이다.</p></div>
<h3 data-ke-size="size23">6. 사람 == 식물<br></h3>
<div data-ke-size="size16"><p>누구에게 무엇이 필요한지 결정하고 제공하는 것이 리더로서 여러분이 해야 할 일입니다. 물론 팀에는 햇볕, 물, 비료가 아닌 동기부여와 방향지시가 필요하다.<br>동기에는 내적 동기와 외적 동기가 있다. 외적 동기는 금전적 보상처럼 바깥에서 기인하는 것이고 안에서부터 무언가 끓어오르는 것이 내적 동기이다. 다니엘이 주장하는 내적 동기부여 방법은 자율성, 숙련, 목적이다. <br>자율성(혹은 주도성)은 다른 사람의 마이크로 매니징 없이 스스로 행동할 수 있는 것을 말한다.<br>숙련(혹은 전문성)의 기본적인 형태는 현재 기술 수준을 높이고 새로운 것을 배울 기회를 제공하는 것이다. 숙련에 필요한 기회를 충분히 제공받은 사람들은 동기가 커지고 때론 야근도 불사하여 결과적으로 더 강한 팀을 만들어준다.<br>일의 목적을 제공해줘야 하는 이유는 아무 의미도 찾을 수 없는 일을 하고 있다면 제아무리 자율성과 숙련의 기회를 줘도 조금의 동기부여조차 되지 못하기 때문이다.</p><p>좋은 관리자는 팀이 일을 스스로 잘하도록 돕고 올바른 목표에 집중하게 하고 조직 외부의 방해 요소를 차단한다. 겸손, 존중, 신뢰를 담아서 말이다.</p></div>
            
            
                </div></div>

흔한 컴공출신 개발자

bernoyoun

0. 들어가며
이번 장은 궁극적으로 ‘책임지는 사람’의 시선으로 이야기를 진행한다.
1. 리더와 매니저
구글은 리더 역할을 두 가지로 구분해 생각한다. 관리자(manager)는 사람을 이끌고 테크 리드(tech lead)는 기술과 관련된 책임을 진다. 
  
2. 우리에게 선장이란
선원이 아무리 많다 한들 선장이 없는 배는 그저 길을 잃은 조각배에 지나지 않다. 소프트웨어에서도 선장이 없다면 엔지니어들은 값진 시간을 허비한다.
3. 관리자와 테크 리드(혹은 둘 다)
모든 팀에서는 리더가 있지만 리더를 모셔오는 방법이 다를 수 있다. 팀에서 경험이 많은 팀원을 리더로 하거나 외부에서 리더를 모셔오기도 한다. 신생 팀의 경우 관리자와 테크 리드 역할을 한 사람이 맡게 되는데 이를 테크 리드 매니저(tech lead manager)라 한다. 엔지니어링 관리자에 대해 말해보자.
많은 회사에서 소프트웨어 엔지니어링에 거의 무지하더라도 훈련된 인사 관리자에게 팀의 운영을 맡긴다. 하지만 구글은 엔지니어링을 아는 사람만이 소프트웨어 엔지니어링 관리자가 될 수 있다. 관리자는 자신이 관리하는 팀의 구성원 모두(테크 리드도 포함)의 성과(performance), 생산성(productivity), 행복(happiness)을 책임져야 한다. 그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 한다. 하지만 사업적 요구와 개별 팀원의 요구가 항상 일치하는 것은 아니어서 관리자는 이따금 난처한 상황에 놓이게 된다. 테크 리드에 대해 말해보자.
테크 리드는 제품의 기술적인 면, 관련한 결정과 선택, 아키텍처, 우선순위, 성능과 일반적인 프로젝트 관리를 책임진다. 테크 리드는 관리자와 긴밀히 협조하며 맡겨진 제품을 개발하는 데 필요한 팀원을 확보하고 엔지니어들의 기술 스펙트럼과 기술 수준을 최대한 활용해 목표를 완수하게끔 이끌어야 한다. 테크 리드는 본인 스스로가 작업을 하는 경우가 있고 일을 위임하는 경우가 있는데 사이즈가 큰 경우 다른 팀원에게 위임하는 편이 나을 때가 많다. 테크 리드 매니저에 대해 말해보자.
완전히 번아웃되지 않고서 두 역할을 동시에 수행하기는 너무도 어렵다. 그래서 각각에 집중하는 전문가를 독립적으로 두는 편이 좋다.
테크 리드 매니저의 역할은 두 역할을 동시에 수행하기에 상당히 힘들다. 자신의 일, 위임, 사람 관리 사이에서 균형을 잡는 요령을 배워야 한다.
4. 팀원에서 리더로
누군가는 선장을 해야 하고 어느 방향으로 가야 할지 정해야 한다. 개발 업계에서 어쩌다 보니 리더가 되어 있는 상황은 아주 흔하다. 문제는 리더가 되기 기피하는 가장 큰 이유는 소프트웨어 개발 분야에서는 코딩할 시간이 크게 줄어든다는 점이다. 물론 누군가는 해야 할 일이고 관리자 업무를 했다는 것이 일을 안 했다는 것은 아니다. 간혹 관리직에 있으며 코드 한 줄 만들지 못한 하루를 보낸 사람은 일을 하나도 하지 않았다고 스스로 자책을 하는 경우가 있지만 이건 정말 큰 착각이다.
관리자들에게는 특히 일종의 질병이 있는 것처럼 보인다. 선임 관리자가 자신에게 했던 끔찍한 일들을 새까맣게 잊고 자신도 어느덧 똑같은 식으로 사람들을 ‘관리’하게 되는 병이다.
이 ‘관리’병을 치료하려면 섬기는 리더십(Servant Leadership)을 자유롭게 응용할 수 있어야 한다. 리더로서 우리는 겸손, 존중, 신뢰의 분위기를 조성하려 힘써야 하고 그 결과로 팀의 기술적 건강뿐 아니라 사회적 건강도 챙겨야 한다.
 
5. 엔지니어링 관리자
이 문장을 기억하자.
성공적인 테크 리드와 엔지니어링 관리자로 만들어주는 패턴 중 안티 패턴을 살펴보자. 
5-1. 만만한 사람을 고용하기
만만하다는 것은 실력도 고만고만하다는 것이고 비약적으로 나보다 무능력하다는 의미일 수 있다. 우리는 더 나은 팀을 만들기 위해 우리를 대체할 수 있는 역량을 가진 사람을 적극적으로 뽑아야 한다.
5-2. 저성과자 방치하기
저성과자를 방치하는 일은 새로운 고성과자가 팀에 합류하는 것을 막기도 하며 그나마 있던 팀 내 고성과자를 떠나게도 한다. 그러다 보면 결국 스스로의 힘으로 떠날 수 없는 저성과자로만 구성된 팀이 남게 된다.
5-3. 사람 문제 무시하기
관리자는 사회적 문제와 기술적 문제 이 두 가지에 신경을 써야 한다. 구글의 관리자들은 일반적으로 기술 측면에 강점을 가지고 있다. 그리고 대부분의 관리자가 기술 업무를 수행하다 승진하였기 때문에 사람의 문제는 소홀히 하는 경향이 있다.
5-4. 만인의 친구 되기
처음 리더가 되는 경험은 대부분 자신이 속한 팀의 관리자나 테크 리드로 승진하며 시작된다. 부드럽게 끌어주는 리딩과 우정을 혼동하면 안 된다. 우리에게는 팀원들의 경력을 좌지우지할 힘이 있기 때문에 인위적이고 낯선 여러분의 행동에서 팀원들은 오히려 압박을 느낄 수 있다.
5-5. 채용 기준 타협하기
스티브 잡스가 한 말 중 이런 말이 있다.
 
5-6. 팀을 어린이처럼 대하기
우리가 팀을 신뢰하지 못함을 보여주는 가장 대표적인 예가 팀원들을 어린이처럼 대하는 것이다. 사람들은 자신을 대하는 방식대로 행동하는 경향이 있다고 한다. 어린이나 죄수처럼 대하면 그들이 어린이나 죄수처럼 행동한다고 한다. 마이크로 매니징을 하거나 단순히 팀원들의 능력을 존중하지 않고 자신의 일에 책임질 기회를 주지 않으면 우리는 팀원을 어린이처럼 대하는 것과 다를 바 없다. 실제로 특정 팀원을 믿지 못해서 마이크로 매니징 할 수밖에 없는 상황이 고착화된다면 우리가 채용을 잘못한 것이다.
위에서 안티 패턴들을 알아봤으니 이제 올바른 패턴도 알아보도록 하자.
 
5-7. 자존심 버리기
2장에서 겸손, 존중, 신뢰를 처음 이야기하였는데 팀 리더에게 특히 중요한 덕목이다. 신뢰는 ‘자존심 버리기’의 한 축이다. 팀을 믿어라. 팀원들의 능력과 기준에 이룬 성과들을 존중해야 한다는 뜻이다. 새로 합류한 팀원이라도 마찬가지다. 장담하건대 우리는 때론 잘못된 결정을 내릴 것이며 모든 문제의 답을 알고 있지도 못한다. 그럼에도 스스로가 완벽한 듯 행동한다면 팀원들의 존경을 빠르게 잃어갈 것이다. 자존심 버리기의 가장 중요한 부분은 ‘실수했다면 사과하기’이다. 말로만 하는 것이 아닌 진심을 담아야 한다.
5-8. 마음 다스리기
더 많은 사람을 이끌수록 감정은 억누르고 평정심을 유지해야 한다. 사람들은 의식적으로든 무의식적으로든 사소한 일 하나까지 어떻게 행동하고 반응해야 할지에 관한 단서를 윗사람, 즉 우리로부터 얻기 때문이다.
5-9. 촉매자 되기
팀 합의 이루기는 비공식 리더가 자주 사용하는 리더십 스킬이다. 실질적인 권한 없이도 이끌 수 있는 방법이기 때문이다. 권한이 있다면 직접 지시하고 방향을 정해줄 수 있지만 합의를 끌어내는 것보다는 전반적으로 효과가 약하다.
5-10. 장애물 치우기
해야 할 일이 무엇인지 팀 내 합의를 이루었지만 장애물에 막혀 꼼짝달싹 목 하는 경우가 있다. 기술적인 문제일 때도, 조직 차원의 문제일 때도 있다. 어떤 경우든 팀이 다시 움직일 수 있도록 도와주는 것이 일반적인 리더십 기술이다. 단편적인 예로 그 팀의 관리자가 자바 전문가는 아니지만 자바에 대해 문제가 생겼을 경우 다른 자바 전문가와 연결을 해줄 수 있다. 선생이자 멘토 되기
테크 리드로서 가장 실천하기 어려운 일을 뽑으라면 ‘내가 하면 20분이면 끝날 일을 세 시간씩 매달려 있는 주니어 팀원 지켜보기’를 빼놓을 수 없다. 훌륭한 멘토라면 성장하는 팀에 발맞춰 멘티가 배우는 데 쓰는 시간과 제품 개발에 기여하는 시간의 균형을 잘 잡아줘야 한다. 멘티에게 최대한의 정보를 제공하는 게 좋은 것도 아니다. 설명이 과하거나 이야기를 끝도 없이 쏟아낸다면 멘티는 그냥 듣는 척만 하고 한 귀로 흘릴 것이다.
5-11. 명확한 목표 세우기
팀이 한 방향으로 빠르게 전진하기를 원한다면 리더가 설정한 방향을 모든 팀원이 이해하고 동의해야 한다. 
5-12. 정직하기
팀이 듣고 싶어 하지 않는 걸 말해야만 하는 위치에 있기에 ‘정직하라’라고 할 필요가 있다. 팀원이 찾아와 우리가 말할 수 없는 것에 대해 묻는다면 ‘답은 알지만 내 마음대로 얘기해줄 수는 없다’ 정도로 답하는 것이 괜찮다. 대부분의 관리자용 교재에서 말을 해야 하지만 말하기 곤란한 경우 칭찬 샌드위치 방식으로 충격을 완화하라고 가르친다. 칭찬 샌드위치는 다음 예시를 통해 이해할 수 있다.
하지만 우리는 칭찬 샌드위치를 사용하지 말 것을 강하게 권고한다. 겉에 둘러진 칭찬 때문에 핵심 메시지, 즉 실제로는 고쳐야 할 점을 지적한 것임을 제대로 인지하기 못하는 사람이 대부분이기 때문이다. 상대가 비판을 듣자마자 방어적으로 변하지 않길 원한다면 친절과 공감이 아주 중요하다.
직접적인 피드백이나 비판을 전할 때는 메시지를 정확하게 왜곡 없이 전달하는 게 핵심이다.
5-13. 행복한지 확인하기
리더로서 팀의 생산성을 장기적으로 더욱 끌어올리려면(이탈하는 팀원 줄이기 포함) 팀원들이 행복해하는지를 확인하는 데도 시간을 써야 한다. 한 테크 리드 매니저는 지저분하고 표 안 나는 일, 하지만 꼭 해야만 하는 일들을 스프레드시트에 정라 한 다음 모든 팀원에게 고르게 분배되도록 관리했다. 또 다른 테크 리드 매니저는 팀이 일한 시간을 측정하여 이따금 대체 휴가를 주거나 팀 소풍을 보내주었다. 번아웃과 피로 누적을 피하는 방법이다. 또 다른 리더는 팀원들과의 서먹함도 줄일 겸 일대일 면담을 하며 기술적인 이야기를 나누곤 했다. 그런 다음 업무를 수행하는 데 부족한 것은 없는지 일일이 챙겨주었다.
리더라면 회사 밖에서도 팀의 행복에 신경 써주는 게 좋다. 경력 관리 챙겨주기도 팀원 행복 추적에 큰 비중을 차지한다. 일 잘하는 리더가 되려면 팀원들이 이 모든 걸 성취하게 할 방법을 고민하고, 또 이런 고민을 하고 있음을 팀원들이 알게 해야 한다. 가장 중요한 것은 이러한 막연한 목표들을 구체적으로 명시해두는 것이다. 행복도 추적은 단순히 경력을 모니터링하는 데서 그치지 않고 각자에게 스스로를 성장시킬 기회를 만들어주고, 하는 일을 인정해주고, 그 여정에서 약간의 재미를 느끼게 해줘야 한다. 구글이 리더들에게 권장하는 그 외 조언과 요령
 
5-14. 위임하되 곤란한 일은 직접 처리하기
팀원에서 리더 역할로 이동할 때 가장 어려운 일 하나가 균형 잡기이다.
5-15. 우리를 대신할 사람 찾기
뛰어난 팀원으로 남고 싶어 하는 사람도 있으며 이 역시 전혀 문제 될 게 없다는 사실을 잊으면 안 된다. 우리는 수많은 회사가 가장 뛰어난 엔지니어를(본인의 의사에 반하더라도) 관리직으로 내모는 모습에 어이없어하곤 한다. 팀 최고의 엔지니어를 내쫓고 평균 이하의 관리자를 채용하는 것과 같은 행위이다.
5-16. 파도를 일으켜야 할 타이밍 알기
불가피하고 빈번하게 머릿속에서 ‘무시하고 그냥 지켜봐!’라고 소리치는 상황에 맞닥뜨리는 상황이 온다. 팀에 필요한 기술 수준을 갖추지 못한 엔지니어 때문일 수도 있고 사사건건 열차를 막아서는 사람 때문일 수도 있다. 지금이 바로 직접 나서서 가장 거센 파도를 일으켜야 할 때이다. 이런 문제가 저절로 해결된 가능성은 극히 희박하다. 오히려 오래 끌수록 팀에 더 안 좋은 영향을 미치게 되고 불면증에 시달리는 밤만 늘어날 것이다. 기다려봤자 운명의 시간이 늦어질 뿐이고 그 과정에서 막대한 피해를 입을 것이다. 빨리 조치를 취해야 한다.
5-17. 혼란으로부터 팀 보호하기
회사는 원래부터 혼란스러웠고 다만 우리가(전임 관리자가) 팀원들을 혼란으로부터 보호해주고 있었고 우리도 그래야 한다.
5-18. 팀에 공중 엄호해주기
가능한 한 많은 정보를 팀과 공유하되 팀에 실제로 영향을 줄 가능성이 거의 없는 조직 차원의 광기로 팀 업무가 방해받지 않도록 해주어야 한다.
5-19. 팀이 잘하고 있으면 칭찬하기
누군가 일을 잘못 처리했을 때 알려주는 것처럼 잘 처리했을 때도 꼭 알려주어야 한다. 기대 이상으로 잘 해냈다면 당사자는 물론 팀 전체에 알려주자. 꼭!!!
5-20. 실패해도 쉽게 되돌릴 수 있는 일에는 ‘해보세요’라고 말하기
새로운 것을 시도하길 원하는 모험적인 팀원에게 최고의 리더가 자주 활용하는 기술이다.
6. 사람 == 식물
누구에게 무엇이 필요한지 결정하고 제공하는 것이 리더로서 여러분이 해야 할 일입니다. 물론 팀에는 햇볕, 물, 비료가 아닌 동기부여와 방향지시가 필요하다.
동기에는 내적 동기와 외적 동기가 있다. 외적 동기는 금전적 보상처럼 바깥에서 기인하는 것이고 안에서부터 무언가 끓어오르는 것이 내적 동기이다. 다니엘이 주장하는 내적 동기부여 방법은 자율성, 숙련, 목적이다. 
자율성(혹은 주도성)은 다른 사람의 마이크로 매니징 없이 스스로 행동할 수 있는 것을 말한다.
숙련(혹은 전문성)의 기본적인 형태는 현재 기술 수준을 높이고 새로운 것을 배울 기회를 제공하는 것이다. 숙련에 필요한 기회를 충분히 제공받은 사람들은 동기가 커지고 때론 야근도 불사하여 결과적으로 더 강한 팀을 만들어준다.
일의 목적을 제공해줘야 하는 이유는 아무 의미도 찾을 수 없는 일을 하고 있다면 제아무리 자율성과 숙련의 기회를 줘도 조금의 동기부여조차 되지 못하기 때문이다.
좋은 관리자는 팀이 일을 스스로 잘하도록 돕고 올바른 목표에 집중하게 하고 조직 외부의 방해 요소를 차단한다. 겸손, 존중, 신뢰를 담아서 말이다.

구글 엔지니어는 이렇게 일한다 part2 문화 - 5장 팀 이끌기

댓글