책 소개

리더 절대로 바쁘지 마라

감상

첫 인상

저자 소개를 보면 김종명님은 보증보험, 패션 업계에 리더로 일하셨고 업계에서 어떻게 일해왔는지를 알 수 있는 내용으로 각색하셨네 하는 느낌을 받았습니다.
실제 차장님, CEO 정도의 연령대의 이야기로 보고 뉘앙스를 이해해보았어요.
IT 업계쪽 리더보다는 역사가 있는 업계의 리더십 관련 서적으로 추천하면 좋을 것 같은 맛이긴 합니다.
(제가 보기엔 약간은 올드한 표현이나 상황들이 있었지만 고전을 읽는 느낌으로 읽었어요 😃)

눈치보는 리더가 성공한다, 공포의 시간을 견뎌라

책의 시작 쯤에 “눈치보는 리더가 성공한다”로 시작해서 팀원들이 어떤 상황인지, 어떤 부분에서 어려워하는지를 알고 지지해줄 수 있는 등, 리더는 살피는 사람이라고 이야기합니다.
그 외에도 팀원들이 스스로 잘할 수 있다는 것을 믿어야 팀원들이 잘 해낸다는 것과 팀의 설장을 위해 공포의 시간을 견뎌야하는 것도 좋은 이야기였습니다.

종종 리드로 일하면서 “저건 저렇게 하는게 맞을까?” 또는 “나라면…” 하는 생각을 하곤하는데,
처음에 방향성과 목표/목적을 팀원과 잘 맞추고 이후의 일은 팀원이 알아서 잘 할 수 있도록 지켜보고 장애물을 치우는 일을 하라는 이야기였습니다.

공포의 시간이라는 표현이 재미있었네요.
리더에게는 팀원을 지켜보면서 잘하고 있나? 저 방식이 괜찮나? 하는 생각도 들고 때때로 팀원들이 잘 할 수 있음에도 참지 못하고 끼어드는 경우도 있을 것이라 생각합니다.
그 공포의 시간을 잘 견디고 팀원들이 잘 나아갈 수 있도록 돕는 일을 해야한다고 이해했는데 돕는 것도 견디지 못하고 끼어드는 것이 아닐까? 싶은 생각도 들었습니다.

아무튼 팀원들의 상태, 상황을 잘 이해하고 팀의 성과를 낼 수 있는 방법은 눈치를 잘봐야한다 -> 센스가 좋아야한다 정도로 이해했습니다.

조직은 리더의 고민을 먹고 자란다 (시스템을 연구하라)

조직에서 일어나는 일들이 왜 그렇게 발생했는지, 어떤 부분을 개선하면 좋을지 등은 팀 모두가 고민하면 좋겠지만
리더가 먼저 고민을 하고 개선에 앞장서야한다는 내용입니다. 문제가 발생하면 사람에게 잘못을 이야기하기보다 시스템을 개선하고 연구해야한다는 것.

결국 조직이 어떻게 동작해야하는지, 팀의 일이 어떻게 동작해야하는지를 같이 고민하되 리더가 앞서서 고민해야한다고 이해했습니다.
이렇게 고민을 많이 할 수 있으려면 리더의 일은 팀원 업무 관심갖기, 팀의 성과 고민, 상위 조직 목표 고민/방향 맞추기 등을 많이 해야겠구나 싶습니다.
책 제목에 바쁘지마라고 했으나 실무가 많은 리더로 살아가고 있어서 현실성이 떨어진다는 생각도 드네요.
다만 바쁘게 자기 일만 하는 것은 줄이고 팀이 시너지를 낼 수 있는, 팀 에너지의 총합보다 더 큰 결과를 만들어낼 수 있는 시스템을 고민해야한다고 항상 생각은 합니다.
(행동이 생각을 따라가지 못해서 문제죠 ㅎㅎ 😂)

불평에 감사하라. 눈치보는 리더가 성공한다

다시 한번 눈치보는 리더가 성공한다고 수미상관으로 마무리합니다.
책의 예시로는 사업쪽 담당자가 보는 시야에서 비판하는 내용으로 디자인 실장이 그 비판을 수용하고 반영하는 이야기가 있었습니다.
약간 허구가 있는게 다른 팀의 실장님에게 비판적인 이야기를 쉽게 할 수 있을까? 싶긴했지만 이야기 뒤에 “실장님이 피드백을 잘 듣는다”는 설정이 있지 않을까 싶긴했습니다.

