[BOOK] 개발 7년차, 매니저 1일차

[BOOK] 개발 7년차, 매니저 1일차 – 카미유 푸르니에 지음 / 권원상, 한민주 옮김

부제: “개발만 해왔던 내가, 어느 날 갑자기 ‘팀’을 맡았다!”

 알파 긱(Alpha geek)은 팀에서 인정받는 최고의 개발자로, 늘 정답을 말하며 어떤 어려운 문제도 풀어내는 사람이다. 지적이고 기술력에 최고의 가치를 두며, 실력이 의사결정에 영향을 미쳐야 한다고 믿는다. (중략) 이들은 뭐든 뛰어나야 하는 ‘탁월함의 문화’를 만들려고 하지만 결국에는 ‘두려움의 문화’를 만드는 경향이 있다. (p. 49)

대부분 관리를 맡게 되는 방식은 비슷할 것이다. 개발자들 중에 가장 연차가 높아서? 개발자들 중에 가장 커뮤니케이션을 잘 해서?
처음에는 후배를 가르치고, 작은 프로젝트에서 한두명의 개발자를 리딩하다가 팀을 맡게 되어 팀장이 된다.
팀장은 무엇을 해야하는지 체계적으로 교육시켜주는 회사는 드문 것 같다. 그저 경험해왔던 팀장들 중에 이런 점은 본받고, 저런 점은 멀리해야지를 생각하는 정도?
첫 팀장을 맡았을 때 이 책이 있었으면 좋았을 것 같다. 지금 시도중인 방법이 맞는지 늘 고민하게 되는데 책에서 가장 기본적인 것들을 소개해준다.

나는 프로젝트 매니저 채용을 좋아하지 않는다. 개발자가 앞으로의 일을 생각하고 현재 무엇을 하고 왜 하는지 자신들이 왜 여기에 있는지 진정으로 질문하고 배우게 하기 보다는 프로젝트 매니저에게 지나치게 의지하게 만들기 때문이다. (p. 73)

후배 한명을 맡은 사수부터 회사 전체의 개발을 맡게되는 CTO까지 어떠한 것을 생각해야하는지 잘 정리되어 있다.

경영층이 개발 팀에게 요구하는 사항과 개발팀의 현실을 조율하고, 소프트웨어 사용자의 목소리를 경청하고, 채용과 비용 절감을 고민하고, 소프트웨어 제품의 출시 기간을 결정하고, 인사 부서와 함께 직원의 복지 문제를 논의하고, 평가를 통해 연봉과 보너스 수준을 결정하고, 개발자의 불만과 의견을 접수하고, 개발자 문화를 어떻게 개선할지 고민하는 일을 수행했다. (p. 94) – 임백준

관리를 하다보면 다시 개발에 집중하고 싶어진다. 사람을 상대하는 것보다 컴퓨터를 상대하는 것이 더 수월하기 때문일 것이다.
그 때를 위해서 기술을 계속 유지할 수 있는 방법도 설명하고 있다.

기술직 매니저로서의 전문성과 역량을 더욱 키울 것인가 아니면 개발 일선으로 언제든지 돌아갈 수 있게끔 기술을 손에서 놓지 않을 것인가는 개개인이 선택해야 할 문제인 것 같습니다. (p. 219) – 정도현

