윌라슨 지음

1. 한줄평 관리에 정답은 없다. 그러나 정답으로 다가갈 수 있게 도와준다. 개발자/관리자 상관없이 누구에게나 꼭 한번쯤 읽어 봤으면 하는 책, 한번 읽고 딱 덮어놓을 수 없는책(옆에 항상 두고 싶은책)

2. 읽으며 기록한 부분들 과 생각
   1) 챕터를 분리 해서 각 관점 별로 정리되어 그 부분만 읽어도 된다.
   - 조직, 도구, 접근법, 문화, 경력
   2) 각 chapter 별로 전체를 아우를만한 도서(혹은 논문)을 앞단에 미리 이야기 해준다(더 읽을거리를 준다)
   ex) p.111 chapter3 도구 중 3.10 미디어를 통한 학습 중 조지 레이코프의 “코끼리코는 생각하지 마 - 진보와 보수, 문제는 프레임이다”
   미디어 발표의 세가지 규칙 1. 묻고 싶은 질문에 답을 해보자. 2. 긍정적인 태도를 갖자. 3. 세가지로 요약해 발표하자로 간결하게 방법을 알려준다.
   - p.286 어떤 사람에게는 어려운 정치적 관점에서 집필된 책이긴 하지만 이 책은 내가 아이디어를 제시하는 방식을 완전히 바꿔놓았다. 어쩌면 레이코프의 좀 더 학술적인 저서를 읽고 싶겠지만 이 책이 훨씬 더 간략하고 읽기가 쉬우므로 이책을 먼저 읽는 것을 추천한다.
   3) 기본을 빠트리지 않는 시작을 할수있게 도와준다.
   - 시간이 지남에 따라 경험이 쌓이고 그 경험을 통해 초반에 내가 왜 이런 실수를 하고 왜 이런 부분들을 미리 준비하지 못했나, 시작을 왜 이렇게 어렵게 진행했나 라는 생각을 하게 된다. 그럴때 1~100 전체를 다 알려준다고 할수는 없지만(회사마다 절차,방법론,산출물등이 다 다르다) 기본은 할 수 있도록 가이드를 잘 해준다.
   ex) p.240 “채용 깔대기는 후보자의 선별, 후보자에게 지원 동기 부여, 회사에 맞는 인력에 대한 평가, 마지막으로 합류와 마무리 등 네가지 단계로 구성된다. 현재의 상황에 따라 이 중 하나 혹은 모든 단계가 매우 어려울 수 있다.” chapter 6. 경력의 6.4 채용 깔대기에 대한 내용으로 채용을 진행하게 될때 준비해야할 부분, 채용 후 평가 최적화와 채용 깔때기의 확대 부분까지 이야기 해준다.
   4) 본인의 경험을 사례를 들어 활용할 수 있게 녹였다.
   ex) p.216 “1년이 되지 않아 이직을 하는 것은 좋지 않다고 보는것이 업계의 전반적인 시각이다. 하지만 한 회사에서 몇 년간 근무한 적이 있거나 1년을 채우고 이직을 한 경력은 그렇게 무제가 되지 않는다. 이런 믿음이 심각하게 문제가 있다고 생각하지만 그럼에도 불구하고 필자의 경력에도 하나의 기준이 되었다. 어디든 2년은 머물되, 2년마다 중심적인 역할을 수행하면서 4년을 보낼 수 있는 회사를 찾는 것이다.” 본문 발췌, 이후 “새로운 경력의 전개” 와 “성장의 기회”로 이어진다.
   p.219에 “성장을 당연한 것으로 생각하지 말자. 성장은 변화로부터 이루어지며, 그 변화가 바로 영향력을 행사할 수 있는 부분이다”
   5) 관리자로써 놓칠 수 있는 부분을 알려준다.
   - 어디나 처음은 있고, 내가 이만큼 잘 하고 있으니(본인 생각에) 나는 굳이 필요없다 라고 생각할 사람들이 한번 읽어보고 그래서 관리를 하는동안 부족했던(간과했던) 그리고 이제 시작하려는 관리자들에게 처음 들어가는 접

3. 그외로 이책을 읽으며 생각한 부분들
   1) 번외로 읽어야 할 책이 늘어났다.
    - p.43 피닉스 프로젝트 : 위기에 빠진 IT프로젝트를 구하라(에이콘 출판사), p.58 시스템적사고 “Thinking in System : A primer, Chelsea Green Pub Co,2008”등
    - 7.2 유용한 참고도서(p.286 참고)
    2) 논문도 들어났다
    - 7.3 유용한 논문(p.292 참고)
