안녕하세요, 오늘부터 매니저입니다를 읽고서

한줄평

매니지먼트란 대체 무엇일까? 읽고 나면 더욱 깊어지는 고민들

 

목차

Chapter 1 소개
Chapter 2 조직
팀 규모 정하기
성과가 좋은 팀을 만드는 데 주력하자
하향식 글로벌 최적화에 대한 사례
초급성장 시대의 생산성
조직의 위험을 어디에 숨길 수 있을까?
인계를 위한 계획

Chapter 3 도구
시스템적 사고
제품 관리 - 파악, 선택, 검증
비전과 전략
지표와 기준치
지표를 이용해 광범위한 조직적 변화를 유도하기
마이그레이션 - 기술 부채를 해결하는 확장 가능한 유일한 방법
엔지니어링 조직의 개편
통제할 수 있는 부분 찾기
경력 기술서
미디어를 통한 간단한 학습
모델, 문서 그리고 공유
일관성의 확장 - 중앙식 의사 결정 그룹의 설계
시니어 리더를 위한 발표
시간 관리
학습 커뮤니티

Chapter 4 접근법
예외가 아닌 정책에 따라 일하기
의견에 반대하기
여러분의 관리 철학
성장하는 회사에서의 관리직
엔지니어링 관리자가 난관에 부딪히는 이유
관리자와 협업하기
관리의 범위
조직의 방향 설정
종료하거나 해결하거나 위임하거나

Chapter 5 문화
기회와 유대감
프로젝트 리더를 선택하는 방법
동료를 최우선 팀으로 대하자
시니어 직책을 위한 팀 고려하기
기업 문화와 자율성의 관리
영웅 놀이 하지 말기, 어렵게 일하지 말기

Chapter 6 경력
초고속 성장 중의 역할 그리고 초고속 성장이 개인의 성장을 대변
하지 못하는 이유
배려 깊은 면접 절차의 운영
콜드 소싱 - 전혀 모르는 사람을 채용하기
채용 깔때기
성과 관리 시스템
경력 수준, 성과 지정 모멘텀, 레벨 분리 외 기타
SRE나 TPM 같은 특별한 역할의 정의
면접 루프의 설계

Chapter 7 부록
성장하는 조직을 운영하기 위한 도구들
유용한 참고 도서
유용한 논문

 

안녕하세요, 오늘부터 매니저입니다 - 예스24

매니저가 되고 싶은 사람을 위한 안내서

매니저를 목표로 준비하는 사람을 위한 책이기도 하지만 이미 매니저이지만 더 나은 매니저가 되기 위한 사람들에게도 도움이 될 것이라고 생각한다. 매니저는 팀을 위한 계획을 세우고 팀원들을 이끌고 목표를 달성하기 위해서 노력하는 사람이라고 생각한다. 새로운 관점에서 팀을 바라보도록 해보자.

 

조직이란 공동의 목표를 위해 일하는 사람들의 집합이다. 각 조직은 수십, 수백 혹은 수천 명이 함께 가능성을 탐구하는 곳이다. 처음에는 제대로 기능하는 조직은 얼마 없다고 쓰고 싶었지만 놀랍게도 모든 조직은 제대로 작동한다.

 

큰 부담 없이 빠르게 해결하고 싶은 문제가 생기면 프로세스의 설계에 대해 생각하는 것부터 시작한다. 이 문제가 영구적으로 해결하고 싶은 문제이고 천천히 해결할 시간이 충분히 있는가? 그렇다면 문화를 개선하기에 적합한 시점이다. 

 

(4인 이하의) 작은 팀은 팀이 아니다

필자는 한두 명으로 구성된 팀의 스폰서를 맡은 적이 있었는데 그때마다 후회했다. 정말 매번 후회를 했다. 팀의 속성에서 중요한 점은 팀을 구성하는 개인의 복잡한 상황을 추상화한다는 것이다. 하지만 4명 이하의 팀은 이런 기능을 지원하지 못하고 마치 개인인 것처럼 작동한다. 소규모 팀의 성과를 유추하려면 긴급 대응 교대, 휴가, 방해 요소 등을 모두 알아야 한다.

 