비판, 피드백 등을 잘 수용하는 리더, 눈치보는 리더가 성공한다는 이야기네요.
비판을 하지 않는 조직, 피드백이 없고 소통이 없는 조직은 목표를 달성하거나 성공하기 힘들겠죠. (물론 팀 목표가 무엇이냐에 따라 다를 수 있겠지만요)

마무리

김장수의 디자인 브랜드 런칭 TF에서 일어나는 이야기로 리더가 고민하고 생각해야할 것들을 이야기 형식으로 재미있게 다뤘습니다.
바쁘지 말아야한다는 제목을 해석해보자면 자기일에만 바쁘게 살지말고 팀을 생각하는 시간을 잘 지켜야한다 정도로 볼 수 있을 것 같네요.
사실 팀 생각하는 것도 바쁜 일에 한몫을 하는 것 같기도 한데요. 어쨌든 리더, 생각할 시간 없이 바삐 살지 말고 여유 시간 잘 챙겨야한다고 해석해보며 마무리해봅니다.

크래프톤 웨이 책 소개

• 크래프톤 웨이

크래프톤(블루홀)이라는 회사가 어떻게 시작되었고 살아왔는지 보여주는 책입니다.
경영진의 입장에서 게임 개발 회사가 성장보다는 어떻게 살아남았는지, 어떤 고민들을 했는지를 볼 수 있습니다.

책에 대한 소개는 링크에서도 보실 수 있으니 바로 감상평으로 넘어가겠습니다 😸

감상

책은 재미있게 술술 읽힌다!

시간순으로 내용이 작성되기도 했고 당시의 결정이나 고민들이 간접적으로 느껴져서 시간가는 줄 모르고 읽었습니다. (300장이 넘지만 3-4일안에 다 읽은 것 같네요)

한편으로는 경영자의 시야와 실무자, 직원 입장에서는 다르게 느꼈을 수 있겠구나하는 관점의 차이도 알 수 있었네요.

지금까지 알지 못했던 크래프톤(블루홀) 초창기 모습, 초기의 어려움을 알 수 있어 좋았다.

저는 2018년 초에 PUBG(펍지)에 입사한 사람이어서 당시 블루홀이 어떤 회사인지, 연합군은 무엇인지 사실 지금까지도 잘 알지 못했습니다. (관심이 크지 않았다고 말할 수 있겠네요.)

이 책을 보면서 회사 초기의 모습을 어렴풋이 알 수 있어서 좋았고 회사 초기 어려움들을 조금이나마 느낄 수 있어서 느낀점이 많았습니다.
(느낀점이 많다고는 했지만 모두 자세하게 나열하기는 어렵네요. ㅎㅎ)

• 블루홀의 뜻을 이제 알았고 블리자드와 연관된 것도 처음 알았네요.
• 종종 블라인드에서 크래프톤 경영진, 리더십에 대한 무책임함에 대한 이야기가 있었는데 이런 일들 때문에 그럴 수 있었겠구나 이해할 수 있었습니다.

블루홀의 비전이었던 “MMORPG 제작의 명가”는 지금 “제작의 명가”로?

책을 읽으면서 지금은 어떻지? 하면서 읽었네요. 지금 크래프톤에 있기에 그런 생각을 하면서 읽게된 것 같습니다.

우리에게 그 비전을 계속 이야기하고 있나? 어떻게 하면 모두가 그 비전을 동일하게 생각할 수 있을까?
스튜디오, 본부, 실(유닛), 팀으로 비전이 스며들어 있을까? 하는 생각이 들었습니다.

그리고 연합군이 목표했던 바를 이루고 있는가도 궁금해졌어요.
크래프톤이 퍼블리셔에게 단일팀보다 더 큰 존재가 되었는가, 경쟁우위가 생겼는가 말이죠.

책의 마지막 부분에서의 PUBG

크래프톤 웨이에는 대부분 블루홀 때의 이야기가 많았고 후반부에 PUBG, 지노 게임즈에 대한 이야기가 나옵니다.
이런 흐름만 봤을 때 책에는 지금까지 쓰여온 블루홀, 크래프톤의 시작에 대한 (경영자 시점의) 역사가 쓰여있습니다.