4. 나(저자)는 이렇게 하는데 나(독자)는 어떤지 생각을 물어본다.
    - p.154 “내가 관리직을 시작했을 때의 리더십 철학은 간단했다.
     1. 골든룰을 따르는 것이 맞다.
     2. 모두에게 각자 ‘주인 의식’을 가지고 책임질 부분을 정해주자.
     3. 보상과 지위는 높은 품질의 작업을 완수해야 얻을 수 있다.
     4. 솔선수범하고 내가 하고 싶지 않은 일을 남에게 부탁하지 말자. “
   
   - p.155~ 문제보다는 끈끈한 관계까 중요하다. 절차보다는 사람을 우선하자. 어려운일은 지금하자. 회사, 팀 그리고 본인 그리고 본인을 위한 고민을 통해서 관리자를 하고 있는 독자에게 최고의 관리 철학에 대해 묻는다. 계속 현실과 마주하며 진화 하는 것이라고, 최악은 아무런 이론도 없는것이지만 그 다음으로의 최악은 변화를 수용하지 안는것이라는 이야기에 진심으로 공감한다.

처음 오늘부터 매니저입니다. 라는 책제목을 보고 이제 막 매니저가 된 사람에게 도움이 되는 책인줄 알았는데 거의 끝까지 읽어보니 관리자의 관리자까지 고려한 매우 폭넓은 범위의 관리자를 위한 책이었다. 
책의 원래 제목이 elegant puzzle 인데 책을 읽으면서 제목을 왜 이렇게 지었는지 생각해보게 된다. 
이책은 내가 제목만 보고 착각한것과 다르게 팀장급뿐만 아니라 이사,상무같은 임원급 분들이 읽기에도 좋은책이다. 관리자들을 관리하는 내용도 있으니 임원을 꿈꾸는 분들은 보세요.
일단 책 표지 우측상단에 적혀있듯이 저자는 IT회사의 관리자를 대상으로 책을 썻는데 저자가 IT회사에서 개발자(프론트엔드)로 시작해서 임원까지 올라가면서 경험한것을 책으로 쓴것으로 보인다. 내용이 주로 IT관련 부서를 대상으로 쓰여졌긴한데 그렇다고 기술적인 내용이 많이 들어간건 아니기 때문에 IT관련된 분이 아니더라도 읽어볼만한 내용들이 많이있다. 

주요 내용을 "조직", "도구", "접근법", "문화", "경력" 5개의 챕터로 나누어 썻는데 이중 가장 많은 비중을 차지하는 챕터가 도구와 경력인데 그만큼 조직관리에 필요한 내용이 많다. 그리고 책에서 관리문제는 정답이 없다고 하는데 참 공감가는 애기다. 

처음 조직 챕터는 팀규모와 팀의상태 각팀원에 대한 상태등에 다루고 있는데 이부분은 회사규모에 따라서 달라질수도 있다고 생각하고, 중견기업 이상의 조직이라면 책의 내용을 활용하기 딱 좋다는 생각이 들었다.  
두번째 도구 챕터는 조직으로 회사일을 어떻게 할것인지 조직원들을 데리고 일을 진행하는 방식등에 대해 다루고 일을 하는데 있어 효율적이고 적극적으로 일을 시키기 위한 방법이나 IT기업에서 자주 언급되는 기술부채문제 등을 다룬다. 기술부채는 IT업무하면서 항상 마주하게 되는 문제인데 쉽게 해결하려면 외주를 쓰면 되지만 근본적인 해결이 되지않고 회사에서 IT조직의 규모가 작으면 기술부채가 해결이 안된채로 넘어가는 경우가 많아 독자들이 관심있게 볼것같다. 이외에도 의사소통, 시간관리등 관리자가 되기전 엔지니어 시절부터 겪어밧을
문제들을 다룬다.
접근법은 IT팀에서 일어나는 다양한 문제들에 대한 접근법을 다루는데 기술하고 상관없이 사람대사람으로 윗사람과 아랫사람으로서 서로 어떻게 대해야 하는지 업무는 어떻게 나누고 어떻게 관리해야 하는지를 다루는데 정말 정답이 없는 문제를 다루고 있다. 일단 대화가 많이 필요하다고나 할까
문화 챕터는 영웅프로그래머 없애기가 눈에 딱 들어오는데 직장인들이라면 공감하는 일잘하는 사람에게 일이 몰리는 현상에 대해서 다루고 있다. 외국이랑 한국이랑 문화가 다르다고 하는데 이 책보면 직장생활은 비슷한 부분이 참많다.
마지막 경력 부분은 말그대로 경력키우기나 채용에 대한 부분을 다루고 있는데 대기업이나 브랜드가 있는 기업은 이 부분에 신경쓸 필요가 없다고 한다. 알아서 좋은 사람들이 지원하기 때문이다. 하지만 그렇지 않은 기업에 관리자라면 평상시에 네트워크를 미리미리 확장해서 좋은 사람을 미리미리 확보해 두었다가 스카웃하라고 한다.
이런 방법에 대해 다루고 있는데 제갈량 얻는 유비의 노력같은 느낌이라고 해야하나 그냥 딱 필요할때 사람 찾지 않고 평소에 네트워크를 만들어 두어야 한다는게 놀랍다.