• 정상적인 상태의 팀은 6~8명 규모여야 한다.
• 새로운 팀을 구성하려면 기존 팀의 규모가 8~10명 정도로 성장해야 하고, 그럴 경우 4~5명 규모의 2개 팀으로 나눌 수 있다.
• 팀원이 없는 팀은 절대 편성하지 말자.
• 관리자가 8명이 넘는 엔지니어들을 관리하게 하지 말자.

 

성과가 좋은 팀을 만드는데 주력하자

팀의 네 가지 상태

• 뒤쳐지는 상태 - 충원
• 업무가 벅찬 상태 - 진행 중인 업무량 감소
• 기술 부채를 해결 중인 상태 - 충분한 시간 부여
• 혁신을 진행 중인 상태 - 여유 부여

 

역량을 한곳에 집중하자. 조직의 리더로서 여러분은 각각 다른 상태에 놓은 여러 팀과 협업하게 될 것이다. 또한 적용할 수 있는 리소스에도 제한이 있으며, 보통 모든 팀의 상태를 동시적으로 개선하기에는 충분하지 않을 것이다. 많은 사람이 제한된 리소스를 여기저기 투입하면서 모든 팀을 동시에 개선하려 하지만 우유부단함을 형평성으로 포장하진 말자. 누구도 얻는 것이 없다면 이를 공평한 결과라고 말할 수 없다.

 

팀 우선

기본적으로 필자는 지속적인 생산성은 성과가 높은 팀으로부터 나오며 성과가 높은 팀을 해체하는 것은 설령 팀원 전체가 남아 있다 하더라도 생산성에 심각한 손실로 이어진다고 믿는다. 이 세계관에서는 성과가 높은 팀은 불가침이므로 필자는 이런 팀을 해체할 생각이 없다.

 

팀 전체가 손발이 맞기까지는 상당한 시간이 걸린다. 어떤 그룹이 몇 년간 함께 일을 하다 보면 서로를 이해하고 굉장히 놀라운 방법으로 협업해 성공을 만들어내는 법을 알게 된다. 그래서 팀원 중 누군가를 다른 팀으로 옮기면, 특히 팀이 이제 막 결성되었고 팀 문화에 큰 차이가 있는 경우 다시 손발 맞출 시간이 필요하게 된다. 

 

교대를 통해 업무의 범위를 옮기자

팀 자체는 유지하되, 팀 간에 범위를 옮기는 것이 가장 효율적이라는 점을 깨달았다. 사람을 옮기는 것보다 업무 범위를 바꿔주는 편이 더 나은 이유는 팀이 다시 결속하는 데 비용이 들지 않고 시스템 동작도 유지할 수 있기 때문이다.

 

엔지니어가 많아지면 문제도 많아진다

수많은 엔지니어의 생산성을 유지하는 것은 어려운 일이다. 우리는 채용 시에 단순히 채용만을 생각하지만 채용 이후에 더 큰 산들이 우리를 기다리고 있다.

 

1. 엔지니어가 늘어날 때마다 새로운 관리 계층을 설계하고 유지해야 한다.
2. 엔지니어가 10명 늘어날 때마다 새로운 팀을 구성해야 하며 그러려면 더 많은 조정이 필요하다.
3. 엔지니어가 매일 더 많은 커밋과 배포를 수행하게 되므로 개발 도구에 부하가 더해진다.
4. 대부분의 장애는 배포 때문에 발생하므로 배포 횟수가 늘어나면 장애 횟수도 늘어나게 되어 장애 관리, 완화 및 회고에 더 많은 시간을 사용하게 된다.
5. 엔지니어의 수가 늘어나면 그에 따라 목적에 특화된 팀과 시스템이 늘어난다. 그러면 긴급 대응 교대 업무가 늘어나서 긴급 대응 엔지니어가 프로덕션 이슈를 디버깅하고 해결하는 데 필요한 충분한 시스템 콘텍스트를 갖추게 된다. 그 결과 긴급 대응에 투자해야 하는 시간이 상대적으로 늘어난다.

 

시스템적 사고

함께 일했던 유능한 리더들은 영향도가 높은 문제를 다루는 놀라운 재주를 가지고 있었다. 일부 문제 영역에서 제품 관리 스킬이 유용한 문제를 판단하는 데 매우 효과적이긴 하지만, 필자의 생각에 전반적으로 가장 유용한 도구는 '시스템적 사고(systems thinking)'아.

 

