<div id="readability-page-1" class="page"><div>
					

회사에서 다른 리더들과 독서 모임으로 읽은 책이다. 책의 저자인 마이클 롭은 넷스케이프, 애플, 슬랙을 거치면서 리더로 성장한 경험을 에세이처럼 30장에 걸쳐서 조언을 제공하고 있다. 각 장은 다른 조언을 얘기하고 있어서 개별 장을 꼭 이어서 읽을 필요는 없고 모든 걸 다 따른다기보다 자신의 상황에 맞는 조언 혹은 습관만 적용하는 식으로 책을 읽을 수 있다.

리더십 책을 인상 깊게 보는 경우가 많진 않은 느낌이긴 한데 이번 책도 그렇게 인상 깊지는 않았다. 기본적으로 책이란 건 의식하든 의식하지 못하든 내가 고민하는 부분이나 가려운 부분을 긁어줄 때 좋다고 느끼기 마련이라 책을 읽는 타이밍 등이 중요하다고는 생각하는데 리더십에 대한 고민이 없다기보다는 대부분은 사람의 문제인 경우가 많아서 책에 나온 내용으로는 그리 도움받는다는 느낌을 못 받아서 그런 거 같긴 하다.

각 장은 꽤 짧은데 말하고자 하는 내용이나 예시가 잘 공감되지 않은 부분도 있고 너무 추상적인 말이거나 이어지지 않는 느낌도 있어서 책이 크게 좋게 느껴지진 않았다. 책보다는 같이 독서 모임을 하는 다른 리더들과 얘기를 나눌 수 있어서 좋았고 내가 그냥 지나친 내용을 다른 사람이 인상 깊게 느꼈다는 얘기를 들으면서 다시 한번 더 생각해 보게 되기도 했다.

책에서 인상 깊게 느꼈던 부분을 그래도 정리해 보면...

<blockquote>
 내가 특히 좋아하는 리더십 습관은 일대일 회의다. 일대일 회의의 전도사라고 불릴 정도다. 수십 년에 걸쳐 매주 일대일 회의를 진행했고 직속 팀원들과 매주 얼굴을 맞댔다. 일대일 회의는 함께 일하는 사람들 간의 신뢰를 구축하는 가장 단순하고 믿을 만한 방식이다. 팀 전체에 영향을 미치는 현재의 사건에 관해 폭넓은 대화를 나눌 기회이기 때문이다.
</blockquote>

일대일 회의는 사실 지금 있는 회사에서 거의 처음 해보고 있다. 뭐 리더 경험이 많지 않은 것도 사실이다. 그동안 내가 경력을 쌓으면서 일대일 회의를 하고 싶다거나 하는 생각을 별로 안 해서 그런지 나도 일대일 회의에 대한 가치를 아주 크게 느끼진 않고 있지만 회사에서 하고 있기도 하고 많은 책에서 권장하고 있어서 가능하면 일대일 회의는 미루지 않고 하려고 하고 있다. 여전히 일대일 회의에서 무엇을 논의해야 하는가 하는 어려움은 있지만 그래도 일대일 회의를 주기적으로 하면서(나는 지금 한 달에 한 번씩 하고 있다) 동료들의 상황을 파악할 수 있다는(어디까지 솔직히 얘기하는지는 알 수 없지만) 장점은 확실히 느껴진다.

<blockquote>
 팀장 회의 후에는 반드시 회의 내용을 팀원들에게 알려주어야 한다. 회의에서 무엇을 논의했는가? 이 일에서 무엇을 배워야 하는가? 이후에는 어떤 일이 생길까? 팀원 모두는 팀장급 회의가 열렸다는 사실을 알 뿐 회의에서 '무슨 일이' 있었는지는 모른다. 회의 내용을 팀원들과 공유하라. 리더로서의 '점수'를 거저로 딸 기회다.
</blockquote>

<blockquote>
 회의 내용을 모두와 공유하라. 그렇게 하면 의사소통 오류가 줄고 사내 정치에 대한 예방 접종이 되어 면역력을 키우는 데 도움이 될 것이다. 뿐만 아니라 예상치 못한 뜻밖의 행운이 찾아오리라.
</blockquote>

개인적으로 신경 쓰는 부분이다. 사안에 따라서 그러기 힘든 부분도 있지만 가능하면 결정이 나지 않더라도 어떤 논의를 하고 있는지 최대한 빨리 공유하려고 하고 있다. 그렇다고 회의 끝나고 팀원을 다시 모아서 회의를 여는 것도 어색하긴 해서 다음 정기 회의 때까지 기다리긴 하지만 그렇게 키워드를 공유해 놓는 것들이 나중에 진행되는 논의에서도 도움이 되는 것 같다.