창한님이 크래프톤 CEO가 되고 그 이후의 길들은 또 다음 책에서 쓰여질 수 있겠네요.

마무리

저는 이 책을 회사에서 나눠주어서 볼 수 있었는데요. 나름 재미있게 보았습니다.
주변 스타트업에서 리드로 일하시거나 대표로 일하시는 분들은 다들 잘 읽었다고 하시는 것 같았는데
반대로 사측의 내용이 많다는 의견도 들었네요. 아무래도 경영자의 관점에서 풀어낸 책이어서 그럴 수 있을 것 같습니다.

두 측면에 이야기가 모두 이해가 되기도 해서 고민을 많이해볼 수 있어서 좋았던 책이었습니다.

테크니컬 리더 책 소개

• 테크니컬 리더
• Becoming a Technical Leader

원서는 1986년에 나왔고 2013년에 번역되어 국문으로 볼 수 있게되었습니다.
혁신, 동기부여, 조직화를 통한 문제 해결 리더십 라는 제목으로 소개되어있습니다.

짧은 소개

이 책에서는 앞서 짧게 소개했던 3가지(동기부여(M), 조직화(O), 혁신(I))를 통해 문제 해결 리더십에 집중합니다.
문제 해결형 리더십을 정의하고 MOI 모델을 만들어보면서 어떻게 문제를 해결해나갈지 각 장 마지막에 질문을 통해 고민해봅니다.

책 뒤에 있는 추천사에 김창준님이 적어주신 내용이 꼭 맞는 것 같습니다.

이 책은 읽는 책이 아니고 경험하는 책이다. 매 장 끝에 나오는 질문들 하나하나를 귀중히 여겨 고민해보고 직접 종이에 답을 쓰고, 믿을 만한 사람들과 그 답을 공유하고 토론하고, 또 해보라는 실험은 모조리 해보도록 노력하라.
그렇게 한다면 아마 여러분들은 나와는 매우 다른, 그러나 매우 유사한 어떤 경험을 하게 될 것이고, 이 책에게 그리고 와인버그에게 매우 고마워하게 될 것이다. - 김창준, 애자일 컨설팅 대표

물론 저는 PM으로 테크니컬 리더는 어떤 사람일까, 어떤 사람이고 싶은걸까 하고 궁금증에 읽어보아서 질문 항목을 성실히 답변해보지는 못했습니다.
다만, 질문 내용을 보았을 때 테크니컬 리더 뿐만 아니라 리더라면 고민해봐야할 내용이 많았어요.

책을 읽으면서 공부하고 이해한 내용을 중심으로 리뷰해보겠습니다.

MOI 모델?

맨 처음에는 MOI가 뭐야 했는데 사실 책 소개 앞에 이야기했던 혁신, 동기부여, 조직화였습니다 😂
하나하나 살펴보면 다음과 같네요.

• 동기부여(Motivation): 위협하거나 보상하거나, 밀거나 당겨서 관련 있는 사람을 움직이도록 만드는 일
• 조직화(Organization): 아이디어 실현이 가능하도록 만드는 구조
• 아이디어(Ideas) 또는 혁신(Innovation): 씨앗, 실현될 것의 이미지

책에서는 이 3가지에 집중해서 성공적인 테크니컬 리더로 나아가야하는 방향을 설명합니다.
각 2부(혁신), 3부(동기부여), 4부(조직화)에서 상세 내용을 다루고 각 장에서는 질문을 통해 내용들을 같이 고민해볼 수 있었습니다.

22장 변화 계획

다른 장들도 읽고 질문에 답을 해보는 것이 좋았지만 저는 22장이 기억에 남아서 따로 남겨봅니다.
(실제로 업무를 하면서 고민했던 점도 있었어요 ⭐️)

이 장에서는 혁신과 관련하여 변화에 대해 이야기합니다.
변화를 어떻게 이끌어나갈 것인가, 새로운 것에 대해 거부하는 자연스러운 현상을 어떻게 계획해서 극복할 수 있을까 등을 고민해봅니다.
책에 있는 방법을 살짝 공유해보면 다음과 같습니다.