마지막으로 팀원으로 계신분들도 미리미리 한번 이런책을 읽어주신 다음에 직장생활 하는것도 좋다고 생각한다.
직장생활이란게 시킨일만 잘한다고 잘 풀리는게 아니기 때문에 사회생활 시작할때 조직의 생리에 대해 알아두는게 좋기때문이다.

IT 업계의 개발자로 근무를 하고 있는 개발자로서

조직을 설장시킬 수 있는 리더가 되려면 어떤 소양이 필요한지 알아보기 위하여 이 책을 읽어보게 되었습니다.

저자인 윌 라슨은 엔지니어링 리더이자 소프트웨어 엔지니어로서

야후, 디그, 소셜코드, 우버 같은 다양한 형태와 규모를 가진 회사를 거쳐 2016년 부터 스트라이프에 재직중이라고 합니다.

이러한 다양한 곳에서 리더를 한 사람의 이야기는 경청해 봐야하지 않을까요...?

1. 소개

본 책에서는 조직, 도구, 접근법, 문화, 경력의 5가지 주제로 매니저먼트 기술을 소개하고 있습니다.

- 조직 : 조직을 일관되게 유지하고 주의 깊게 변경하는 법을 설명한다.

- 도구 : 시스템 사고, 문서, 지표, 마이그레이션 등 관리용 도구에 알아본다.

- 접근법 : 빠르게 성장하는 기업에서 관리 능력을 적용하는 법을 설명한다.

- 문화 : 포용력을 갖도록 지도하기 위한 방법과 사례를 살펴본다.

- 경력 : 면접, 채용, 성과 관리 등을 직접적으로 설명한다.

2.1 팀 규모 정하기

팀 규모 결정 가이드라인

- 정상적인 상태의 팀은 6~8명 규모여야 한다.

- 새로운 팀을 구성하려면 기존 팀의 규모가 8~10명 정도로 성장하여야 하고, 그럴 경우 4~5명 규모의 2개의 팀으로 나눌 수 있다.

- 팀원이 없는 팀은 절대 편성하지 말자.

- 관리자가 8명이 넘는 엔지니어들을 관리하게 하지 말자.

중소기업에서는 흔히 2~3인 정도의 팀으로도 개발을 하고 있거나 10명이 넘은 팀원을 1인이 관리하는 곳도 많은 곳이 현실이므로 이런 곳은 관리자의 능력을 최대한 발휘하지 못하겠구나라는 생각이 들며, 이러한 회사는 경영진에서 이 책을 읽어야 하지 않을까 라는 생각이 들었습니다.

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

팀의 4가지 상태

1.뒤처지는 상태 -＞ 인원 충원

2.업무가 벅찬 상태 -＞ 진행 중인 업무량 감소

3.기술 부채를 해결 중인 상태 -＞ 충분한 시간 부여

4.혁신을 진행 중인 상태 -＞ 여유 부여

새로운 팀원을 충원하는 것은 팀의 결속 프로세스에 방해가 되므로 먼저 어느 정도 팀의 규모를 빠르게 키운 후 그 팀이 손발을 맞출 수 있는 시간을 주는 편이 훨씬 쉽다

본인의 팀의 상태를 파악하고 그에 맞게 팀을 조직해야 한다는데…

일반적인 중소기업에서 필요한 만큼 인원을 충원하거나, 업무량을 감소시킬 수 있는 매니저가 얼마나 있을까요? 특히나 초보 매니저라면…?

