개발 7년차, 매니저 1일차

저자 : 카미유 푸르니에

2장 멘토링 중에서

멘토는 복잡한 설명을 몇 번이나 다른 방법으로 말할 수 있어야 한다. 멘티의 질문이 이해되지 않으면 다른 방식으로 거듭 질문을 한다. 필요하면 사무실 한 구석에 있는 화이트보드에 다이어그램을 그린다. 다시 말해서 멘티가 이해할 때까지 시간을 쓰는 것이다. 기억하자. 멘티의 눈에는 멘토가 큰 힘이 있는 위치의 사람이다. 멘티는 힘들게 잡은 기회를 망칠까 봐 또는 멘토를 기쁘게 해야 한다는 생각에서 멍청하게 보이지 않으려 노력하기 때문에 긴장한다. 그래서 이해하지 못해도 질문하지 않을 수 있다. 따라서 편안한 마음으로 멘티의 질문을 들어라. 멘토가 질문에 답을 하기 위해 많은 시간을 쓰는 확률보다 멘티가 충분히 질문하지 않아 일이 전혀 다른 방향으로 잘못 진행될 가능성이 더 높다.

3장 테크리드 중에서

궁극적으로 '계획의 가치'는 계획을 얼마나 완벽하게 수행하는지, 사전에 모든 세부사항을 미리 파악했는지, 장차 벌어질 일을 예측하는지에 있지 않다. '계획의 가치'는 실제 업무를 시작하기 전에 스스로 프로젝트를 어느 정도까지 깊이 있게 생각할 수 있는지에 있다. 계획을 세우는 데 있어서 어느 선까지 합리적으로 예측하고 계획을 수립하는지가 목표이지, 계획이 얼마나 정확한지에 대해서는 많은 시간을 쓸 만큼 중요하지 않다.

4장 사람 관리 중에서

신뢰(trust)할 것인가 통제(control)할 것인가는 마이크로매니저에게 중요한 문제다. 업무가 제대로 처리될 거라 믿지 못하거나 당신이 저한 기준으로 결과물을 엄격하게 통제하려 할 때 마이크로매니지먼트를 하게 된다. 이런 상황은 뛰어난 개발자가 특히, 기술적으로 자부심이 강한 개발자가 팀장이 될 때 자주 일어난다. 팀에서 당신의 가치가 당신이 잘하는 코딩에서 아직 잘 모르는 사람관리로 바뀌었다면, 팀원들을 자신의 분신처럼 다루고 싶을 수도 있다. 불가피하게 마감 기한을 맞추지 못하면 상황을 제대로 통제하지 못하는 것으로 보고 더 신경 쓰게 된다. 기대와 달리 프로젝트가 잘 진행되지 않는다 생각하게 되고 팀을 마이크로매니지먼트하는 것이 적절한 선택이라는 믿음을 갖게 된다.

자율성(autonomy)은 팀원이 자신의 업무 중 일부를 직접 통제할 수 있는지를 의미하며 동기 부여의 중요한 요소다. 마이크로매니지먼트로 팀을 잘 운영하기 어려운 이유는 바로 자율성 때문이다. 창의적이고 재능 있는 사람이 자율성을 빼앗기면 즉시 동기도 사라진다. 스스로 어떤 결정도 내릴 수 없고, 모든 업무를 매니저가 이중, 삼중으로 확인한다고 느끼게 하는 것만큼 최악은 없다.

반면, 위임은 포기가 아니다. 책임을 위임하더라도 프로젝트가 성공하도록 도와야 한다. 

7장 매니저 관리 중에서

과로는 종종 신입 매니저가 위험하다는 신호이기도 하다. 자신이 통제광, 팀에 일을 시키는 사람이라고 생각하는 매니저는 모든 결정을 자신이 내리려고 한다. 업무에 소홀한 매니저도 나쁘지만, 때로는 권력을 행사하고 싶어서 열심히 일하는 매니저가 더 나쁘다. 팀에 권력을 과시하고 싶어 하는 매니저는 팀이 자신보다 직급이 높은 사람과 스킵 레벨 미팅을 진행할 때 좌절한다. 자신이 힘을 행사할 수 없기 때문이다. 항상 모든 팀원에게서 상세한 보고를 받으려고 하는 마이크로매니저와 비슷하지만 살짝 다르다. 마이크로매니저는 불필요한 세부사항을 요구하기 때문에 팀을 극도로 짜증 나게 만든다. 통제광은 팀 스스로 결정할 수 있는 능력을 빼앗고 직원에게 업무를 할당하는 일이 자기 일이라고 생각한다. 통제광은 협업하기보다 혼자 결정하겠다고 자주 싸우기 때문에, 일반적으로 제품 관리 팀과 다른 기술 팀 동료들과 사이가 좋지 않다. 심지어 통제권을 빼앗길까 염려해 매니저에게 본인이 하는 일을 숨기고 싶어 한다. 새로 온 매니저가 원온원 미팅을 건너뛰거나 팀이 무엇을 하는지 물어볼 때 답을 피한다면, 그 신입 매니저는 통제광일 가능성이 높다.