시스템적 사고에 대한 기초를 탄탄하게 다지고 싶다면 「Thinking in Systems: A Primer」를 읽어보는 것을 추천한다.

ESG와 세상을 읽는 시스템 법칙 - 예스24

시스템적 사고의 유용성에 대한 예시를 생각하다가 바로 한 가지가 떠올랐다. 

디지털 트랜스포메이션 엔진 - 예스24

 

「디지털 트랜스포메이션 엔진」을 읽은 후로 속도에 대해 저자가 내린 정의를 오랜 시간 고민했다. 이 책에서는 개발자의 속도를 네 가지로 측정한다.

 

1. 전달에 이르는 시간(delivery lead time)
2. 배포 빈도(deployment frequency)
3. 변화 실패율(change fail rate)
4. 서비스 복구 시간(time to resore service)

어떻게 개발자 생산성을 유추할 수 있는 시스템으로 모델링할 수 있는지 한번 살펴보자.

 

• 풀 리퀘스트(pull request)는 코드 리뷰 비율에 따라 준비된 커밋(ready commits)으로 전환된다.
• 준비된 커밋은 배포 비율에 따라 배포된 커밋(deployed commits)으로 전환된다.
• 배포된 커밋은 결함 비율에 따라 장애(incidents)로 전환된다.
• 장애는 복구 비율에 따라 취소된 커밋(reverted commits)으로 전환된다.
• 취소된 커밋은 디버그 비율에 따라 디버깅 후 새로운 풀 리퀘스트로 전환된다.

 

비전과 전략

'전략(strategies)'은 문제를 해결하기 위한 트레이드오프와 조치를 설명하는 근거 있는 문서를 말한다.

'비전(vision)'은 서로 협업하지 않는 사람들이 서로 잘 맞는 결정을 내릴 수 있도록 도움을 주는 문서이다.

 

 

발표를 통한 학습

발표를 통해서 5분 정도의 짧은 학습이 머릿속에 각인되어 스스로 반복할 수 있게 된다.

 

발표에 대한 세 가지 규칙을 살펴보자.

1. 질문에 대해서 답하기 편한 형태로 질문을 재구성하자.
   모호한 질문을 그대로 받지 말고 스스로 그 질문을 재구성해보자. '코끼리는 생각하지 마'는 이슈를 재구성하는데 간결하면서도 감탄스러운 가이드를 제공한다.
2. 긍정적인 태도를 갖자.
3. 세 가지 키워드로 요약해서 발표하자.

 

코끼리는 생각하지 마 - 예스24

 

효과적인 리더십 시나리오

기존의 하향식 전달방법과 저자가 이야기하는 모델, 문서, 공유에 대해서 비교해 보자

• 모델 : 변화를 이끌어내기 전에 팀의 상황에 대해서 파악한다.
• 문서 : 해결해야 할 문제점, 학습과정, 다른 팀은 어떻게 도입했는지 등을 상세히 문서화한다.
• 공유 : 간단한 이메일로 문서화한 방법을 공유한다. 그냥 방법과 여러분이 이 방법을 따른 경험만을 제시한다.

 

하향식 전달은 괜찮은 방법을 빠르게 적용한다.

• 팀이 새 방식에 적응할 만한 여력이 있다.
• 조직이 롤아웃을 조율할 리소스를 확보하고 있다.
• 이 주제에 대한 의사 결정을 중앙식으로 처리하고 싶다.
• 일관성을 갖고 모든 팀이 어떤 문제에 대해서 같은 방식으로 대해야 한다.
• 변화를 빨리 이끌어내는 것이 중요하다.

 

모델, 문서, 공유는 훌륭한 방법을 천천히 도입한다.

• 팀이 새로운 방식에 적응할 여력이 없다.
• 조직이 롤아웃을 조율할 충분한 리소스가 없다.
• 이 주제에 대한 의사 결정을 분권화하고 싶다.
• 팀은 스스로 적절한 절차에 적응할 수 있다.
• 변화를 점진적으로 이끌어내고 싶다.

 

시니어 리더를 대상으로 하는 발표

시니어 리더를 대상으로 발표를 진행하는 것은 어려운 일이다. 익숙해지기까지 시간도 걸릴뿐더러 이 일을 잘하는 대부분의 사람들도 어떻게 그렇게 잘하게 되었는지 제대로 설명하지 못한다. 게다가 이 일을 잘하는 사람들은 카리스마, 순발력, 전문 지식 또는 수년간의 경험 등 쉽게 흉내 낼 수 없는 자신만의 장점을 활용하고 있다.

 

