Dayoung

Dayoung

Be-Developer

© 2024

Dark Mode

SoftwareEngineering at google : 문화
Mar 12, 2023
  • softwareEngineering,
  • study

02 팀워크 이끌어내기

내코드를 숨기고 싶어요

  • 다른사람들의 기대에 미치지 못할것이라는 두려움.

    천재 신화

  • 성공한 프로젝트는 유명한 대표1명이 완성한것이 아니라, 그가 이끄는 팀이 완성한것.
  • 기술 전문가 셀럽 현상 : 인간은 본능적으로 리더와 롤모델을 찾고 우상화하고 흉내내려한다. 우리에겐 영감을 줄 영웅이 필요하며 프로그래밍 세계도 다르지 않다.
  • 우리 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐 이다.

    숨기는것은 해롭다

  • 집중과 인내가 주는 가치를 협업과 인내로 맞서 이겨내야한다.

    조기감지

  • 일찍 실패하고, 빨리 실패하고, 자주 실패하라

    버스지수

    : 몇명의 팀원이 버스에 치어서(다양한 사유로) 일을 할수없게 될때 프로젝트가 망하게 되는지를 나타내는 지수

  • 최소한 각 책임 영역마다 2차소유자(담당자)를 두고 제대로 된 문서를 갖추어둔다면, 프로젝트의 미래를 보장하고 버스지수를 높이는데 도움이 된다.
  • 혼자일하게 되면 버스지수 외에 전반적인 진행 속도에도 해롭다.

    진척 속도

  • 팀플레이가 속도를 높이는데 도움이 된다.
  • 눈이 많아야 버그가 줄어든다.

    결론은, 숨기지 말자

  • 홀로 일하기는 함께 일하기보다 본질적으로 위험하다. 다른사람이 아이디어를 훔친다거나 여러분이 똑똑하지 않다고 생각하는게 두렵더라도, 잘못된 일에 천금같은 시간을 낭비할 가능성을 더 걱정해야한다.

    모든건 팀에 달렸다

    사회적 상호작용의 세 기둥

    1. 겸손 : 당신은 모든것을 알지도, 완벽하지도 않는다. 겸손한 사람은 배움에 열려있다.
    2. 존중 : 동료를 친절하게 대하고, 그들의 능력과 성취에 감사해야한다.
    3. 신뢰 : 동료들이 유능하고 올바른 일을 하리라 믿고, 스스로 방향을 정하게 해도 좋다.

      세 기둥이 중요한 이유

  • 만약 당신에게 필요한 시스템이 있따면 그 시스템이 당신의 일을 어떻게 도울 수 있을지 연구하라.
  • 사회적 관계의 힘을 과소평가 하지말라. 일이 진행되도록 관계를 형성해야한다.

    겸손, 존중, 신뢰 실천하기

    1. 자존심 버리기
    • 자기가 가장 현명하다고 확신하더라도 그 속내를 겉으로 드러내서는 안된다.
    • 모든것을 다 아는듯 행동하지 말라.
    • 모든 논의주제를 시작하고 마무리짓는 사람이 자신이 되어야한다거나, 안건마다 첨언하고싶다거나 하는 마인드는 버려라.
      1. 비평하고 비평받는법 배우기
    • 성향을 공격하는것은 쓸데없는 짓이다.
    • 건설적으로 비판하는 사람은 상대를 진심으로 생각하고 상대의 업무가 개선되길 바라야한다.
    • 우리의 자존감을 우리가 작성한 코드,창작물과 동일시 해서는 안된다.
    • 코드리뷰의 예
      • ASIS : xyz 패턴을 적용했어야 해요. 코드에 해선 안될 행동이 많네요. 고쳐주세요
      • TOBE : 이부분의 제어 흐름이 조금 헷갈리네요, 혹시 xyz를 적용하면 명확해질까요? 나중에 관리하기 쉬워지기도 하겠네요
      • 상대가 아닌 자신을 낮추고, 상대가 틀린것이 아니라 여러분이 코드를 이해하는데 문제를 겪고 있는것으로 말하자.
      • 누군가의 가치나 코딩 기술이 아니라 코드 자체에 집중하라.
        1. 빠르게 실패하고 번복하기
    • 실패를 배우고 다음 단계로 넘어갈 수 있는 절호의 기회라고 생각하자.
    • 구글X 에서는 실패를 보상 제도에 녹였는데, 엉뚱한 아이딛어를 내고 동료들에게는 가능한 빠르게 아이디어를 파쇄하라고 장려한다. 기간동안 얼마나 반증하는지에 따라 보상을 받고 경쟁하고, 반증할수없는 아이디어라면 채용한다.

      비난 없는 포스트 모템 (postMortem) 문화

  • 실패한 근본 원인을 분석하여 문서로 남기는것이 실수로 부터 배우는 핵심이다.
  • 포스트모템에 담겨야하는 내용
    1. 사건의 개요
    2. 사건을 인지하고 해결에 이르기까지의 타임라인
    3. 사건의 근본 원인
    4. 영향과 피해 평가
    5. 문제를 즉시 해결하기 위한 조치 항목
    6. 재발 방지를 위한 조치 항목
    7. 해당 경험에서 얻은 교훈₩
      1. 인내심을 기르자.
      2. 마음을 열고 받아들이자. : 다른사람이 내생각을 바꿔도 괜찮다는 마인드. - 제대로 들으려면 다른 이의 말에 귀기울여야 한다. 결정사항을 공표하기 전에 주변의 말을 듣자. - 결점을 드러낸다는 것은겸손을 겉으로 표현하는 일이다. - 팀원은 동반자이지 경쟁자가 아니다. 방어적인 태도를 고집할 필요가 없다.

        구글다움?

  • 모호함을 뚫고 번창한다. : 변화하는 환경속에서 상충하는 메세지와 방향에 잘 대처하고, 합의를 이끌어내 문제 진전시킬 수 있어야한다.
  • 피드백을 소중히 한다.
  • 저항(항상성)을 극복한다. : 다른 이들이 저항하거나 관성때문에 움직이지 않으려 해도 야심찬 목표를 세우고 밀고 나가야한다.
  • 사용자를 우섢나다.
  • 팀에 관심을 기울인다.
  • 옳은 일을 한다 : 강한 윤리의식을 갖고 일해야한다.