---

마지막으로, 새 매니저를 채용하는 데 빠뜨릴 수 없는 한 가지 요소가 또 있다. 바로 레퍼런스 체크다. 면접자와 일을 함께 해보았더라도, 채용하는 모든 사람에 대하여 레퍼런스 체크를 하라. 그 사람이 성공하는 방법과 실패하는 방법을 모두 설명해 달라고 하자. 그 사람과 다시 일하고 싶은지 물어보자. 면접자에 대한 어떤 부분을 좋아하고, 어떤 부분이 관계를 힘들게 만드는지 물어보라. 매니저를 채용할 때 레퍼런스 체크를 하지 않는다면, 팀에 큰 민폐가 될 수 있다. 레퍼런스 체크를 하면, 면접자가 신중하게 선택한 사람이라 할지라도 그 면접자를 채용했을 때 어떤 상황이 발생할 수 있는지 알게 되는 경우가 많으므로 레퍼런스 체크를 절대 빠뜨리지 말자.

8장 빅 리그 중에서

이 이야기에서 알 수 있듯이 좋은 기술 전략이란 여러 가지를 의미했다. 기술 전략은 기술 아키텍처를 의미했고, 팀 구조를 의미했고, 비즈니스의 기초와 방향을 이해하는 것을 의미했다. 제품 중심의 회사 기술 전략은 '미래의 많은 잠재 비즈니스를 가능하게 만드는 것'이라고 설명하고 싶다. 그저 현재 문제를 설명하려고 노력한 문서가 아니다. 미래의 성장을 예측하고 가능하게 하는 계획서다. 당신이 제품 중심 비즈니스에서 일하고 있다면, 기술 전략의 핵심은 실제로 제품 방향을 결정하는 것이 아니라 성공적으로 실행하기 위한 더 큰 로드맵을 활성화하는 것이다.

9장 문화 개선 중에서

당신 회사는 소수의 아주 단순한 시스템으로 시작했다. 사람들이 합류하고 정책과 인프라가 추가되면서 복잡한 시스템으로 발전했다. 팀 규모가 작고 잘 동작하고 있을 때, 조직 구조와 프로세스를 과도하게 설계하는 것은 큰 이점이 없다. 하지만 어느 시점이 되면 실패를 경험하게 되고, 실패가 발생했을 때가 조직 구조를 어떻게 바꿔야 할지 조사하고 파악하기 가장 좋은 시점이다. 경력 경로 제도를 만드는 예를 들어보면 직원 한명이 경력 제도가 없다는 이유로 회사를 그만둔다고 해서 제도를 만들 수는 없다. 하지만 여러 직원이 그만두게 되거나 새로운 직원을 받지 못한다면 경력 경로 제도를 다시 고려해야 한다. 계속 근무했으면 하는 직원들이 퇴사하는 것과 현재 구조를 그대로 유지할 때의 팀이 얻는 가치를 따져야 한다.

---

읽은 거리는 많으나 TMI가 느껴진다.

스타트업 부터 많은 인원으로 구성된 조직을 운영해 본 저자의 많은 노하우가 담겨 있다. 내용은 구체적이고 풍부하며 실행적이다. 단원별 주제에 부합되는 실제 사례들과 저자의 실패 경험담을 통해 시행착오를 줄여주고자 노력한다. 실제 고민 중인 시니어 개발자, 신입 매니저, 중견 매니저들에게 도움이 될 많은 내용이 있으며, 인사이트를 제공할 수 있어 보인다.

책의 두께만 보고 만만하게 여겼는데, 내용이 빼곡하여 읽는 시간이 꽤 많이 걸렸다. 저자는 정말 하고 싶은 얘기가 많았나 보다. 4백 페이지 가깝기도 하고 여백 없이 꽉 찬 내용 때문에, 중간에 잠깐 포기할 뻔 했다. 너무 많은 얘기를 하고 싶어서 정작 하고 싶은 얘기가 보이지 않는다.

누군가 매니저로 첫 발을 내딛는 중이라면, 특히나 개발자에서 매니저로, 무겁지만 업계 선배의 잔소리를 경청해 보는 것도 괜찮아 보인다.