1. 개인적 달성 목표를 세운다. 목표는 안전하고 새로운 것이며 스스로 해낼 수 있어야한다. 도달한 성과 수준을 곧바로 알 수 있어야 한다.
2. 첫날에는 성과의 기준선을 정한다. 그 다음 적어도 하루에 한번 연습하고 매일 일기에 진행 상태를 기록한다.
3. 마지막 날에는 성과를 보여줄 수 있도록 준비하고 달성을 위해 노력하면서 무슨 일이 일어났는지 이야기한다.

달성 목표, 계획을 세우는 것 자체가 어떤 것을 이루려는 방법을 배우는 것이라고 생각합니다.
어떤 변화를 위해서라면 변화하고자 하는 목표와 계획을 세우고 진행해야한다는 것을 알 수 있었습니다.
(어찌보면 되게 당연한 말인데도 정리해본적은 없다보니 새로운 것을 배운 느낌이긴하네요. 😂)

22장의 질문은 작은 기술을 매일 연습하고 기록하는 것, 지금까지 어떤 교육 과정에 참여하고 무엇을 배웠는지 등을 생각해보는 것이 있었습니다.
과거에 어떤 교육을 받았고 향후에는 어떤 교육을 받을 것인지도 질문에 있어서 계획을 세우고 공부해라 정도로 질문을 이해하긴했습니다.

이 챕터를 읽으면서 개인적인 달성 목표 매일 업무 일지(업무 회고)를 작성하는 것을 하고 있는데요.
사실 매일 일기쓰기 같은 느낌이어서 종종 피곤하면 빼먹고 몰아쓰기도 하고 있습니다.
마지막 날(매월 말일)에는 월말 회고를 계획하고 있는데 최대한 빼먹지 않고 열심히 써보려하고 있어요. 💪

테크니컬 리더: 테크니컬 리더를 위한 책

책 자체가 두껍긴 한데 테크니컬 리더가 어떤 고민을 하면서 살아가야하는지를 알려주는 책이라고 생각합니다.
질문 내용을 모두 고민하고 살기는 어렵겠지만 하나하나 실천해보면 좋은 리더로 나아갈 수 있지 않을까 싶었어요.

전에 리뷰를 작성했던 Book review: 개발 7년차, 매니저 1일차 이 책보다는 어렵다는 생각은 했습니다.
테크니컬 리더는 뭘해야하지? 어떤 고민을 하면서 살아야하지? 하는 고민을 크게 하시는 분들이라면 집중해서 읽어보기 좋을 것 같고,
리더가 된지 얼마 되지 않았다면 개발 7년차, 매니저 1일차를 입문서로 읽어보시는 것을 추천합니다. 👍

책 내용은 많았지만 제가 느꼈던 내용을 중심으로 짧게 책 리뷰를 해보았습니다.
저는 몇 가지 책갈피해둔 질문들을 리더로 일을 하면서 한번씩 되돌아보려고 합니다.
(테크니컬 리더가 아니더라도 일반적인 리더가 고민하면 좋은 것이 많아서요. 😈)

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

• yes24-개발 7년차, 매니저 1일차
• Oreilly-The Manager’s Path

추천

책 뒤에는 아래와 같은 사람들에게 추천한다고 되어있습니다.

• 개발자 VS 매니저 갈림길에 서있는 사람
• 개발자 관리를 체계적, 효율적으로 하고 싶은 사람
• 내 사수가 사수 역할을 못해서 내가 고생 중인 사람

정말 개발(여기서는 엔지니어링)을 해왔던 사람이 어느 날 팀을 맡았다면 어떤 것 부터 해야할지, 어떤 것을 고민하고 팀을 운영, 매니징해야하는지 하나하나 잘 설명해주었습니다.
어떤분들에게 어떤 내용들이 도움이 될지 간단하게 추천해보고자 합니다. (사실 서평처럼 써보려고 했으나 가볍게 추천한다고 보시면 될 것 같습니다. 😸 )

참고: 여기서 매니저는 “프로젝트 매니저”할 때의 매니저 보다는 팀장, 실장 등 엔지니어링 팀을 관리하는 매니저로 보시면될 것 같습니다.

주니어 엔지니어, 엔지니어링팀 팀원들을 위한 추천 장(챕터)