정리

  • 팀 혹은 더 큰 조직안에서 효과적으로 일하고 싷ㅍ다면 자신이 선호하는 업무방식, 다른 사람들이 선호하는 방식도 알아야한다.

03 지식 공유

  • 조직에 배움의 문화가 자리잡혀야하고, 사람들에게 모르는걸 인정 할 수 있또록 돕는 심리적 안전을 제공해야한다.

    배움을 가로막는 장애물

  • 심리적 안전 부족 : 불이익이 두려워서 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경
  • 정보섬 : 각 부서가 소통하거나 자원을 공유하지 않아서 지식이 파편화된다.
  • 단일 장애점 : 중요한 정보를 한사람이 독점하면 병목이 생긴다.
  • 전부 아니면 전무 전문성 : 전문가와 초심자로 나뉘고 허리가 사라진다 > 지식과 책임은 전문가에게 집중되고, 팀원이나 초심자는 느리게 성장한다.
  • 앵무새처럼 흉내내기 (parroting) : 이해하지 못한 상태로 무의식적으로 패턴이나 코드를 따라하는것.
  • 유령의 묘지 : 무언가 잘못될게두려워 아무도 손대지 않는 영역

문서화,

  • 문서화된 지식은 팀을넘어 조직 전체로 퍼트릴 수 있다.
  • 조직 스스로 교육하고, 배우고 성장하는데 집중하고, 충분한 수의 전문가를 양성해야한다.

판깔아주기 : 심리적 안전

  • 타인의 무지를 탓하지 말고, 그 솔직함을 반겨야한다.
  • 배움에는 무언가를 시도하다 실패해도 안전하다는 인식이 매우 중요하다.

멘토 제도

: 구글에서 누글러(뉴비)가 합류하면, 뉴비에게 질문의 두려움을 줄여줄 수 있는 멘토가 할당된다.

큰 그룹에서의 심리적 안전

  • 소통에 권장되는 패턴
    • 거짓된 놀람 금지 (뭐라고 모른다고?) : 심리적 안전을 방해하여 모른다는 사실을 인정하기를 두려워하게 된다.
    • 음, 실제로는 금지 : 지나칠정도로 세세하게 고쳐주는것은 정밀성보다는 본인자랑의 무의식일 가능성이 크다.
    • 뒷좌석 운전 금지 : 토론중에 발언권 없이 끼어들어 의견제시하지 말자.
    • 미묘한 -주의 금지 : 인종,연령, 동성애혐오 등 편견이 깃든 표헌 사용 금지.