<blockquote>
 나는 어떤 유형의 리더를 싫어하는지 정확히 말할 수 있다. 사람들이 즉흥적으로 행동하거나 반복할 수 없도록 또는 피드백의 여지를 주지 않으려 행동 하나하나를 짚어주는 리더가 싫다.
</blockquote>

이런 리더는 나도 싫다. 그래서 그러지 않으려고 더 노력하다 보니 어떤 면에서는 책임을 회피하고 있는 건가? 싶을 때도 있다.

<blockquote>
 리더로서 당신에게는 확실한 무기가 있다. 바로 축적된 경험이다. 축적된 경험이야말로 리더가 반드시 갖춰야 하는 자질이다.
</blockquote>

경험을 어디서 쌓는지가 문제이긴 하다. 또한 개인 엔지니어링 스킬과는 달리 경험을 쌓으면서 당연히 실패도 있고 실수도 있을 텐데 리더는 실패의 영향이 다른 사람들에게까지 더 많이 끼치게 되므로 조심스럽게 되고 조심스러워서 경험을 더 쌓기 어렵지 않나 하는 생각도 든다.

<blockquote>
 매사 사소한 것까지 관리하고 통제하도록 '기본값'이 설정된 리더는 속 빈 강정이다. 팀원들이 자기만의 경험을 구축하는 기술에 관해 하나도 배울 게 없기 때문이다.
</blockquote>

마이크로 매니징은 나도 너무 싫어하는 형태이다.

<blockquote>
 사람들이 자기 생각을 거리낌없이 나누도록 멍석을 깔아주자. 획기적인 아이디어가 언제 나올지 아무도 모른다. 팀원들이 리더인 당신의 아이디어에 반박할 공산이 낮다는 사실을 명심하라. 이것은 리더가 나중에 행동해야 하는 또 다른 명백한 이유다.
</blockquote>

리더와 팀원은 너무 나누는 건 별로 좋아하는데 또 전혀 경계가 없을 수 없기도 하다. 어려움 부분.

<blockquote>
 신참 관리자로서 스스로를 증명하고 싶은 의욕을 갖는 것은 당연하다. 그래서 당신은 모든 일을 자발적으로 떠안고 주구장창 야근을 하며 무리수를 둔다. 게다가 생전 처음으로 직속 직원들이 생겼으니, 그들에게 당신의 지위를 각인하는 동시에 좋은 첫인상을 주려고 젖 먹던 힘까지 짜낸다. 관리자가 되기 전 개별 기여자였을 때는 이런 접근법이 매우 효과적이었을 것이다. 그래서 당신은 팀의 리더일 때도 이 방법이 효과적일 거라고 단정짓는다.
</blockquote>

이렇게 되기 쉬운 거 같긴 하다. 나도 우리 파트에서 일어나는 일의 대부분을 파악하고 있으려고 하고 그렇기에 파트 규모를 늘리는데 조심스럽긴 하다. 당연히 흐름을 놓치지 않고 의사결정에 참여하려면 알고 있어야 한다고 생각하면서도 너무 많이 간섭하려고 하는 건 아닌지에 대한 걱정도 있고 어쩌면 내 능력 범위에 파트의 능력이 갇히는 건 아닌지에 대한 걱정도 있다.

<blockquote>
 관리자가 되었다고 해서 갑자기 누군가에게 당신의 일을 위임하려니 본능적으로 꺼려진다. 위임은 힘과 맥락을 잃는다는 뜻인 데다 당신은 그런 상실에 익숙하지 않다.
</blockquote>

업무에 따라 약간 다르긴 하지만 위임은 조금씩 익숙해지고 있는 것 같다.

<blockquote>
 이 순간 그 상황에 대한 전적인 책임을 통감하는 관리자라면 ‘나는’이라는 단어를 아주 많이 사용할 것이다. 또한 송곳같이 날카로운 질문을 퍼부을 것이다. 그런 질문에는 그것이 그가 해결해야 하는 그의 문제라는 인식이 담겨 있다. 어차피 자신도 윗선에서 어려운 질문을 받을 것이기 때문이다. 그 관리자는 책임감을 느낀다. 그러나 그가 사용하는 단어들 사이에 꽁꽁 숨고 그가 묻는 질문들의 뒤에 음흉하게 감춰진 속내가 있다. 그는 내가 이 일을 주도한 엔지니어라면 우리는 절대로 이런 상황에 처하지 않았을 것이라고 생각하는 것이다. 
 조심하라. 신뢰를 갉아먹는 소리가 들리는 듯하다.