시니어 리더를 대상으로 발표할 때의 아래의 몇 가지 팁을 제시하고자 한다.

• 의사소통 방식은 회사마다 다르다.
• 결론부터 시작하자.
• 주제가 중요한 이유를 만들자.
• 다른 질문에 대비하자.
• 준비는 많이, 연습은 조금만 하자.
• 질문은 분명하게 하자.
• 데이터 중심의 진단
• 의사 결정 원칙들

 

시간 관리

시간 관리는 리더가 안고 있는 지속적인 문제다. 시간을 관리하는 방식을 바꿔보면서 가장 효과가 좋았던 건 다음과 같다.

 

• 분기별로 시간을 회고한다.
• 단기적 품질보다는 장기적인 성공을 우선한다.
• 작고 영향력 있는 일부터 끝낸다.
• 업무를 그만 맡는다.
• 규모를 늘리지 않고 줄인다.
• '체제'에 따르는 업무를 위임한다.
• 여러분이 구축한 체제를 믿는다.
• 생산성과 첨여도를 구분한다.
• 성장 속도보다 약간 빠르게 채용한다.
• 일정에 시간을 확보한다.
• 관리 부서의 지원을 얻는다.

 

지속 가능한 학습 커뮤니티

동료들과 함께 학습해 나가는 커뮤니티는 유대감이 형성된 가운데서 특히 더 잘 동작한다.

 

• 가르치는 사람이 아니라 조력자가 되자.
• 발표는 간단히, 논의는 길게 하자.
• 작은 그룹으로 분리하자.
• 학습 내용을 전체 그룹과 공유한다.
• 사람들이 이미 알고 있는 주제를 선택한다.
• 재직 기간이 긴 사람들의 참석을 유도한다.
• 사전 자료를 미리 제공한다.
• 시작 전에 자기소개를 하자.

 

여러분의 관리 철학

내가 관리직을 시작했을 때의 리더십 철학은 간단했다.

 

• 골든 룰(golden rule)을 따르는 것이 맞다.
• 모두에게 각자 '주인 의식'을 가지고 책임질 부분을 정해주자.
• 보상과 지위는 높은 품질의 작업을 완수해야 얻을 수 있다.
• 솔선수범하고 내가 하고 싶지 않은 일을 남에게 부탁하지 말자.

이 철학은 든든한 기초가 되어주긴 했지만 오랜 시간 여러 상황에 반복해서 적용하다 보니 갈수록 예외 사황이 발생했다. 계속 배워나가기 위해 해당 주제를 연구하면서 몇 가지 아이디어를 더하기 시작했다.

 

• 윤리적 직업
• 문제보다는 끈끈한 관계가 중요하다.
• 절차보다는 사람을 우선하자.
• 어려운 일은 지금 하자.
• 회사, 팀 그리고 본인
• 본인을 위한 고민

 

엔지니어링 관리자가 난관에 부딪히는 이유

새로운 팀장이 된다면 처음 몇 년 안에 다음과 같은 이유로 난관에 부딪힐 수 있다..

 

• 아랫사람만 관리한다.
• 위사람만 관리한다.
• 윗사람을 전혀 신경 쓰지 않는다.
• 팀만을 위한 최적화를 수행한다.(부분 최적화)
• 채용으로는 어떤 문제도 해결할 수 없다고 가정한다.
• 관계 형성에 소홀하다.
• 자신의 역할을 너무 좁게 해석한다.
• 윗사람도 사람이라는 사실을 잊는다.

더 경험이 있는 관리자라면 다음과 같은 이유로 난관에 봉착한다.

 

• 이전 회사의 경험에 의존한다.
• 관계 형성에 너무 많은 시간을 소비한다.
• 모든 문제를 채용으로 해결하려 한다.
• 책임을 위임하는 것이 아니라 피한다.
• 실질적인 정보와 단절된다.

그 이외의 관리자들이 난관에 부딪히는 경우는 다음과 같다.

 

• 영향력을 위해 팀의 규모를 잘못 조정한다.
• 영향력을 위해 잘못된 직책을 택한다.
• 권한과 진실을 혼동한다.
• 책임을 위임할 만큼 팀을 믿지 않는다.
• 시간 관리를 스스로 하지 못한다.
• 문제만 바라본다.

 