책에 있는 챕터 별로 매니저가 하는 일, 해야하는 일을 설명하고 있는데요.
그 중에서 주니어, 팀원들이 읽으면 좋을 만한 이야기들이 있는 장은 초반에 있는 장입니다. (+ 9 문화 개선 챕터)

• 1. IT 관리 101
• 2. 멘토링
• 3. 테크리드
• 4. 사람관리
• 9. 문화 개선

위 챕터들에서는 처음 매니저 업무를 시작하거나 어떤 커리어 패스를 고민해야하는지를 설명합니다.
1~4의 챕터들에서 많이 나오는 항목은 원온원(1 on 1) 미팅입니다.

원온원(1-on-1) 미팅

원온원 미팅은 팀장-팀원이 1:1로 업무, 개인 이슈 등 여러가지 이야기를 하고 피드백을 하는 미팅으로 이해해주시면될 것 같습니다.
이 원온원 미팅은 매니저가 주도적으로 할 수도 있지만 팀원도 같이 참여해서 어떤 이야기들을 할지 고민하고 참여해야한다는 점에서 주니어 엔지니어도 알아두면 좋을 내용이라고 생각했습니다.

주니어 엔지니어, 팀원들은 프로젝트 업무 외에도 커리어와 개인적인 일들을 매니저와 이야기할 수 있는 자리가 있어야합니다. 팀으로 같이 잘 일하기 위해서는 서로 공유해야하는 미팅이 필요하지요.
팀장, 팀원은 팀으로 일하기 위해 서로에게 신뢰를 쌓아야한다고 생각합니다. 잡담이나 티타임 정도로도 신뢰가 쌓일 수 있겠지만 팀으로 일하는데에 업무 신뢰도가 쌓이려면 조금 더 업무와 관련한 이야기를 집중해서 할 수 있는 자리가 필요하다고 생각합니다.
이러한 역할을 원온원 미팅이 할 수 있을 것으로 책에서 이야기하고 있습니다.

물론 어떻게 미팅을 진행하냐에 따라 신뢰를 잃을 수도 있겠지만요 😂

책에서는 원온원 미팅 처음을 어떻게 시작하면 좋은지, 어떻게 진행해나가면 좋을지를 짚어주어서 좋았습니다.
제가 완전히 주니어일 때 이 책을 보았다면 이런 것도 있군! 하고 팀장님에게 이야기하고 해봤으면 좋겠다고 이야기했을 것 같네요.

지금은 프로젝트 매니저로 일하고 있기에 어떻게하면 팀이 일을 잘 만들고 진행할 수 있을지를 더 많이 고민하고 있습니다. 😀

시니어 엔지니어, 팀장이 될 예정이거나 팀장인 엔지니어

사실 팀장이 될 예정인 혹은 팀장이 되었지만 어떻게 해야 할지 혼란스러운 엔지니어분들에게는 꼭 읽어보고 이런 방법도 있구나 하고 하나둘씩 적용해보았으면 좋겠습니다.
주니어 엔지니어에게 추천했던 챕터를 먼저 읽어보고 그 뒤로는 매니저 커리어 패스를 잡을 때 참고하면 좋을 것 같다는 생각을 했습니다.

추천하고 싶은 내용 중에서는 3장 테크 리드, 4장 사람관리를 추천하고 싶습니다. 엔지니어링 팀장을 맡으면서 태스크 관리나 팀원 관리에 대한 이야기가 튜토리얼로 해볼 만한 것들이 많았습니다.
예를 들면, 테크 리드의 기본 역할(주요 역할), 팀원과 관계 맺기 (신뢰 관계 구축하기) 등 매니저가 되면 어떤 것들을 신경 써야 하는지를 알 수 있는 내용들이 Getting Started와 같은 내용이라고 생각합니다.

여기서 원온원 미팅 스타일도 나열해주었는데 살펴보면 아래와 같습니다.