</blockquote>

저런 생각이 들면 정말 힘든 것 같다. 또 모든 걸 맡기기만 하면 잘 되는 것은 아니기 때문에 어느 순간이 개입할 때이고 어느 순간이 기다려야 할 때인지가 어렵다. 그래도 요즘은 그런 고민을 거의 안 하기는 하는데 조직마다 성격이 좀 달라서 다른 조직에서는 또 어떨지 잘 모르겠다.

<blockquote>
 먼저 하기 어려운 말을 하는 법을 배우고, 그런 다음 듣기 힘든 말을 적극적으로 듣는 것이다.
</blockquote>

<blockquote>
 피드백이 아무리 비판적이더라도 주의 깊게 경청하고 그저 대략적으로라도 이해하도록 노력하라.
</blockquote>

듣기 힘든 말을 듣는 건 항상 사람으로서는 어려운 일이긴 하지만 제일 어려운 건 듣기 힘든 말도 할 수 있는 분위기인 것 같다. 기본적으로 비판적인 피드백이 없을 때 그럴 만한 일이 없는 건지 사실은 있지만 말을 안 하는 건지 판단할 수 없다고 생각한다. 보통은 후자일 가능성이 높을 텐데 그렇다고 말하라고 한다고 말하는 것도 아니니까...

<blockquote>
 소소한 일을 처리하느라 쉴 새 없이 움직이지만, 정작 결과를 놓고 보면 괄목할 만한 진전을 이뤘다는 기분이 들지 않는다. 이런 삶이 바로 테크 리더의 현실이다.
</blockquote>

수시로 이런 느낌이 드는데 테크 리더만 그런지는 잘 모르겠다.

<blockquote>
 엔지니어로서 나는 여전히 관리자들의 역할에 대해 회의적이다. 심지어 내가 관리자가 되어서도 그렇다.
</blockquote>

어느 정도는 동의한다.

<blockquote>
 서로의 견해에 동의하지 않는 것도 피드백이다. 따라서 우리는 서로의 의견에 효과적으로 반대하는 법을 배울 필요가 있다. 그 방법을 빨리 배울수록 서로를 더 빨리 (그리고 더 많이) 신뢰하고 존중하게 될 것이다. 아이디어는 합의를 통해 발전하지 않는다.
</blockquote>

중요한 말이다.

 </div></div>

Outsider's Dev Story

Outsider

실리콘밸리 리더십 - 애플 테크 리더가 들려주는 30가지 비법
    
          
          
            실리콘밸리 리더십 - 애플 테크 리더가 들려주는 30가지 비법 - ⭐⭐
            
