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

감상

2020.04.18

멘티 개발자, TL, 매니저 등 단계별로 신경을 써야 할 일들을 이 책에서 체계적으로 정리했다고 느껴집니다. 미국 IT 업계를 배경으로 하고 있지만 국내 IT회사에 다니는 분들도 공감이 갈만한 지점이 많습니다. 1On1 미팅을 강조하고 있다는 점도 인상적입니다.

2020.06.30

‘실리콘밸리의 팀장들’ , ‘개발7년차, 매니저 1일차’, ‘슬랙’ 을 읽고 느낀 점

• 다른 사람과 협업을 하는 모든 개발자는 ‘관리'의 영역에 있는 일을 신경써야 한다.
• 관리 업무에서 가장 중요한 지점은 ‘명확한 피드백'을 전달하는 것이고, 때로는 불편한 피드백을 주어야 하는 경우도 있다.
• 어느 규모 이상의 조직을 담당하는 매니저(한 10명이상?)라면 관리와 개발을 다 하겠다는 것은 욕심이고 좋은 결과를 낳지 못한다.
  • 전업 관리자 업무를 하게 되더라도 다시 개발업무를 하는 직무로 돌아갈 수도 있다고 생각하는 좋다. 그래야 기술에 대한 관심과 영향력을 유지할 수 있고, 팀원들과 피드백을 주고 받을 때 합리적인 근거를 찾게 되는 노력을 더 하게 되는듯하다.

인상 깊은 부분

1장 : 관리 101

p20

“매니지먼트의 비밀은 당신을 미워하는 사람들을 아직 그렇지 않은 사람들에게서 떼어놓는 것이다.” - 케이스 스텡겔(미국 메이저리그의 전설적인 감독)

2장 : 멘토링

p41

멘토가 질문에 답을 하기 위해 많은 시간을 쓰는 확률보다 멘티가 충분히 질문하지 않아 일이 전혀 다른 방향으로 잘못 진행될 가능성이 높다.

3장 : 테크리드

p62

테크리드는 자기 코드의 세부 사항에만 집중하고 싶은 사람에게 적합한 역할이 아니다.

우리는 테크리드의 역할을 개발자가 특정 레벨에 도달했을 때 맡는 역할이 아니라 경력 사다리의 다양한 지점에서 맡을 수 있는 하나의 특성으로 정의했다.

p73

불확실한 부분이 많고 상대적으로 마감이 빠듯한 프로젝트를 맡게 되면 일반적인 애자일 개발 방법론이 프로젝트에 딱 들어 맞지 않다는 걸 깨닫게 된다.

p81

“시니어 개발자의 실제 생활” 단락

당신이 중요한 아키텍트임을 증명할 수 있는 대규모 프로젝트는 드물다.

p86

“매니저의 실제 생활” 단락

마지막 조언은 원할 때 경력 트랙을 전환할 수 있음을 기억하라는 것이다. 매니지먼트 업무를 하다가도 업무와 맞지 않아 다시 기술 트랙으로 돌아가는 일은 흔하게 일어난다. 어떤 선택도 영원한 것은 없으며 이렇게 하더라도 당신의 시야는 넓어진 것이다.

p92

임백준 님의 기고. 매니저와 테크니컬 리더와의 역할 차이

매니저는 팀원을 리드한다는 면에서 테크니컬 리더와 비슷하지만 완전히 다른 역할을 수행한다. 가장 큰 차이는 코드를 작성하는가 여부다. 테크니컬 리더는 다른 개발자와 함께 코드베이스에 코드를 체크인하지만 매니저는 코드를 체크인하지 않는다. 또 다른 차이는 팀원들을 평가하는 방식과 수준이다. 테크니컬 리더는 팀원을 직접 평가하거나 팀원의 연봉과 보너스를 결정하지 않는다. 기술적인 영역에서만 리더십을 발휘하며 영향을 미친다. 하지만 매니저는 평가와 연봉, 보너스를 결정하는 업무를 수행한다.

p93

임백준 님

초보 매니저가 흔히 저지르는 실수의 하나는 자기 본분을 잊고 코딩 업무를 게속 수행하는 것이다. 매니저가 개발자와 함께 코딩을 하는 문화가 바람직하다고 주장하는 사람도 있지만 그렇지 않다. 사람을 관리하고, 평가하고, 응원하고, 일정을 책임지는 것은 그 자체로 상당한 수준의 역량과 노력을 필요로 하는 전문적인 업무다. 파트타임으로 할수 있는 일이 아니다. 마찬가지로 코드를 설계하고, 구현하고, 테스트하고, 디버깅하고, 현장문제를 지원하는 일은 온 힘을 다해서 수행해야 하는 고도로 전문적인 업무이며 파트타임으로 감당할 수 있는 일이 아니다. 따라서 그 둘을 섞는 건 어느 쪽도 제대로 할 수 없게 만드는 잘 못이다.

