구글 엔지니어는 이렇게 일한다 - 5장, 6장, 7장

(책을 읽으며 느낀 개인적인 사견이 회색 글씨로 작성되어 있습니다.)

 

5장 팀 이끌기

어떤 팀도 리더 없이는 제대로 굴러갈 수 없습니다. 관리자는 사람을 이끌고 테크 리드는 기술과 관련한 책임을 집니다.

• 테크 리드 매니저
  • 관리자와 테크 리드 역할을 한 사람이 맡는 경우
• 엔지니어링 관리자
  • 자신이 관리하는 팀의 구성원 모두의 성과, 생산성, 행복과 제품의 사업적 요구 충족을 책임져야 함
• 테크 리드
  • 제품의 기술과 관련한 결정, 아키텍처, 우선순위, 성능 등 일반적인 프로젝트 관리 책임

5.2 개인 기여자에서 리더로

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

• 사람들이 관리자가 되기 싫어하는 이유 → 코딩할 시간 없어짐
• ‘코딩’은 작성한 코드, 설계 문서, 해결한 버그로 자신이 한 일의 총량을 입증할 수 있음
• 반면에 ‘관리’는 수량화하기 어려움
• 하지만 관리를 통해 팀에 활기를 불어넣고 생산성을 높일 수 있음
• 피터의 법칙
  • 주어진 위치에서 뛰어난 성과를 내는 직원은 승진을 거듭하다가 더는 성과를 낼 수 없는 위치까지 올라선 후 멈추게 되고, 결국 조직 전체가 무능한 사람들로 채워지는 역설적인 상황
  • 조직의 보상과 승진 제도가 적절한지, 나아가 의도대로 시행되고 있는지를 돌아보게 하는 이론
  • 승진 체계만을 이유로 직원을 억지로 관리자로 올리면 안된다

5.2.2 섬기는 리더십

• 겸손, 존중, 신뢰의 분위기를 조성하도록 힘쓸 것

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

관리자가 직원들을 신뢰한다는 분명한 신호를 주면 직원들은 신뢰에 부응해야 한다는 긍정적인 압박을 느낍니다.

→ 심리적 안전 조성

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

→ 마이크로 매니징 하지 않기

실패해도 괜찮지만 ‘팀으로서 함께’ 실패하고, 실패로부터 배워야 합니다. 한편, 특정 개인이 이룬 성취는 팀이 보는 앞에서 칭찬해주세요. 하지만 실패한 개인에게는 ‘개인적으로’ 따로 불러서 ‘건설적인’ 비판을 해주세요. 어떤 경우든 배울 기회로 삼고, 겸손 존중 신뢰라는 원칙 하에 행동하세요.

5.4 안티패턴

• 만만한 사람 고용하기 - 나(관리자)의 자리 보전을 위해 좌지우지할 수 있는 사람을 고용하기
  • 나보다 똑똑하고 나를 대체할 수 있는 역량을 갖춘 사람을 적극적으로 채용해야 함
• 저성과자 방치하기
  • 희망은 전략이 아니다.
  • 단기간의 겸손, 존중, 신뢰를 바탕으로하는 마이크로매니징으로 성장할 수 있도록 돕기
• 사람 문제 무시하기
  • ‘사람’으로서 사람의 문제에 공감해줄 것
• 만인의 친구 되기
  • 적당한 사회적 유대 관계를 유지할 것
• 채용 기준 타협하기
  • 적합하지 못한 사람을 채용하면 드는 막대한 피해를 생각해라..
• 팀을 어린이처럼 대하기
  • 마이크로매니징을 하거나 자신의 일에 책임질 기회를 주지 않으면 안 됨

5.5 올바른 패턴

• 자존심 버리기
  → 개인적으로 가장 경계하는 것 = ‘자만’하게 되는 것
  → 내가 가진 의견이 어떤 근거를 가지는 지, 어떤 점에서 확신을 가질 수 있었는지 생각해야 함
  → 다만 종종 의견을 제시할 때 자신감 없어 보인다는 피드백을 받기도 함, 겸손을 핑계로 하고있는 것은 않는지 생각해보기
• 겸손과 자신감 결여는 분명히 다릅니다. 자만에 차 있지 않더라도 자신감과 의견을 가질 수 있습니다.
• 마음 다스리기
• 촉매자 되기
• 장애물 치우기
• 선생이자 멘토 되기
  • 필요한 능력
    • 팀의 프로세스와 체계에 대한 경험
    • 다른 이에게 무언가를 설명해주는 능력
    • 멘티에게 도움이 얼마나 필요한지 측정하는 능력 → 정보가 과하면 다 흡수하지 못함
• 명확한 목표 세우기
• 정직하기
  • 칭찬 샌드위치가 아닌 직접적인 피드백, 비판을 전달해야 함(with 친절 & 공감 & 따뜻)
  • 전달 하고자 하는 피드백을 왜곡없이 정확하게 전달하는 것이 핵심
• 행복한지 확인하기

5.7 그 외 조언과 요령