내 지식 키우기

질문 하기

  • 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이라.
  • 팀의 리더든 새로운 멤버든 무언가 배울게 있는 환경에서 살아야 한다.
  • 가면 증후군 (사기꾼 신드롬) : 자신의 능력보다 과대평가 받고 있다고 느껴져서 자칫 실수하면 자신이 사기꾼임을 들킬지 모른다는 두려움, 면접관들도 바보가 아닌이상 감안해서 뽑았을것이니 도전을 두려워하지 말자.
  • 상급자라면 모든것을 알아야한다는 인식이 생기지 않도록 주의하라.

맥락 이해하기

  • 무언가를 옮기거나 바꾸려면 그게 왜 그자리에 있는지부터 이해하자.
  • 용도를 모르겠다면 그냥 밀어버리자! 보다는 용도를 알아내면 그때 철거를 결정하자.

질문 확장하기 : 커뮤니케이션에 묻기

  • 미래의 자신을 위해서라도 무던가를 일대일로 배울때는 기록하는 습관을 기르자.

    그룹 채팅

  • 실시간으로 전문가들에게 답변을 받고, 임시 문서화? 되어 히스토리 찾는데도 좋다.

    메일링 리스트

  • 맥락정보가 많이필요한 복잡한 질문에 적합하지만, 채팅처럼 빠르게 주고받는 대화에는 취약하다.
  • 이메일 아카이브는 내용 수정이 불가하여 오래된 내용 최신화가 어렵다.

    YAQS (yet another question system) 플랫폼

  • 채팅과 메일링 리스트의 단점을 보완한 Q&A플랫폼, 시간이 지나도 정보를 수정하기 쉽다.

지식 확장하기 : 누구나 가르칠게 있다.

오피스 아워

: 누군가가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워둔 정기적 이벤트.

  • 즉각적인 답이 필요해 다른 시간에 질문할 가능성이 크지만, 오피스아워는 전문가와 직접 대면할 기회를 제공한다는 점.

기술 강연과 수업

  • 수업의 효과를 극대화하는 조건
    • 수업 개설비용이 크므로, 요구가 있을만한 복잡한 주제를 다루어야 한다.
    • 수업 내용이 자주바뀐다면 다른 공유형태를 찾아보는것이 낫다.
    • 수업의 난이도가 혼자 공부할수 있는 내용보다, 교사가 있어야 효과가 큰 주제가 좋다.
    • 수업을 정기적으로 개설해도 될만큼 수요가 있어야 한다.

      문서 자료

      1. 문서자료 갱신하기 : 무언가를 막 배운 순간이 기존 문서자료에서 개선점을 찾기 좋은 때이다.
      2. 새로운 문서자료 작성하기 : 발견될 수 없고, 검색되지 않는 문서자료는 존재하지않는것과도 같다.
      3. 문서화 촉진하기 : 문서화가 꼭 남을 위한것은 아니다. 같은 문서로 팀원이 찾아오면 문서자료를 건네 스스로 해결하게 할 수 있다.
    • 적절한 보상으로 문서화의 필요성을 대두시키자.
    • 문서화는 팀과 조직의 규묘를 키우는데에도 보탬이 된다.

      코드

  • 코드리뷰는 작성자와 리뷰어 모두에게 배움의 기회를 준다.
  • 코드내 주석도 문서화의 일부.

    조직의 지식 확장하기

    지식 공유 문화 일구기

    1. 존중
    • 지식을 공유할때는 상냥함과 존중을 담아야한다.
      1. 보상과 인정
    • 많은 조직에서 어떤 가치를 추구할지 까지는 잘 정해놓은 다음, 엉뚱하게 가치를 강화하는 일과 관련없는 활동에만 보상하는 실수를 한다.
    • 구글에서는 동료추천 보상이라는 직원이 주도하는 보상제도가 있다.
      • 지식 공유에 대한 기여를 인정하고, 지식공유 활동이 팀 너머까지 전해졌음을 공개적으로 인정해줄 수 있다.
      • 동료의 업적을 인정해주는 제도는 이타적이고 멋진 일을 하도록 강한 동기를 부여한다.

        표준 정보 소스 구축하기

  • 눈에 잘띄게 두고, 적극적으로 관리하고 감독해야하며, 복잡한 주제일수록 소유자를 명확히 해야한다.
    • 개발자 가이드
      • 구글에서는 회사차원에서 깊이있는 공식 가이드를 만들어 제공한다.
    • go/ link
      • 구글에서 사용하는 url 단축 서비스, 대화중 링크 공유에도 쉽다.
      • 링크유형이 통일되있어서 찾기도 쉽다. ex) go/python : 파이선 개발 가이드
      • 실제 url이 바뀌더라도 go/ link 매핑만 바꾸면 되어 관리가 쉽다.
    • 코드랩
      • 구글에서 제공하는 실습형 튜토리얼, 강사가 주도하는 수업 형식이므로, 관리비용이 많이들며 학습자의 요구에 대응할 수 없다.
    • 정적 분석
      • 조직 차원에서 많은 모범 사례를 더 일관되도록 적용할 수 있다.
      • 초반 설정만 하면 관리비용이 크지않다.
      • 어떤 도구는 한단계 더 발전하여 개선사항을 자동으로 적용하게끔 제안하기도 한다.

        소외되지 않기

  • 뉴스레터
    • 공식 문서는 항상 최신상태 유지가 기대되지만, 뉴스레터는 유지가 필요하지않다.
  • 커뮤니티
  • 다른 부서의 구글러들과 커뮤니티로 지식 공유