p95

임백준 님

매니저는 기술의 막다른 골목이 아니다. 매니저가 되면 어쩔 수 없이 기술이 퇴화하고 다시는 개발 협업으로 돌아갈 수 없다고 생각하는 사람이 많다. 이것은 사실이 아니며 사실이 되어서도 안 된다. 이런 생각은 기술적으로 게으른 매니저에게 면죄부를 발급해주는 미신에 불과하다. 매니저 트랙과 기술 트랙은 서로 만나지 않는 두 개의 평행선이 아니다. 그것은 서로 수시로 교차하는 나선형이다. 백세 시대의 기나긴 커리어 기간을 고려하면 매니저는 언제나 기술현업에 돌아갈 준비가 되어 있어야 하고, 코딩 업무를 보는 사람도 상황에 따라 hands-off 매니저 역할을 수행할 수 있어야 한다.

p96

임백준님

매니저가 되면 끊임없이 사람에 대한 판단을 내려야한다. 그리고 그 판단은 냉철하고 정확해야 한다. 일상생활에서 다른 사람을 제멋대로 판단하는 것은 나쁜 습관이지만 매니저가 팀원에 대해서 내리는 판단은 회사의 정상적인 운영을 위해 꼭 필요한 일이다. 다만 매니저의 판단은 반드시 조직의 목표와 비전이라는 문맥 안에서 이루어져야 한다.

4장 : 사람 관리

p102

“개발팀장이 되면 새로 맡은 직무를 승진으로 생각하고 개발 과제나 문제에서 연공서열을 따지게 된다. 이런 태도는 초보 매니저에 머무르다 결국 나쁜 리더가 되는 가장 확실한 방법이다. 신임 개발팀장이라는 위치가 서열의 말단이라는 것을 받아들이기 어렵겠지만, 팀을 이끄는 입장에서 이는 최고의 사고 방식이다.” 마크 헤드룬드

p107

‘팀원과 소통하기’ 단락

정기적인 원온원은 자동차의 엔진 오일을 바꾸는 것과 비슷하다. 귀찮다고 건너뛰면 고속도로 갓길에서 옴짝달싹 못하는 최악의 상황에 대비한 계획이 필요할 것이다. - 마크 헤드룬드

p115

업무가 제대로 처리될 거라 믿지 못하거나 당신이 정한 기준으로 결과물을 엄격하게 통제하려 할 때 마이크로매니지먼트를 하게 된다. 이런 상황은 개발자가 특히, 기술적으로 자부심이 강한 갭라자가 팀장이 될 때 자주 일어난다.

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

####  p117 “팀원을 만나기 전에 시스템에서 정보를 수집하라” 단락

최악의 마이크로매니저는 쉽게 얻을 수 있는 정보인데도 끊임없이 묻는 사람이다.

5장 : 팀관리

p159

합의냐 투표냐를 양자택일하지 않는다. …. 나쁜 소식을 직접 전해야하는 매니저의 책임을 지지 않으려고 문제 될  것이 뻔한 투표로 사람들을 몰아넣지 않는다.

p160

성과 평가 과정에서 매니저로서 부정적 피드백을 해야 한다면, 이를 즉시 실행해 직원들이 크게 놀라지 않도록 한다.

이렇게 자문하는 목표는 목표는 팀의 효과성을 떨어뜨리는 문제를 함께 찾아내고 해결하는 것이지 팀의 치료사가 되는 것이 아니다.

p161

승진할 준비가 되지 않은 사람에게 더 준비가 필요하다고 알려주고, 그러려면 무엇이 필요한지 말해주는 것이 친절한 것이다. “아마 승진할 수도 있을 거야"라고 말해놓고 승진하지 못하는 것을 지켜보는 것은 그 사람에게 친절하지 못한 행동이다.

p165