• 위임하되, 곤란한 일은 직접 처리하자
• 여러분을 대신할 사람을 찾자
• 파도를 일으켜야 할 타이밍을 알자
  • 문제 상황에서 결단력 있게 적절한 타이밍에 조치를 취해야 함
• 혼란으로부터 팀을 보호하자
  • 회사 위쪽에서 무슨 일이 벌어지고 있는지 알게 해주는 것
  • 수 많은 불확실성과 팀 외부의 시시콜콜한 요구를 막아주는 일도 중요팀에 공중 엄호를 해주자
• 팀이 잘하고 있다면 칭찬하자
• 실패해도 쉽게 되돌릴 수 있는 일에는 ‘해보세요’라고 말하자

5.8.1 내적동기와 외적동기

• 내적 동기 부여 방법
  • 자율성(주도성)
    • 마이크로매니징 없이 스스로 행동할 수 있는 것
    • 주인의식 성장
  • 숙련
    • 현재 기술 수준을 높이고 새로운 것을 배울 기회를 제공하는 것
  • 목적
    • 자신이 하는 일의 목적을 인식 → 적극적이고 생산적으로 변화 가능

---

6장 성장하는 조직 이끌기

• 3A 리더십
  • 눈가리개 찾기
    • 늘 결정하라 - Always Be Deciding
      • 최선의 답 결정하기 - 어떤 상황에서든 옳은 답은 없다
        → 현재 우리 상황을 고려하여 오버엔지니어링하진 않는 지 생각해볼 필요가 있다
    • 늘 떠나라 - Always Be Leaving
      • 리더는 모호한 문제를 풀어줄 뿐 아니라 맡은 조직이 여러분 없이도 ‘스스로’ 문제를 풀 수 있게 유도해야 한다는 것입니다. 그럴 수만 있다면 여러분은 새로운 문제 혹은 새로운 조직을 찾아 떠날 수 있게 됩니다. 여러분 덕분에 스스로 자생력을 갖추게 된 팀을 남겨두고 말이죠.
    • 늘 확장하라 - Always Be Scaling 
      • 정말 중요한 일만 처리하기
      • 에너지 관리하기
        → 개인적으로 중요하게 생각하는 것 중에 하나.
        → 내가 좋아하는 일을 오래 함께하기 위해서는 적당한 거리를 유지할 필요가 있다고 생각
  • 가장 값진 자원은 ‘자신의 제한된 시간, 집중력, 에너지’

---

7장 엔지니어링 생산성 측정하기

7.1 엔지니어링 생산성을 측정하는 이유

• 사업이 번창 → 사업 확장 → 충원 필요 → 소통 비용 급등
• 이 때, 조직 내 엔지니어들 각자의 생산성을 높인다면 소통 비용 증가를 억제하면서 사업 확장 가능
• 생산성을 늘리기 위해 무엇이 필요한지 이해하고, 회사의 엔지니어링 프로세스에서 비효율적인 부분을 찾아 개선

7.2 선별: 측정할 가치가 있는가?

• 해당 지표가 측정할 가치가 있는 지 알아보는 작업
• 생산성 측정을 해도 될지 판단하는 질문 목록
  • 어떤 결과를 기대하고, 왜 그런가?
  • 데이터가 기대한 결과를 뒷받침한다면 어떤 조치를 취하겠는가?
    • 측정 결과에 상관 없이 아무런 조치를 취하지 않을 거라면 측정이 무의미해짐
  • 부정적인 결과가 나온다면 적절한 조치를 취할 것인가?
  • 결과에 따른 조치는 누가 결정하고, 언제 수행하는가?
• 측정하지 말아야 될 경우
  • 당장 프로세스/도구를 변경 할 여유가 없다.
  • 어떤 결과가 나오든 곧 다른 요인에 의해 의미가 없어질 것이다.
  • 측정 결과를 이미 확정 된 계획을 뒷받침하는 용도로만 쓴다.
  • 측정 할 수 있는 지표들이 문제를 평가하기에 충분히 정확하지 않으며, 다른 요인들 때문에 혼탁해질 우려가 크다.

7.3 GSM 프레임워크

→ 측정을 결정했을 때, 지표를 선정하는 방식

• Goal (목표)
  • 원하는 최종 결과를 고차원 어휘로 표현한다.
• Signal (신호)
  • 최종 결과를 이뤘는지 판단하는 방법
• Metric (지표)
  • 실제로 측정하는 대상

7.4 목표

• 퀀츠(QUANTS) - 엔지니어링 생산성을 구성하는 다섯가지 요소
  • 코드 품질 (Quality of the code)
  • 엔지니어들의 몰입도 (Attention from engineers)
  • 지적 복잡성 (Intellectual complexity)
  • 박자와 속도 (Tempo and velocity)
  • 만족도 (Satisfaction)

→ ‘측정’을 하기 위해서는 프로세스를 측정하고, 얻은 데이터를 분석하고, 분석 결과를 회사 전체에 공유해 알리는 사람 필요

→ 측정 할 가치를 잘 따져보고, 당연하거나 가능성이 없는 것에 ‘측정’ 이라는 리소스를 허비하지 않도록 하기