가독성 제도 : 코드 리뷰를 통한 표준 멘토 제도

가독성 인증 프로세스

  • 가독성 자격증이 있는 유저의 승인이 있어야 pr 머지가 가능함.
  • 1~2%의 엔지니어가 가독성 리뷰어로 활동중.

    가독성 인증 프로세스를 두는 이유

  • 문서로 정리된 모범사례들은 구글 코드에서 따라야하는 일관화된 표준을 제공하는데, 가독성 제도는 이를 시행하고 전파하는 매커니즘.
  • 코드베이스 전체가 일관될때 얻는 가치는 크다. 팀 이전 및 다른 코드를 보아도 쉽게 이해할 수 있다.
  • 들이는 비용 대비 이익이 큰가? 가독성 인증 프로세스를 이수한 엔지니어 대다수가 만족한다.
    • 대다수는 정적분석이 자동 검출하고, 리뷰어들은 더 고차원적 문제에 집중하도록 지원한다.

정리

  • 대부분의 지식을 쉽게공유하는데 투자한 노력은 회사 생애동안 그 몇배로 돌려받을 수 있다.

04 공정사회를 위한 엔지니어링

편견은 피할 수 없다.

  • ex) 구글포토 이미지 인식 알고리즘이 흑인을 ‘고릴라’ 로 분류했던 사건, 학습 데이터셋에 흑인 자료가 부족했다. 의도적으로 드러난 차별이 아닌 무의식적 편견이 편향된 제품을 탄생시킨 사례.
  • 소프트웨어 엔지니어링 조직 자체의 인적 구성을 제품이 목표하는 시장의 인적 구성과 비슷해지도록 돕는것도 방법.