똑똑한 바보가 있을 때 팀을 위한 최선의 방법은 나쁜 행동을 용인하지 않겠다고 공개적으로 거부하는 것이다. “칭찬은 공개적으로, 비판은 개인적으로” 라는 방법을 거꾸로 적용하는 몇안되는 경우다. 이런 직원의 행동이 쉽게 눈에 띌 정도로 팀에 영향을 미치고, 이런 방식이 매니저로서 원하는 것이 아니라면 규칙을 분명히 하기 위해서 그런 수간에 무엇인가를 명확하게 지적해야한다.

p166

매니저의 첫 번째 목표는 전체로서 팀을 보호하는 것이며, 두 번째는 팀원 개인을 지켜주는 것이고, 매니저 스스로를 지키는 것이 가장 우선 순위가 낮은 일이다.

‘소통하지 않는 사람’ 단락

가능하면 뭔가를 숨기는 근본적인 원인을 다뤄야 한다. 무엇인가를 숨기는 사람이 비난받는 것을 두려워한다면, 팀에 해결되어야 할 가혹한 문화가 있는 것은 아닌가? 일반적으로 그런 심리적 안정감이 팀에 있는가? 혹시 이런 팀원이 다른 배경이나 기술을 가지고 있어서 다른 팀원들이 아웃사이더로 취급하는가?

p170

‘반드시 있어야 할 기능’ 이 실제로 반드시 필요한지 파악 할수 있도록 기술 팀 리드로서 테크리드와 제품 리드/비즈니스 담당자와 협력해야 한다는 의미다. 양쪽 모두에게 아니요라고 말할수 있어야하 한다.

빠른 추정을 할 때는 두배 법칙을 사용하지만, 긴 작업을 추정하는 계획시간을 따로 가져아한다. 인기 있는 소프테웨어 추정 방법인 두배 법칙은 “시간 추정 요청을 받을 때마다 추측한 다음 두 배로 알려준다.“이다. 이 규칙은 즉석에서 추측해 달라는 요청을 받을 때 사용할 수 있는 적절하고 좋은 규칙이다. 그러나 2주 이상 걸릴것으로 예상되는 프로젝트에 대해 말할 때는 예상치를 두배로 말하면 되지만 소요시간을 확실히 하기 전에 약간의 계획 시간이 필요함을 분명히 해두어야 한다.

p171

불확실성을 잘 다루어서 팀이 겪게 되는 불확실성의 정도를 제한하는 것이 매니저의 책임이다. 앵무새처럼 다른 사람의 말을 반복하며 이미 계획한 중요한 업무로 바쁜 팀원들을 방해하는, 엔지니어와 화사의 사람들 사이에 전화기 노릇은 하지 말자. 그렇다고 블랙홀이 되어서도 안 된다.

6장 : 여러팀 관리

p181

마지막으로, 코딩을 많이 하지 않을 작정이라도, 적어도 일주일에 한 번 반나절 동안은 미팅이나 업무에서 벗어나 창의적인 작업을 꼭 하기를 권장한다. 개발 블로그에 포시팅을 작성하거나, 컨퍼런스 내용을 준비허간, 오픈소스 프로젝트에 참여할 수 있다. 창의성 갈증을 해소할 수 있는 일을 해보라. 그렇게 하지 않으면 매너조럿 만족도가 떨어질 수 있다.

p182

그 만면에 ‘관리'는 명확한 퀵윈이 많지 안혹, 특히 신입 매니저는 퀵윈을 하기가 더욱 힘듭니다. 컴퓨터 앞에서 일만 하면 되던 그때, 이렇게 골치 아프로 복잡한 ‘사람'을 다룰 필요가 없던 그때, 단순했던 그때를 그리워하는 건 당연합니다.

p191

팀이 당신없이 잘 운영되지 않는다면, 당신은 승진하기 어려울 것이다.

p218

정도현님의 기고

개발자의 경력 경로는 사다리가 아니라 정글짐 만약 매니저를 하다가 적성과 맞지 않는다고 판단되거나 아직 이르다고 판단되면 일반 개발자로 돌아올 수도 있어야 합니다. 이를 좌천으로 보아서는 안됩니다.

7장 : 매니저 관리

p236

예스를 남발하는 사람은 약속을 과하게 하고 잘 지키기 못하며, 이런 경험을 하고도 향후 필요한 약속만 해야한다는 것을 배우지 못한다.

p241

과로하는 매니저는 다른 팀원에게 자신의 기존 업무를 인계하지 못한 채 새로 맡은 매니저 업무까지 두 가지 일을 모두 한 번에 하고 있을 것이다. … 기존 업무를 인수인계하고 새로운 기회를 발견하기를 바란다고 신입 매니저에게 명확히 알려야 한다.