마이클 롭 지음
김정혜 옮김
한빛미디어
원제: The Art of Leadership
          
        
회사에서 다른 리더들과 독서 모임으로 읽은 책이다. 책의 저자인 마이클 롭은 넷스케이프, 애플, 슬랙을 거치면서 리더로 성장한 경험을 에세이처럼 30장에 걸쳐서 조언을 제공하고 있다. 각 장은 다른 조언을 얘기하고 있어서 개별 장을 꼭 이어서 읽을 필요는 없고 모든 걸 다 따른다기보다 자신의 상황에 맞는 조언 혹은 습관만 적용하는 식으로 책을 읽을 수 있다.
리더십 책을 인상 깊게 보는 경우가 많진 않은 느낌이긴 한데 이번 책도 그렇게 인상 깊지는 않았다. 기본적으로 책이란 건 의식하든 의식하지 못하든 내가 고민하는 부분이나 가려운 부분을 긁어줄 때 좋다고 느끼기 마련이라 책을 읽는 타이밍 등이 중요하다고는 생각하는데 리더십에 대한 고민이 없다기보다는 대부분은 사람의 문제인 경우가 많아서 책에 나온 내용으로는 그리 도움받는다는 느낌을 못 받아서 그런 거 같긴 하다.
각 장은 꽤 짧은데 말하고자 하는 내용이나 예시가 잘 공감되지 않은 부분도 있고 너무 추상적인 말이거나 이어지지 않는 느낌도 있어서 책이 크게 좋게 느껴지진 않았다. 책보다는 같이 독서 모임을 하는 다른 리더들과 얘기를 나눌 수 있어서 좋았고 내가 그냥 지나친 내용을 다른 사람이 인상 깊게 느꼈다는 얘기를 들으면서 다시 한번 더 생각해 보게 되기도 했다.
책에서 인상 깊게 느꼈던 부분을 그래도 정리해 보면...
내가 특히 좋아하는 리더십 습관은 일대일 회의다. 일대일 회의의 전도사라고 불릴 정도다. 수십 년에 걸쳐 매주 일대일 회의를 진행했고 직속 팀원들과 매주 얼굴을 맞댔다. 일대일 회의는 함께 일하는 사람들 간의 신뢰를 구축하는 가장 단순하고 믿을 만한 방식이다. 팀 전체에 영향을 미치는 현재의 사건에 관해 폭넓은 대화를 나눌 기회이기 때문이다.
일대일 회의는 사실 지금 있는 회사에서 거의 처음 해보고 있다. 뭐 리더 경험이 많지 않은 것도 사실이다. 그동안 내가 경력을 쌓으면서 일대일 회의를 하고 싶다거나 하는 생각을 별로 안 해서 그런지 나도 일대일 회의에 대한 가치를 아주 크게 느끼진 않고 있지만 회사에서 하고 있기도 하고 많은 책에서 권장하고 있어서 가능하면 일대일 회의는 미루지 않고 하려고 하고 있다. 여전히 일대일 회의에서 무엇을 논의해야 하는가 하는 어려움은 있지만 그래도 일대일 회의를 주기적으로 하면서(나는 지금 한 달에 한 번씩 하고 있다) 동료들의 상황을 파악할 수 있다는(어디까지 솔직히 얘기하는지는 알 수 없지만) 장점은 확실히 느껴진다.
팀장 회의 후에는 반드시 회의 내용을 팀원들에게 알려주어야 한다. 회의에서 무엇을 논의했는가? 이 일에서 무엇을 배워야 하는가? 이후에는 어떤 일이 생길까? 팀원 모두는 팀장급 회의가 열렸다는 사실을 알 뿐 회의에서 '무슨 일이' 있었는지는 모른다. 회의 내용을 팀원들과 공유하라. 리더로서의 '점수'를 거저로 딸 기회다.
회의 내용을 모두와 공유하라. 그렇게 하면 의사소통 오류가 줄고 사내 정치에 대한 예방 접종이 되어 면역력을 키우는 데 도움이 될 것이다. 뿐만 아니라 예상치 못한 뜻밖의 행운이 찾아오리라.
개인적으로 신경 쓰는 부분이다. 사안에 따라서 그러기 힘든 부분도 있지만 가능하면 결정이 나지 않더라도 어떤 논의를 하고 있는지 최대한 빨리 공유하려고 하고 있다. 그렇다고 회의 끝나고 팀원을 다시 모아서 회의를 여는 것도 어색하긴 해서 다음 정기 회의 때까지 기다리긴 하지만 그렇게 키워드를 공유해 놓는 것들이 나중에 진행되는 논의에서도 도움이 되는 것 같다.
나는 어떤 유형의 리더를 싫어하는지 정확히 말할 수 있다. 사람들이 즉흥적으로 행동하거나 반복할 수 없도록 또는 피드백의 여지를 주지 않으려 행동 하나하나를 짚어주는 리더가 싫다.
이런 리더는 나도 싫다. 그래서 그러지 않으려고 더 노력하다 보니 어떤 면에서는 책임을 회피하고 있는 건가? 싶을 때도 있다.
리더로서 당신에게는 확실한 무기가 있다. 바로 축적된 경험이다. 축적된 경험이야말로 리더가 반드시 갖춰야 하는 자질이다.
경험을 어디서 쌓는지가 문제이긴 하다. 또한 개인 엔지니어링 스킬과는 달리 경험을 쌓으면서 당연히 실패도 있고 실수도 있을 텐데 리더는 실패의 영향이 다른 사람들에게까지 더 많이 끼치게 되므로 조심스럽게 되고 조심스러워서 경험을 더 쌓기 어렵지 않나 하는 생각도 든다.
매사 사소한 것까지 관리하고 통제하도록 '기본값'이 설정된 리더는 속 빈 강정이다. 팀원들이 자기만의 경험을 구축하는 기술에 관해 하나도 배울 게 없기 때문이다.
마이크로 매니징은 나도 너무 싫어하는 형태이다.
사람들이 자기 생각을 거리낌없이 나누도록 멍석을 깔아주자. 획기적인 아이디어가 언제 나올지 아무도 모른다. 팀원들이 리더인 당신의 아이디어에 반박할 공산이 낮다는 사실을 명심하라. 이것은 리더가 나중에 행동해야 하는 또 다른 명백한 이유다.
리더와 팀원은 너무 나누는 건 별로 좋아하는데 또 전혀 경계가 없을 수 없기도 하다. 어려움 부분.
신참 관리자로서 스스로를 증명하고 싶은 의욕을 갖는 것은 당연하다. 그래서 당신은 모든 일을 자발적으로 떠안고 주구장창 야근을 하며 무리수를 둔다. 게다가 생전 처음으로 직속 직원들이 생겼으니, 그들에게 당신의 지위를 각인하는 동시에 좋은 첫인상을 주려고 젖 먹던 힘까지 짜낸다. 관리자가 되기 전 개별 기여자였을 때는 이런 접근법이 매우 효과적이었을 것이다. 그래서 당신은 팀의 리더일 때도 이 방법이 효과적일 거라고 단정짓는다.
이렇게 되기 쉬운 거 같긴 하다. 나도 우리 파트에서 일어나는 일의 대부분을 파악하고 있으려고 하고 그렇기에 파트 규모를 늘리는데 조심스럽긴 하다. 당연히 흐름을 놓치지 않고 의사결정에 참여하려면 알고 있어야 한다고 생각하면서도 너무 많이 간섭하려고 하는 건 아닌지에 대한 걱정도 있고 어쩌면 내 능력 범위에 파트의 능력이 갇히는 건 아닌지에 대한 걱정도 있다.
관리자가 되었다고 해서 갑자기 누군가에게 당신의 일을 위임하려니 본능적으로 꺼려진다. 위임은 힘과 맥락을 잃는다는 뜻인 데다 당신은 그런 상실에 익숙하지 않다.
업무에 따라 약간 다르긴 하지만 위임은 조금씩 익숙해지고 있는 것 같다.
이 순간 그 상황에 대한 전적인 책임을 통감하는 관리자라면 ‘나는’이라는 단어를 아주 많이 사용할 것이다. 또한 송곳같이 날카로운 질문을 퍼부을 것이다. 그런 질문에는 그것이 그가 해결해야 하는 그의 문제라는 인식이 담겨 있다. 어차피 자신도 윗선에서 어려운 질문을 받을 것이기 때문이다. 그 관리자는 책임감을 느낀다. 그러나 그가 사용하는 단어들 사이에 꽁꽁 숨고 그가 묻는 질문들의 뒤에 음흉하게 감춰진 속내가 있다. 그는 내가 이 일을 주도한 엔지니어라면 우리는 절대로 이런 상황에 처하지 않았을 것이라고 생각하는 것이다.
저런 생각이 들면 정말 힘든 것 같다. 또 모든 걸 맡기기만 하면 잘 되는 것은 아니기 때문에 어느 순간이 개입할 때이고 어느 순간이 기다려야 할 때인지가 어렵다. 그래도 요즘은 그런 고민을 거의 안 하기는 하는데 조직마다 성격이 좀 달라서 다른 조직에서는 또 어떨지 잘 모르겠다.
먼저 하기 어려운 말을 하는 법을 배우고, 그런 다음 듣기 힘든 말을 적극적으로 듣는 것이다.
피드백이 아무리 비판적이더라도 주의 깊게 경청하고 그저 대략적으로라도 이해하도록 노력하라.
듣기 힘든 말을 듣는 건 항상 사람으로서는 어려운 일이긴 하지만 제일 어려운 건 듣기 힘든 말도 할 수 있는 분위기인 것 같다. 기본적으로 비판적인 피드백이 없을 때 그럴 만한 일이 없는 건지 사실은 있지만 말을 안 하는 건지 판단할 수 없다고 생각한다. 보통은 후자일 가능성이 높을 텐데 그렇다고 말하라고 한다고 말하는 것도 아니니까...
소소한 일을 처리하느라 쉴 새 없이 움직이지만, 정작 결과를 놓고 보면 괄목할 만한 진전을 이뤘다는 기분이 들지 않는다. 이런 삶이 바로 테크 리더의 현실이다.
수시로 이런 느낌이 드는데 테크 리더만 그런지는 잘 모르겠다.
엔지니어로서 나는 여전히 관리자들의 역할에 대해 회의적이다. 심지어 내가 관리자가 되어서도 그렇다.
어느 정도는 동의한다.
서로의 견해에 동의하지 않는 것도 피드백이다. 따라서 우리는 서로의 의견에 효과적으로 반대하는 법을 배울 필요가 있다. 그 방법을 빨리 배울수록 서로를 더 빨리 (그리고 더 많이) 신뢰하고 존중하게 될 것이다. 아이디어는 합의를 통해 발전하지 않는다.
중요한 말이다.
댓글 쓰기

[Book] 실리콘밸리 리더십 - 애플 테크 리더가 들려주는 30가지 비법

댓글