다양성이 필요한 이유 이해하기

  • 모두를 위한 제품을 개발하려면 먼저 우리가 어떤 사람들을 대표하는지를 이해해야한다. (ex) 중소득층에 해당하는 비장애인 한국인 집단?)
  • 팀 구성원이 다양한 계층을 대표할 수 없다면, 엔지니어 각각이 모두를 위한 제품을 만드는 방법을 배워야한다.

    다문화 역량 갖추기

  • 엔지니어는 사회를 변화시킬 힘을 가지고있다.
  • 무언가를 만들어야할 때와 아닐때를 구분하는 안목도 갖추어야 한다. 우리가 구축하는 시스템이 모든 사람에게 번영을 가져다주거나 차별받지않고 기술을 접할 수 있는 잠재적인 기회를 날려버릴 가능성은 없는지 이해해야한다.
    • 키오스크?
    • 지문인식? 손이 없으면?
  • 사회적,교육적 요인때문에 심어진 편견의 현재상태를 인식하는것이 먼저.

    다양성 실천하기

    단일한 접근방식 거부하기

  • 팀원을 다양성있게 구성하기 위해 채용과정만 수정하면 되는것이 아니라, 승진과 고용 유지(이탈 방지) 측면에서도 제도적 차별을 주시해야한다.
    • 여성의 출산후 고용 유지등
  • 리크루터가 성별 구분없이 능력있는 후보자들을 알아보는 식견을 갖추고 있는지 확인해야한다.
  • 많이쓰이는 기능을 먼저 개발하고, 특수한 케이스는 나중에 개선하는 방식
    • 기술을 접하기에 유리한 사람들에게 우선권을 줌으로써 불평등을 가중시키는 방식.
    • 시작부터 포용적으로 설계하여 개발이 지향해야하는 기준점을 높여주세요.
      • 웹 접근성 적용을 후순위 과제로 미루는것?
    • 가장 어렵고 가장 소외된 사용 사례를 최우선으로 살펴야한다.

      확립된 프로세스에 도전하기

  • 팀이동이 되는 새로운 지원자의 과거 팀에서의 성과를 보는것은 공평하지 않다.
    • 등급은 특정 시기의 성과 평가에 중요한 수단이지만, 미래성과를 예견하지 못한다.
    • 앞으로 맡길 역할에 준비되어있느냐를 평가하거나 팀 이동시 자격을 논하는 데에는 이용되면 안된다.
    • 지원자가 팀에 적합한지를 평가하느나데는 참고할 수 있다.
    • 어떻게 지원자를 더 잘 도와줄 수 있는지 고민해볼 수 는 있다.
  • 아예 다른 직무라면 지표를 참고하지 않을수도 있겠지만,,? 같은 직무라면 필요하지않을까?
  • 블라인드 채용이 있는 이유인가?

    가치 vs 결과

    1. 자신을 솔직하게 보고 성찰하자.
    2. 모두를 위해 만들지 말자 . 모두와 함께 만들자. (팀원 구성)
    3. 제품을 이용하기 가장 어려운 이들을 위해 설계하자.
    4. 가정하지 말고, 시스템 전반의 공정성을 측정하자. : 다양성,공정성, 포용성 전문가와 협력해야한다.
    5. 변해야한다. : 감시,허위사실유포,사이버 폭력 등을 과거 실패한 방식과 기술로는 해결할수없으므로 변해야한다.
  • 웹 개발자가 챙겨야할 차별?
    • 연관 검색어?
    • 웹 접근성
    • 언어 다양성?

05 팀 이끌기

  • 관리자는 사람을 이끌고, tech lead 는 기술과 관련한 책임을 진다.

    관리자와 테크리드 혹은 둘다

    엔지니어링 관리자

  • 구글은 엔지니어링을 아는 사람만이 할수있다.
  • 팀 구성원 모두의 성과생산성,행복을 책임지고, 제품의 사업적 요구까지 충족시켜야 한다.

    테크 리드

  • 기술과 관련한 결정과 선택 아키텍처 우선순위, 성능과 일반적인 프로젝트 관리.
  • 엔지니어들의 기술 스펙트럼과 기술 수준을 최대한 활용해 목표를 완수하게끔 이끌어야 한다.

    테크 리드 매니저 (TLM, 관리자 + 테크리드)

  • TLM은 인적, 기술적 요구를 혼자 관장하는 사람이고, 경력이 오래된 최근까지 개인 기여자였던 사람에게 맡긴다.
  • 각각에 집중하는 전문가를 독립적으로 두는편이 낫다.

    개인 기여자에서 리더로

    두려워해야 햘 건 오직… 전부다.

  • 피터의 법칙 : 자신의 무능력이 드러나는 직급까지 승진할수있다.
  • 리더를 하고싶지않은 개인기여자에게 리더역할을 준다면, 형편없는 관리자를 얻는대신 뛰어난 엔지니어를 잃게된다.
  • 리더를 하게되면 경력 스펙트럼을 확장할 수 있다.
  • 보통 리더가 되기를 꺼려하지만, 하다보면 리더로서의 재능을 찾는 경우가 있다.

    섬기는 리더십

  • 섬기는 리더가 행하는 ‘관리’는 오직 팀의 기술적,사회적 건강관리뿐이다.

엔지니어링 관리자