3.1 시스템적 사고

개발자의 속도(능력)는 다음의 4가지로 판단할 수 있습니다.

- 전달에 이르는 시간

- 배포 빈도

- 변화 실폐율

- 서비스 복구 시간

개개인 마다, 프로젝트 마다 다를 수 있겠지만 개발자의 능력을 이렇게 정량화할 수 있다는 것을 알게 되었고, 좀 더 구체적인 방법으로 업무에 적용시켜 보고 싶다는 생각이 들었습니다.

3.11 모델, 문서 그리고 공유

가장 까다로우면서도 흔한 리더십 시나리오는 권위를 내세우지 않고 이끄는 것이며 이러한 상황에서 놀라운 효율성을 발휘하는 스타일 중 하나는 모델, 문서, 공유 이다.

모델을 만들고 팀 내에서 작게 테스트 하여 효과적인 모델을 찾아낸다.

해결해야할 문제점 및 학습 과정, 도입과정 등을 상세히 기술한 문서를 작성한다.

이메일 등의 간단한 방법으로 문서를 공유한다.

우선 나의 팀에서 작은 규모로 시스템을 운영해보고 잘 되었을 경우 회사 전체로 전파시킨다라는 데서 공감이 된다. 어떠한 시스템을 회사에 전체적으로 도입하려면 경영진 및 각 팀에서도 반발도 많을 것이기 때문에 우선 테스트해보고 결과를 보여주며 이용을 유도하는 방법은 바람직하다고 생각된다.

4.3 여러분의 관리 철학

최고의 관리 철학은 변하지 않는 것이 아니라 현실과 마주하면서 계속 진화하고 있다. 최악의 관리 이론은 아무런 이론도 없는 것이지만 그 다음으로 최악은 변화를 수용하지 않는 것이다.

일관성 있는 관리 철학도 중요하지만 때에 따라 상황에 따라 변화하고 적응해야만 한다는 말에 전적으로 공감이 됩니다.

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

이 부분을 읽으면서...

우리 회사의 경우와 비슷하다는 생각이 들었다.

능력있는 사람이 한명 있는데... 일을 잘하다 보니 위에서는 계속 그 개발자에게 일을 시키게 된다.

이 개발자는 일을 받는데로 해결해 나가긴 하지만...

어느순간 번아웃이 와서 일에 대한 회의를 갖게되고

연구소 내에서는 시기의 시선이 가득차게 됩니다.

처음에는 이 개발자를 보고 대단하다고 생각하며 부러워 했었는데...

지금은 그 반대가 되었다는...

영웅 프로그래머를 없애고, 무너진 시스템을 재건 하라는 말은 깊게 공감이 가는 부분이다.

책을 읽고 나서...

이 책에서는 조직, 도구, 접근법, 문화, 경력 5가지 주제로 매니저먼트 기술을 소개하고 있다.

이 책은 제목에서 의미하는 것과는 다르게 초보 매니저를 위한 책은 아닌것 같다.

초보 매니저가 할 수 없는 내용도 많이 들어있지만…

그래도 유용한 정보들이 많이 들어 있습니다.

이 책은 초보 매니저 보다도, 중견 관리자에게 더 필요한 책이라고 생각됩니다.

그렇더라고 하더라도 조금이라도 매니지먼트에 대해 고민하고 있는 리더 및 관리자, 개발팀장 등등...

매니저가 되고자 하는 모든 분들은 꼭 일독을 권해드립니다.

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

매니지먼트란 대체 무엇일까? 읽고 나면 더욱 고민들이 깊어지지만 언젠가는 관리자의 길로 가야하지 않을까라는 생각을 하게 만드는 책이었다.

조직이란 공동의 목표를 위해 일하는 사람들의 집합이다. 각 조직은 수십, 수백 혹은 수천 명이 함께 가능성을 탐구하는 곳이다. 결국은 사람들이 모여서 일을 한다. 중요한 것은 사람이다.

4인 이하는 팀이 아니다! 꽤나 도발적인 멘트로 책의 도입부가 진행된다.

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

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

'타율이 잘나오는 타자의 폼을 바꾸려하지 말라.' 팀장님에게 들어던 여러 이야기들을 생각나게 하는 책이다.

각 장에서 다루는 주제들에 대해서 생각해보면 좋을거 같다. 그리고 책에서 참조로 나오는 책들도 참고하기에 좋다고 생각이 든다.