영웅 놀이 하지 말기, 어렵게 일하지 말기

'열심히 일하자'라는 주문은 평범한 직원들이 의미 있는 기여를 하기에는 어려운 방식으로 일을 처리하는 영웅 프로그래머만 키워낼 뿐이다. 나중에 새로 합류한 영웅들이 번아웃에 시달리게 되면 다음과 같은 굉장히 어려운 세 가지 문제에 봉착하게 된다.

 

• 뛰어나지만 불만에 가득하고 지친 영웅 프로그래머를 키워냈다.
• 여러분과 영웅 프로그래머가 나머지를 모두 소외시켰다.
• 프로젝트는 여전히 완전히 망가진 채다.

이는 성장하는 기업의 대다수가 겪는 반복적인 패턴이며 대기업의 프로젝트에서도 발생하는 현상이다. 팀은 열심히 일하고 경영상 절박한 곳이라면 '열심히 일하라'는 압박은 언제든 발생할 수 있다.

 

대부분은 더 이상 어떻게 프로젝트에 기여해야 할지 몰랐다. 그 이유는 여러분과 영웅 동료가 기존 시스템을 다시 작성했고 장애를 디버깅했으며, 쉬운 방법만을 골라 사용했기 때문이다. 그러면 나머지 사람들은 뭘 해야 할까?

 

하루가 지나고 한 주가 지날수록 영웅과 그렇지 않은 사람 사이의 갈등은 커져만 가고 피할 수 없는 재앙으로 치닫게 된다.

 

프로젝트는 언제든 실패하고 사람들은 항상 실수를 한다. 보통은 실수를 인정하지 않기 때문에 상황이 더 악화된다. 우리가 실수를 빨리 인정하고 너무 힘들어지기 전에 나쁜 결정으로 인한 손실을 줄인다면 실수로부터 배우고 개선할 수 있다.

 

영웅을 없애고 더 열심히 일하는 것을 그만두자. 실수에 갇히지 말고 실수로부터 배우고 나아가자.

 

콜드 소싱 - 전혀 모르는 사람을 채용하기

면접 대상자를 확보하는 가장 큰 세 가지 방법으로는 기존 팀의 추천, 채용 페이지를 통해 지원한 응시자 그리고 여러분이 직접 채용에 참여시키는 섭외 등이 있다.

 

소규모 기업은 주로 추천에 의존하는 경향이 있고 대기업은 전담 채용 담당자들이 섭외하는 방법을 주로 사용하며 중간 규모 회사들은 두 가지 방법을 모두 사용한다.

 

콜드 소싱을 처음 시도하는 방법

• 링크드인에 가입한다.
• 실제로 아는 사람을 팔로우해서 인맥을 구축해 나간다.
• 인내심을 갖고 기다린다.
• 인맥에 추가할 2차 인맥을 찾는다.
• 연결 요청을 수락한 사람의 프로필을 보고 정중한 메모를 보내 커피나 전화 통화를 요청한다. 채용하는 업무에 대해 설명하는 문서가 담긴 링크를 첨부하자.
• 당장은 함께할 수 없더라도 내년이나 다음에 이직하면 함께 일할 수 있는 사람이라는 점을 기억하자. 인력풀에 추가하자.

채용 파이프라인을 구성하는 단계들

 

정리하면서

책에서 다루는 내용들은 관리자라면 한 번쯤 고민해 봤을 내용들을 두루두루 다루고 있어서 도움이 되었다. 관리자를 경험해 본 적은 없지만 '나라면 어떻게 생각하고 고민했을까'에 대해서 책을 읽는 내내 생각하게 만들었다. 하지만 아쉽게도 책의 전반적인 번역의 상태가 고르지 못하고 문장의 의미가 이해되지 않는 비문들이 있어 이해하는데 쉽지 않았다.

 

관리자들이 고민하는 내용들에 대해서 아이디어를 얻어가는 정도로 가볍게 접근하기에 좋은 책이라는 생각이 든다. 그리고 중간에 언급되는 책들이 하나같은 좋은 책들이라는 생각이 들어서 참고해 볼 예정이다.

 

 

본 리뷰는 업체로부터 도서를 제공받아 읽어보고 객관적으로 작성한 리뷰입니다.