관리자는 밥맛이야

  • (Pointy-haired) 관리자는 과거 산업혁명때나 효율적이었던 방식
  • 당근과 채찍방식은 비효율적이고 창의적인 사람의 생산성을 떨어뜨린다는 연구는 수도 없다.
  • 대신 소프트웨어 엔지니어에게는 생각하고 창조할 자양분과 시간 공강이 필요하다.

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

  • 전통적인 관리자는 일을 ‘어떻게’ 처리할지를 고민하는 반면, 훌륭한 관리자는 ‘무슨’일을 처리할지를 고민하고 ‘어떻게’ 는 팀을 믿고 맡긴다.
  • 실패는 선택이다
    • 팀이 위험을 감수하는 문화를 조성하는 멋진 방법은 실패해도 괜찮음을 알게 하는것이다.
    • 실패는 많은것을 아주 빠르게 배울 수 있는 기회이고, 실패후에 포스트모템을 작성하여 반복되지않도록 예방장치를 고안할 수 있다.
    • 실패해도 괜찮지만 ‘팀으로서 함께’ 실패하고, 실패로부터 배워야한다. 잘한것은 팀원이 보는앞에서 칭찬해주고, 실패한 개인에게는 개인적으로 불러서 건설적인 비판을 해주어야 한다.