과로는 종종 신입 매니저가 위험하다는 신호이기도 하다. 자신이 통제광, 팀에 일을 시키는 사람이라고 생각하는 매니저는 모든 결정을 자신이 내리려고 한다. 업무에 소홀한 매니저도 나쁘지만, 때로눈 권력을 행사하고 싶어서 열심히 일하는 매니저가 더 나쁘다.

p246

매니저 면접과 개발자 면접의 가장 큰 차이는 이론적으로 매니저가 당신을 쉽게 속일 수 있다는 점이다. 앞서 계속 언급된 매니저의 능력은 거의 전적으로 소통에 기반을 두고 있다. 면접에서 글러듯한 말을 잘하는 사람은 채용될 수 있지만 실전에서 일을 잘하지 못할 수도 있다.

매니저에 지원한 사람은 모두 면접 때 원온원 미팅 역할극을 수행해야 한다.

p249

동료에게 잘 하는 대기업 출신 매니저를 보았는데, 이 살마은 부하 직원이나 하급 직원들을 비인간적으로 대우해 스타트업에서 큰 마찰을 일으켰다. 다른 관계자으 ㅣ승인도 많이 필요한 환경에서 본인이 가장 중요하다고 생각하는 부분이라면 무엇이든 추진하는 스타트업 출신 매니저도 여럿 만나봤다.

p253

“제대로 작동하지 않는 조직을 디버깅하기” 단락

훌륭한 디버깅이 관리와 무슨 관련이 있을까? 팀 관리는 서로 연동되는 여러개의 복잡한 블랙박스라고 할 수 있다. 이 블랙박스는 눈으로 확인 가능한 입력과 출력이 있지만, 출력이 예상과 다를 때 그 이유를 살펴보려면 블랙박스를 열어 내부적으로 어떤 일이 벌어지고 있는지 보아야 한다.

p255

지루한 회의는 잠재적 문제의 신호다. 지루한 회의는 주최자가 비효율적으로 준비했다는 의미일 수 있다.

p256

슈뢰딩거 실험의 핵심은 관찰이 결과를 달라지게 하거나 오히려 결과를 유도한다는 점이다. 마찬가지로 당신은 팀에 들어갈수 없으며, 팀 주위에 있거나 회의에 함께 참석하거나 팀원의 발표를 보고 있는 것만으로 팀 행동이 바뀔 수도 있다. 적어도 당분간은 로그문이 동시성 문제(concurrency issue)를 마법처럼 안 보이게 하는 것처럼 당신이ㅡ 존재가 팀의 행동에 영향을 미치고 당신이 찾으려는 문제를 가릴 수 있다.

p260

스트레스를 피하고 싶을 때 남을 비난하는 방법은 보통 합리적이지 않다. 압박을 주는 사람에게 공감하는 모습을 보여주고 여러 방법으로 문제를 해결하려고 하면 비난이 행동으로 바뀌는데 상당한 효과가 있다.

p262

향후 개발 프로젝트 약속을 남발하지 말라. ‘나중에’ 재미있는 개발 프로젝트를 할 것이라고 팀과 약속하지 말라. 나중을 위한 제품 로드맵은 아직 작성되지 않았기 때문이다. 이런 방식은 희망고문이기도 하고 결국 서운함을 낳게 된다.

8장: 빅리그

p284

CTO는 개발자가 아니다. CTO는 기술 경력의 최상위에 위치하는 직업이 아니다. 천생 개발자인 사람들이 경력 목표로 삼아야 하는 역할이 아니다.

p291

마지막으로, 사람들이 충분히 이해할 수 있도록 하기 위해 얼마나 자주 다양한 방법으로 이야기해야 하는지 쉽게 생각하지 말자.  큰 조직에서 소통한다는 것은 어려운 일이다. 내 경험으로는 대부분의 사람들이 실제로 이해하기 까지 최소한 세번은 들어야 했다.

p296

많은 사람을 모아놓고 나쁜 소식을 공지하면 안된다. 나쁜 소식을 전달하는 가장 나쁜 방법은 이메일과 채팅을 통해서 전달하는 방법이다. 특히 답글을 달 수 있는 매체가 제일 좋지 않다. 당신의 팀은 당신이 직접 전달해 주는걸 들을 자격이 있고, 직접 메시지를 전달하지 않으면 사람들의 오해와 분노기 커질 수 있다. 나쁜 소식을 전달하는 두 번째로 좋지 않은 방법은, 소식이 반갑지 않을 많은 살마들을 모두 한 방에 모아놓고 메시지를 전달하는 방법이다. 차라리 소문이 나기 전에 한번에 모두에게 나쁜 소식을 전하는 방법이 가장 좋다고 생가하겠지만, 이 방법 역시 비인간적이다. 모든 사람들의 반응을 볼 수는 없지만 메시지가 제대로 전달되기도 전에 매우 상심한 산두 명의 직원이 순식간에 모든 팀을 화나게 만들 수 있다.