1. 현대의 소프트웨어 개발은 팀 스포츠입니다. 매니저는 ‘코치’이자 ‘지지자’가 되는 것이 가장 좋습니다. (p. 7)
2. 신뢰가 바탕이 된 인간적인 연결은 좋은 팀의 뼈대다. 신뢰, 특히 진실한 신뢰를 쌓으려면 상대 앞에서 기꺼이 약해질 수 있는 능력과 의지가 필요하다. (p. 23)
3. 자신이 하는 일이 회사의 성공에 어떻게 기여하는지 이해할 때 평범한 일이 자부심의 원천이 될 수 있기 때문이다. (p. 26)
4. 경력의 여러 단계를 거치다 보면, 세상이 얼마나 불확실한지 깨닫게 된다. (p. 30)
5. 건강한 조직에서는 신입 사원 멘토링 프로그램이 멘토와 멘티 모두에게 한 단계 더 성장할 기회가 된다. (p. 37)
6. 멘토링은 관리와 관련된 업무를 안정적으로 배울 기회이자, 조직에서 누군가를 책임지는 경험을 쌓는 기회다. (p. 38)
7. 경청은 사람 관리의 시작이자 기본이다. (p. 40)
8. 효율적으로 일하는 팀에는 신입 사원 교육 문서가 잘 갖춰져 있다. (p. 46)
9. 알파 긱이 팀에서 가장 똑똑하고 기술적으로 뛰어난 사람이라는 정체성을 유지하는 한, 형편 없는 매니저가 될 가능성이 높다. (p. 50)
10. 인재 채용에 많은 비용과 시간이 드는 것처럼 멘토링 프로그램을 운영하는 데도 비용과 지원이 필요하다. (p. 52)
11. 멘티의 질문은 새로운 사람의 눈을 통해 조직의 명확치 않은 것들을 관찰하는 시작점이 된다. (p. 55)
12. 테크리드에게는 기술 전문성 이상으로 사람을 다루는 기술이 필요하다. (p. 64)
13. 흔쾌히 코드에서 한 발 물러나 업무의 기술적인 면과 팀 전체 요구사항 사이에서 균형을 잡을 방법을 찾아야 한다. (p. 66)
14. 테크리드가 되는 과정에서 소프트웨어 개발자, 시스템 아키텍처, 비즈니스 분석가, 팀 리더로서 직접 할 일과 다른 사람에게 위임할 일을 구분할 줄 알아야 한다. (p. 69)
15. 프로젝트 관리가 모든 세부 사항을 관리하는 것이 아닌데, 어떤 조직에서는 세부 사항을 지나치게 점검하는 경우가 있다. (p. 73)
16. 테크니컬 매니저는 정말 어려운 문제를 해결할 수 있는 최고의 사람을 채용하지만, 모든 것을 ‘알지는 못한다’. (p. 76)
17. 좋은 매니저는 언제나 더 큰 리더십 역할을 맡길 재능 있는 사람을 찾습니다. (p. 79)
18. 당신은 매니저로서 결정을 내리고, 문화를 만들고 당신 주변의 모두에게 당신이 하는 일이 효율적이라는 것을 명백하게 증명한다. (p. 84)
19. 팀원이 당신의 의견에 동의하지 않고 당신을 존경하지 않으며, 심지어 좋아하지 않는 것은 자연스러운 일이다. (p. 85)
20. ‘업무를 위한 적절한 도구’가 있다고 믿는 개발자가 테크리드가 되면 그들은 계획, 집중, 시간 관리, 우선순위 설정 등 모든 이슈를 해결할 도구를 찾는 과정에서 프로세스 독재자로 변해간다. (p. 87)
21. 신임 테크리드라면 팀의 의사소통이나 리더십 차이로 인한 문제를 해결해야할 때 프로세스에만 의존하는 것은 주의해야 한다. (p. 87)
22. 테크리드는 직접 결정할지, 팀의 전문가에게 결정을 위임할지, 팀원 전체가 모여 결정할지를 정한다. (p. 89)
23. 성공한 리더는 글을 잘 쓰고, 주의 깊게 읽으며, 그룹 앞에 나서서 말을 잘할 수 있다. (p. 90)
24. 맥락에 대한 이해와 통찰이었다 (p. 95)
25. 매니저 트랙과 기술 트랙은 서로 만나지 않는 두개의 평행선이 아니다. 그것은 서로 수시로 교차하는 나선형이다. (p. 95)
26. 매니저가 되면 끊임없이 사람에 대한 판단을 내려야 한다. (p. 96)
27. 좋은 매니저는 후배를 성장시키는 사람이다. (p. 98)
28. 좋은 매니저는 비전, 실력, 전문성, 의사소통 능력 등 여러 가지 덕목을 갖춰야 하지만 무엇보다도 마음이 넓어야 한다. (p. 99)
29. 신규 직원이 팀에 적응하는 과정의 일부로 신규 팀원용 기존 문서를 갱신하도록 한다. (p. 106)
30. 90일 동안 신규 직원의 시각으로 관찰한 팀에 대한 피드백을 가능한 한 많이 받으라. (p. 107)
31. 원온원은 기획 회의만큼 창의적인 토론 자리다. (p. 111)
32. 어떤 방식의 원온원 미팅을 하든 팀원의 인간적인 모습을 이해할 수 있는 여지는 남겨둬야 한다. (p. 112)
33. 신뢰(trust)할 것인가 통제(control)할 것인가는 마이크로매니저에게 중요한 문제다. (p. 115)
34. 매니저가 쉽게 확인할 수 있는 정보를 수집하는 데 업무 시간의 절반을 쓰는 팀은 절대로 생산성이 높거나 행복할 수 없다. (p. 117)
35. 팀의 표준 업무 방식을 만들면 코드나 설계 리뷰에서 팀원 간 소통이 원활해지며 기술적 피드백을 주고 받는 과정을 객관화할 수 있다. (p. 118)
36. 훌륭한 매니저는 팀원의 재능을 확인하고 강점을 더 끌어낼 수 있도록 돕는 방법을 알고 있다. (p. 121)
37. 성취한 것은 축하하고, 잘 진행되는 일에 대해 이야기하며, 잘한 업무는 많이 칭찬하는 것이 좋다. (p. 125)
38. 누구를 승진시켜야 할지도 고민해야 하지만, 그 사람이 승진할 수 있는 상황도 만들어야 한다. (p. 130)
39. 팀원이 팀을 떠나는 것이 상처가 될 수도 있지만, 그들에게는 새로운 도전을 위해 다른 팀이나 다른 회사가 더 좋을 수도 있다. (p. 132)
40. 피드백은 일찍하고 자주 해야 하며, 기록해야 한다. 또한 긍정적인든 부정적이든 피드백은 반드시 해야 하며 대화 형태여야 한다. (p. 134)
41. 팀 관리는 개인을 관리하는 것과는 차원이 다르다. 그래서 지금부터는 관리 업무의 성격이 바뀐다. (p. 141)
42. 좋은 매니저가 된다는 것은 기술적으로 가장 뛰어나야 한다는 의미는 아니었다. 사람을 돕는 일이 매니저로서 성공하는 데 훨씬 중요했다. (p. 143)
43. 내가 할 수 있는 것이 무엇인지 깨닫고 다른 사람에게 영향을 주어 변화시킬 수 있는 일에 집중해야 한다. (p. 153)
44. 정기적인 프로세스 회고는 패턴을 찾아내고 의사 결정의 결과를 판단하는 데 중요한 가치가 있다. (p. 157)
45. 팀을 성공시키기 위한 일은 심리적 안전을 가져올 수 있는 우호적인 분위기를 만드는 것에서 시작한다. (p. 163)
46. 매니저를 관리하는 방법과 여러 팀을 관리하는 방법은 관련이 있지만 반드시 똑같지는 않다. (p. 177)
47. 엔지니어링 디렉터는 조직의 전반적인 기술 역량을 책임지고, 필요한 경우 교육과 채용을 통해 전체 팀의 역량을 이끌고 성장시킨다. (p. 177)
48. 엔지니어링 디렉터는 회사의 기술 부서와 다른 부서 간의 협업과 기술 부서들 간의 협업에 본보기를 보여주는 강력한 리더다. (p. 178)
49. 코드 리뷰는 코드의 감을 유지하는 좋은 연습이 된다. (p. 179)
50. 위임은 천천히 시작되지만 경력 성장에 꼭 필요한 과정이다. 팀이 당신 없이 잘 운영되지 않는다면, 당신은 승진하기 어려울 것이다. (p. 191)
51. 현실적으로 안 되는 부분을 명확히 이야기하면서도 긍정적인 대답을 할 수 있다는 건 당신이 고위 리더쉽을 시작할 수 있다는 의미이다. (p. 194)
52. ”안 돼요”라고 말해야 한다면 주저하고 오래 끄는 것 보다는 빨리 말하는 것이 좋다. (p. 197)
53. 모든 프로세스가 생산적으로 동작하는지 살피고 자동화될 수 있는지 항상 주시하자. (p. 201)
54. 팀이 더 생산적으로 일하고, 더 빠르고 진취적으로 일할 수 있도록 자극하며, 팀원들이 지금 업무를 더 흥미롭게 진행할 수 있게 시간적 여유를 가질 수 있도록 지원해야 한다. (p. 202)
55. 오래가는 팀은 회사에서 제시하고 공유하는 목표를 기반으로 구성되어 있고 회사의 가치에 잘 부합한다. (p. 208)
56. 수평적인 기업 문화 속에서 매니저는 상급자라기보다는 팀원들이 자신의 일을 원활하게 할 수 있도록 도와주는 집사에 가깝다. (p. 215)
57. 수평적 조직 문화는 조직 내 구성원 모두가 같은 권한을 가진다는 것을 의미하지는 않습니다. (p. 217)
58. 여러 팀을 관리하는 일도 힘들고 부담스럽지만, 여러 매니저를 관리하는 일은 상상할 수 없을 만큼 더 복잡하다. (p. 223)
59. 어떤 사람들은 조직에서 문제를 숨기는 일에 능하며, 당신이 시간을 들여 신경 쓰지 않으면 이런 문제를 전혀 알 수 없습니다. (p. 227)
60. 스킵 레벨 미팅은 중간 매니저 없이 성공적으로 인력을 관리할 수 있는 중요한 비결 중 하나다. (p. 228)
61. 사람들이 물어보는 질문에 어떻게 대답하는지, 회의실 분위기를 어떻게 장악하는지, 생각을 어떻게 정리하는지, 사람들 앞에서 어떻게 서 있는지를 보기 위해서다. (p. 247)
62. 매니저는 본인의 문화로 팀을 만들어 나가고 그 문화를 바탕으로 새 직원을 뽑기 때문에, 매니저에게는 문화 적합성이 아주 중요하다. (p. 249)
63. 최고의 개발 매니저가 훌륭한 디버거인 경우가 많다. 버그를 고치기 위해 끈질기게 ‘왜’를 추적한다. (p. 253)
64. 안타깝게도 팀이 하고자 하는 연구 개발과 레거시 코드 정리, 기술 품질 향상을 위한 시간은 늘 부족하다. (p. 264)
65. 개발자가 비즈니스 관점과 향후 제품 로드맵에 대한 이해를 가지고 결정을 내릴 수 있도록 해야 한다. (p. 266)
66. 이 업무는 소프트웨어 공학과 기술의 트레이드-오프를 이해하지 못하고 여기서 오는 어려움을 받아들이지 못하는 사람이 할 수 없는 매우 기술적인 업무다. (p. 267)
67. 우리는 기술 시니어 리더다. 매니저이면서 개발자로서 기술 시니어 리더에게 주어지는 개발과 이에 관련된 책임, 지속적으로 변화하는 환경 변화에서 팀원의 성장을 돕는 책임을 진다. (p. 275)
68. 사람들은 당신을 믿고, 당신이 뽑은 사람들을 믿고, 당신이 세운 임무를 믿기 때문에 회사에 입사한다. (p. 276)
69. 사람들에게 회사의 가치가 무엇인지 보여주자. 당신의 약속을 지키자. 별로 내키지 않아도 팀에 가장 좋은 모범을 보이자. (p. 277)
70. 개발 부사장은 숲도 볼 줄 알아야 하고 나무도 볼 줄 알아야 한다. (p. 283)
71. CTO는 비즈니스에 대해 관심을 가지고 이해해야 하며, 기술적인 측면에서 비즈니스 전략을 수립해야 한다. (p. 285)
72. 집중하고 있는 것을 유지하거나 바꾸려면 위아래로 설득할 준비가 되어야 한다. (p. 290)
73. 상사가 해주었으면 하는 일이 있다면 상사에게 최소한 세 번은 이야기해야 한다. (p. 291)
74. 기술 전략은 기술 아키텍처를 의미했고, 팀 구조를 의미했고, 비즈니스의 기초와 방향을 이해하는 것을 의미했다. (p. 295)
75. 일단 결정되고 나면, 우리는 결정에 따르고 회사의 개발 팀 및 모든 사람들 앞에서 단결된 모습을 보여야 한다. (p. 303)
76. 사람들은 당신이 팀 앞에서 하는 행동을 그대로 배우고 모방할 것이다. (p. 305)
77. 실수를 하더라도 위험을 감수하는 팀을 만들고 싶다면 챙겨야 할 핵심 요소는 ‘소속감’과 ‘안전성’이다. (p. 309)
78. 신뢰를 기반으로 한 문화를 만들어가는 것은 시간이 걸리지만, 결과는 그럴 만한 가치가 있다. (p. 311)
79. 리더는 세부 사항을 모두 조사할 시간이 없이 빨리 결정해야 할 때, 자신이 오랜 기간 쌓아온 지혜에 의지해 결정을 내린다. (p. 313)
80. 문화를 만드는 것도 시니어 개발 리더의 역할이다. (p. 321)
81. 성공과 실수를 통해 학습하고 실패로부터 학습한 교훈을 투명하게 공유하고 싶다면 시스템을 만들어야 한다. (p. 322)
82. 회사 간 유사한 점이 많더라도, 어떤 회사에서 잘 운영되던 부분이 다른 회사에서 잘 운영될 것이라는 보장은 없다. (p. 338)
83. 가장 좋은 프로세스와 가장 좋은 문서는 지금 당신이 품은 선입견만 반영하는 것이 아니라 팀 전체를 반영한 문서다. (p. 344)
84. 개발 프로세스 없이는 팀이 성장할 수 없으며 잘못된 프로세스는 팀의 생산성을 저하시킨다. (p. 348)
85. 투명하게 모든 사람에게 공유한다는 것이 누구에게는 용기를 낸 행동일 수도 있습니다. (p. 361)
86. 갈등을 잘 해결한다는 의미는 대화할 때 자존심을 잘 분리한다는 의미이다. (p. 365)

BOOK Comment 1-2-3
1. 처음 부사수가 생겼을 때 읽었으면 좋았겠지.
2. 개발과 관리는 다른 영역이다.
3. 개발을 관리하는 것은 일반 관리와도 다르다.

BOOK Underline 1-2-3
1. 세계 어디에서든, 회사의 문화가 어떻든, 개발 관리는 힘들고 외로운 업무입니다. 
2. 매니저의 업무는 회사와 팀을 위해 최선을 다하는 것이다. 팀원이 좋아하는 일만 하는 게 아니다.
3. 팀이 현재 매일 최상의 컨디션으로 일할 수 있는 환경인가?

BOOKSTORE : YES24, 알라딘