안티패턴

  1. 만만한 사람 고용하기
    • 직장에서의 자리는 유지할 수 있을지 몰라도, 결국 일을 본인이 하게되어 생산성이 떨어질것이다.
  2. 저성과자 방치하기
    • 저성과자를 방치하면 고성과자가 떠나게된다.
    • 저성과자에게는 겸손,존중,신뢰가 바탕이된 마이크로매니징이 필요하다.
      • 기간을 정하고 (ex 두달) 구체적인 목표를 제시하여 성공과 실패를 경험하게 한다.
    • 저성과자에 적극적ㅇ로 대응하다 보면 의외로 작은 격려와 방향 제시가 필요했을 뿐이기도 하다.
  3. 사람문제 무시하기
    • 팀원의 개인사정을 이해하고 배려할 수 있어야 한다. 독단적이면 안된다는 뜻
  4. 만인의 친구 되기
    • 역할이 바뀌어도 우정을 잃지않으려면, 우정과 리딩을 혼동하지 않아야 한다.
    • 점심을 같이먹거나, 업무 외적인 대화를 나누어 사회적 유대를 유지
  5. 채용기준 타협하기
    • 적합한 사람을 찾는데 드는 비용은(광고, 검증등) 적합하지 않은 사람을 채용했을때 처리하는 비용보다 훨씬 저렴하다. 아끼지말자
    • 팀원 채용시 발언권이 없고 채용된 사람들이 만족스럽지 못하다면, 더 뛰어난 엔지니어를 뽑아달라고 필사적으로 싸워야 한다. 그럼에도 평균 이하의 엔지니어들이 팀에 배속된다면 이직타이밍
  6. 팀을 어린이처럼 대하기
    • 팀원을 믿지못해서 마이크로매니징할수밖에 없는 상황이 고착화 된다면 채용을 잘못한 것.
    • 믿을만한 사람을 뽑고 신뢰를 보여준다면 보통은 그들도 능력을 발휘할 것.

      올바른 패턴

  7. 자존심 버리기
    • 대신 팀이라는 집단으로서의 자존심과 정체성을 강화해야한다.
    • 질문하기 문화를 장려한다면 건설적인 비판이 이루어지는 더 나은 팀의 리더가 될 가능성이 크다.
    • 실수했다면 사과하기. 겸손 존중 신뢰!
  8. 마음 다스리기
    • 더 많은 사람을 이끌수록 감정은 억누르고 평정심을 유지해야 한다.
    • 상대를 진정시키고 문제를 해결하는데 집중하게 도와주는 효과가 있다.
    • ‘직접 해결하기’는 가장 마지막에 택해야하는 전략이다.
    • 조언을 청한 사람이 자기힘으로 문제를 해결하도록 도와주려 노력해야한다.
  9. 촉매자 되기
    • 팀 리더가 하는 일반적인 일은 합의를 이끌어내는것.
    • 비공식 리더가 진행하기도 하고, 빠른 진행을 원한다면 리더에게 전적으로 맡기기도한다. 이것도 팀이 자발적으로 정한것이라면 이역시 합의를 이끈것.
  10. 장애물 치우기
    • 많은 경우 정확한 답을 알고있기보다 올바른 사람을 알고있을때의 가치가 크다. 리더는 문제에 적합한 사람에게 연결 해주면 된다.
  11. 선생이자 멘토되기
    • 훌륭한 멘토라면 성장하는 팀에 발맞춰 멘티가 배우는데 쓰는 시간과 제품 개발에 기여하는 시간의 균형을 잘 잡아줘야한다.
  12. 명확한 목표 세우기
    • 목표가 명확하다면 우선순위를 명확히 설정하고, 구체적으로 무엇을 택하고 무엇을 버려야할지는 팀이 스스로 정하도록 적시에 도와야 한다.
  13. 정직하기
    • 거짓말대신 모른다고 하거나, 알아도 얘기해줄수없다 정도로 얘기해줄 수 있다.
    • 칭찬 샌드위치로 피드백을 주면 안된다. 핵심 피드백을 제대로 인지할 수 없기 때문 (칭찬 + 쓴소리 + 칭찬)
    • 기분상하지 않도록 명확한 피드백과 지시를 주자.
      • ex) 저는 홉씨가 자각하지 못하고 있다고 확신하는데, 홉씨의 행동은 다른 사람을 소외시키고 화나게 하는 경향이 있습니다. 그래서 제 팀의 일원으로써 더 효과적으로 일하려면 소통 기술을 개선해야할것같아요. 저와 다른 팀원들도 최선을 다해 도와드리겠습니다.
  14. 행복한지 확인하기
    • 면담의 마지막에 ‘뭐 필요한거 없어요?’ 라고 묻기. 항상 물어본다면 답을 준비해서 오는 팀원도 있을것.

      예상치 못한 질문

       - 팀원이 처한 상황을 인지하고 배려하기.
 - 경력관리를 챙겨주기위해, 고민하고있음을 팀원이 알게 해야한다. 막연한 목표를 구체적으로 명시하여 조언해야할 시점이 되었을때 평가할 지표가 되게 하라.
 - 행복도 추적은 팀원 스스로를 성장시킬 기회를 만들어주고, 하는 일을 인정해주고 그 여정에서 약간의 재미를 느끼게 해줘야한다. ## 그 외 조언과 요령
 - 위임하되, 곤란한 일은 직접 처리하자. 
   - 팀을 이끈지 제법 되었거나, 신생팀일때 존경을 이끌어내고 속도를 높이는 방법.
 - 여러분을 대신할 사람을 찾자.
 - 파도를 일으켜야할 타이밍을 알자.
   - 무시하고 지켜보는 어떤 상황이 오래되면 결국 안좋은 영향이 커진다. 빨리 조치를 취하자.
 - 혼란으로부터 팀을 보호하자.
   - 회사는 원래부터 혼란스러웠지만, 리더가 보호해주고있어서 팀원들은 모를뿐.
 - 팀에 공중엄호를 해주자.
   - 회사 위쪽에서 무슨일이 벌어지고 있는지를 팀이 알게해주는것도 물론 중요하다.
   - 팀에 실제로 영향을 줄 가능성이 거의 없는 조직차원의 광기로 업무가 방해받지않도록 지켜야한다.
 - 팀이 잘하고있다면 칭찬하자.
   - 기대이상으로 잘했다면 당사자와 팀원 전체에게 알려 칭찬하자.
 - 실패해도 쉽게 되돌릴 수 있는 일에는 '해보세요'
   - 리더는 실패해도 쉽게 돌릴수있는지 아닌지 판단할수있어야 한다. ## 사람은 식물과 같다.
 - 정체되어있는 팀원에게는 동기부여, 산만하거나 뭘해야할지 모르는 팀원에게는 강하게 지시해야한다. 과유불급! ### 내적동기와 외적동기
 - 사람을 생산적이게 만드는것은 금전적인 외적 동기보다 내적동기부여가 중요하다.
 - 내적 동기부여 방법
   - 자율성 : 스스로 행동할 수 있게 기회 제공
    • 제품과의 관계가 끈끈해지고, 주인의식이 커져, 성공시키려는 의지도 커질것. - 숙련(전문성) : ex) 배울 기회를 제공 - 목적 제공 : ex) 제품 피드백을 알려주어 동기부여