p304

당신은 더이상 팀원이 아니다. 당신의 최상위 팀은 리더십/임원진 동료로 구성되어 있고, 두 번째 팀은 당신의 보고 라인이다. 당신을 팀원 중 한 명에서 담당 책임자로 인식시키는데 성공했다면, 아마도 조직 전반에서 사람들과 조금 떨어지기 시작할 것이다. 회식이 있을 때에는 술을 마시러 가되 팀이 서로 어울리도록 자리를 피해주어야 한다. 가게가 문을 닫을 때까지 함께 있게 되면 모두에게 좋지 않다. 그 어떤 정기 회식에서도 그러지 않기를 간절히 바란다. 근무 시간 외에 팀과 깊이 친분을 쌓는 일은 옛날일이다.

p306

사람들은 아무도 잣니을 개인적으로 신경 써주지 않는다고 느끼면, 최선을 다하지도 않고 윟머을 감수하지 않으며 어려운 과정들으 겪지 않으려고 할 것이다.

p131

진북을 결정하는 리더는 세부 사항을 모두 조사할 시간이 없이 빨리 결정해야할 때, 자신이 오랜 시간 쌓아온 지혜에 의지해 결정을 내랜다. 이런 유형의 리더가 되고 싶다면 커리어 초기에 이런 재능을 연마할수 있도록 시간을 많이 할애해야, 빠른 결정을 안정적으로 내릴 수 있다. 기술 지식을 유지해야 한다는 의미이기도 하다. 기본적인 지식 그 이상을 배울 수 있도록 프로젝트, 프로그래밍 언어, 프레임워크를 충분히 오랫동안 따라가보면서 노력해야 한다. 매일 코딩을 할 수 없더라도 새로운 것을 배우기 위해 노력해야 한다.

9장 : 문화개선

p328

존 갤의 저서 ‘Systemantics'에 나온 내용

단순하지만 작동하는 시스템만이 복잡계로 진화한다는 점에는 예외가 없다. 아무것도 없이 설계된 복잡계는 절대로 동작하지 않으며, 작동하도록 수정할 수도 없다. 반드시 동작하는 단순한 시스템에서 시작해야 한다.

p339

문화란 사람들이 일을 완성하려고 생가하지 않아도 일이 완성되도록 하는 방법이다. - 프레데릭 라루, ‘조직의 재창조’

p351

‘스타일 문제는 린터(linter)를 사용하라’ 다락

코드 리뷰 때 스타일 이야기를 하게되면, 비생산적인 사소한 말다툼과 비판이 발생하고, 최악의 경우에는 괴롭힘으로 이어진다.

p354

아키텍처 검토

결정을 내리는 위원회는 가장 많은 영향을 받는 사람들로 구성되는 것이 좋다. 전혀 무관한 사람들이 프로젝트를 거부하는 것만큼 팀원들의 사기를 떨어뜨리는 일은 없다.

p356

배상언 님의 기고

그렇다고 해서 여지껏 본 적 없는 독창적인 프로세스를 만드는 것은 추천하지 않습니다. 관리 방법의 발전은 기술의 발전에 비해 비교할 수 없을 정도로 느립니다. 효율성을 높일 수 있도록 프로세스를 만든다는 것은 보편적으로 통용되는 관리 방법을 토대로 상황에 맞게 약간 변화를 주는 정도로 이해하면 좋을 것 같습니다.

10장 : 결론

‘나 자신부터 관리하기’ 단락

내가 배운 중요한 교훈은, 다른 사람들을 잘 관리하기 위해서는 나 자신을 관리할 수 있어야 한다는 점이다. 자기 자신, 자신이 반응하는 방법, 자신에게 영감을 주는 일, 자신을 미치게 만드는 일에 대해 이해하기 위한 시간을 가질수록, 나아질 것이다. 훌륭한 매니저는 갈등을 해결하는 전문가다. 갈등을 잘 해결한다는 의미는 대화할 때 자존심을 잘 분리한다는 의미이다.