• 할 일 목록 점검 미팅: 업무 목표를 정리하여 논의하고 우선순위에 따라 각 업무 목표를 다룸.
• 팀원의 이야기 듣기: 팀원의 이야기를 듣는다. 다만 위로하고 불평을 듣기만 하는 자리라면 무의미해지는 것을 조심해야 함.
• 피드백 미팅: 비공식적인 피드백, 코칭 시간으로 활용. 개인 목표나 회사 내 목표 등 진행 사항을 같이 검토할 수도 있음.
• 진행보고 미팅: 프로젝트 세부 사항을 논의하는 시간이 될 수 있음. 프로젝트와 무관한 내용을 이야기하는 방법도 같이 해볼 수 있겠으나 상황에 따라 미팅 빈도를 줄이는 것도 고려해야 함.
• 인간적인 관계 강화 미팅: 팀원의 사생활 캐묻기가 아닌 팀원 개인에게 인간적인 관심을 갖고 이야기하는 것. 미래 목표를 묻는 것도 괜찮음.
• 다양한 방식으로 시도하기: 산책이나 커피, 점심을 먹으며 미팅을 할 수도 있음. 다만 민감한 주제를 이야기할 수 있도록 방음이 잘되는 회의실에서 하는 것도 고려해야 함.

여기서 마지막 조언으로 공유 문서에 미팅 노트를 작성해서 팀원들과 공유하는 것을 짚어주었습니다.
어떤 피드백을 받았는지 서로 알 수 있고 기억할 수 있는 점과 나중에 성과 평가할 때나 다른 피드백을 줄 때 기억하기 쉬운 점에서 조언을 주었습니다.

이후에는 좋은 매니저, 나쁜 매니저를 이야기하는데 이 부분도 추천하고 싶네요.

“좋은 매니저, 나쁜 매니저: 마이크로 매니저, 위임하는 매니저”를 제목으로 썼는데 정말 위임을 어떻게 해야 할까에 대한 내용은 “효율적으로 위임하기 위한 실질적인 조언”에서 볼 수 있었으니 참고하시면 좋을 것 같습니다.
맛보기로 부제들의 내용을 나열해보겠습니다. 어떻게 보면 누구나 말할 수 있는 내용일 수 있겠지만 초보 매니저로서 겪는 문제를 해결하는 데에 좋은 표지판이 될 수 있다고 생각합니다.

• 팀의 목표를 통해 어떤 세부 사항을 파악해야 하는지를 판단하라
• 팀원을 만나기 전에 시스템에서 정보를 수집하라
• 프로젝트 단계에 따라 확인할 부분을 달리하라
• 코드 및 시스템 표준을 설정하라
• 좋은 정보든 나쁜 정보든 중립적 태도로 정보를 개방하기

이후의 챕터들도 모두 참고할 만한 내용이 많으니 읽어보시면 좋을 것 같습니다.

마치며

처음으로 책을 읽고서 추천해봅니다. 사실 자기 계발서에 가까운 책이긴 합니다.
자기 계발서를 꺼려하시는 분들에게 말씀드리고 싶은 점은 매니저 튜토리얼 책으로 봐주시면 어떨까 합니다.
매니지먼트 책 중에서 엔지니어가 빠르게 읽고 적용해볼 수 있는 책이라고 생각합니다.

• 매니저로 일을 시작하면서 겪는 것이 엔지니어링 하면서 겪는 것보다 사람 관리, 팀 관리가 더 어려운 것 같습니다.
• 컴퓨터에 대한 문제는 구글링이나 스택오버플로우에 검색해보면 나오 기라도 하지.. 관리는 어떻게 하면 팀이 일을 잘하게 할 수 있을지 등 많은 것을 생각해야하기도하구요.

제가 이 책을 보고 크게 와 닿았던 것 중에 하나는

• 코딩, 개발 업무는 Quick Win이 가능하다.
  • 구현 후 빠르게 결과를 볼 수 있다는 것인데 이 이야기는 곧 빠른 피드백을 받아볼 수 있는 것
• 반면 관리(매니징)는 여러 요인으로 인해 Quick Win이 힘들다.
  • 때로는 조직의 복잡도로 인해 문제 해결이 오래 걸릴 수도 있고, 개개인의 사정이 있어 시간이 걸릴 때도 있고 등등
  • 이런 차이로 인해 엔지니어 업무를 하다가 매니징 업무로 가기 더 어렵기도 하다는 것

어렵지만 누군가 해야 하는 관리 업무를 모두가 잘 헤쳐나갈 수 있었으면 좋겠습니다. 🙏
매니저, 팀장이 되고자 하는 분들, 지금 팀장을 하고 있는 모든 분들이 이 책을 보고 매니저 업무에 도움이 되었으면 좋겠습니다.