개요

이 책[1]은 오래 전에 읽었던 것이다. 아래 내용들은 읽으면서 기억하고 싶은 내용들을 메모한 것이다 아메리컨 풋볼 코치로서 리더십에 관련된 내용을 정리한 것인데, 팀을 운영하는 사람으로서는 참고할 만한 내용이 많다. 

책 내용 요약

I. 리더가 될 준비를 하라

Ch1. 열정을 품고 시작하라.

내꿈은 고등학고 풋볼팀 감독이 되는 것이었다. 

Ch2. 돈보다 참된 스승을 쫓아라

. 블랑그린 주립대학 로이튼 페리, 노스웨서던 대학 애리 파사지언, 오하이오 주립대 우디 페이스

. 나의 스승들은 누구인가?

Ch3. 적당한 때를 기다려라.

. 지식을 최고의 코치가 되는데 사용했다.

 좋은 기회가 오기를 기다려라, 그리고 나머지는 모두 거절하라. 그러면, 상황은 완전히 달라질 것이다.

II. 주도권을 확보하라

Ch4. 첫날 부터 기준을 확립하라

리더가 되기 위한 준비! -> 이것이 역사를 바꾼다.

Ch5. 몸 담고 있는 곳의 역사를 존중하라

. 사람들에게 모든 것이 달라질 것이라는 찬물을 끼언어야 한다. 하지만, 단체나 조직에게 똑같은 행동을 하면 안된다.

Ch6. 정직하라

. 회사 스캔들 "저는 몰랐습니다."

  나중에 알게되도, 그것에 맞게 해야 한다.

. 정직하라

Ch7. 기대치를 명확히 제시하라

. 용건이 없는 회의는 소집하지 마라

1. 다른 사람을 존경하라

2. 정직하라

3. 자신의 성적에 책임을 져라

4. 외부인을 들이지 말라

5. 살아도 팀, 죽어도 팀, 팀만이 전부다

Ch8. 리더가 되려면 목표를 세워야 한다.

. 위에서 아래가 아니라, 목표를 달성할 책임이 있는 사람에게서 목표가 나와야 한다.

. 리더는 팀원들이 목표에 도달할 수 있도록 도와 주고, 목표가 무엇인지, 그 꿈을 이루기 위해서 무엇을 어떻게 해야할지 "매일" 일깨워야 한다.

. 일년에 한번 리더가 정한 목표를 보여주는 것은 의미가 없다.

. 팀의 목표는 팀원들이 정하며, 그것이 뼈에 사무쳐야 한다.

  팀원들에게 중차대한 책임감을 안겨줘야 한다.

  직원들에게 리더가 될 기회를 주는 것. 그것이 리더가 할일이다.

III 내 팀을 만들어라

Ch9. 나를 위해 일하겠다는 사람을 채용하라

. 미시건대에서 데리고 있던 36명의 코치들은 11명이 다른 곳의 감독이 되었다. 새로운 사람을 뽑으려고 하면,나는 그들에게 전화해서 마땅한 사람이 없는지 물어 본다.

. 현재하고 있는 일을 그만 두고 싶어 안달이 난 사람을 채용하는 일은 하면 안된다.

. 다른 곳에서 선수를 스카우트 하는 일보다는 코치를 면밀히 분석하는데 더 많은 시간을 투자해라

 가족들을 만나는 것도 중요하다. 배우자는 내조할 강건함이 있어야 한다.

Ch10. 참모진을 최대한 활용하라

. 참모진 만큼은 내 의사대로 끌고 갈 생각이 없다. 스태프 미팅에 참석하면, 너 나할 것없이 고함을 지르고 주먹을 내리치는 광경. 코치 한명을 일부러 골탕 먹일 때도 있다. 가장 좋은 것을 추려내기 위함이다.

. 우리는 우리가 무엇을 할 것인가, 그리고 그것을 어떻게 할 것인가에 대한 의견 일치 없이는 맹세코 단 한번도 필드에 나간 적이 없다는 사실

. 잠시 짬을 내서 주변에 벌어지는 일들을 되는데로 골라 이야기 나누면 인간적인 관계를 맺을 수 있다.

. 일단 책임자가 되면, 나는 채찍, 부관들은 당근이다. 일단 감독이 되면, 코치처럼 행동하면 안된다. 더 이상 보조가 아니다.

. 리더는 보좌진을 불리한 입장에 두게 하면 안된다.

Ch 11. 품성으로 사람을 뽑아라

. 재능이 중요하지만, 품성을 보고 선수를 뽑아야 두다리 뻣고 편히 잘 수 있다.

. 가장방문으로 잃는 선수보다 우리를 잃는 유망주가 2배 더 많다.

Ch 12 아랫사람을 리더로 키워라

. 그러히 않으면 혼자 모두 떠 맡아야 한다.

. 경찰관이자, 인생의 안내자가 되게 해야 한다.

. 선수들을 차별대우 했다는 점은 굳이 부인하지 않겠다.

Ch 13 스타 시스템을 폐지하라

. 사람을 다루는 법

  스타플레이어는 분수를 지키게. 중간 실력은 동기 부여, 실력이 처지는 친구는 성공에 기여하도록

. 당분간 나를 떠날 생각이 없는 선수라면, 최대한 능력을 발휘하게 한다.

Ch 14 중간 계층의 사기를 복돋워라

Ch 15 누구에게나 기회를 줘라

. 누군가 받아들이기 어려운 결정을 내려야 한다면, 그런 결정을 내릴 수 밖에 없는 이유를 설명해 주어야 한다. 당사자가 달가와 하지않겠지만, 이해해줄 것이고, 설명을 들은데에 대해서 고마운 마음을 품을 것이다. 방법은 간단하다. 진실을 이야기 해주는 것이다.

. 팀이 가진 능력을 최대한 이끌어 내려면, 별 능력이 없어 보이는 사람이라도 무엇인가 보여줄 수 있는 기회를 주어야 한다.

Ch 16 각자의 역할을 주고 가치를 인정하라

. 우리가 모든 선수들에게 준것은 시간과 관심.

Ch 17 불가피한 해고를 하려면 재빨리 단행하라.

. 단 한시간도 1분도 허투루 다루면 안된다.

 어떤 직업도 수련 과정이 필요하다. 그렇기 때문에 리더의 궁극적인 책임은 아랫 사람을 훈련시키는 것이다.

. 훈련을 계획 할 때, 최종 결과물을 생각해야 한다.

Ch 18 철저한 준비 태세를 갖추어라

.Staff, 선수, 연습, 모니터링, 연습 경기

  -> 25초라는 시간. 경기당 100번, 1년에 총 12경기

  -> 미리 조직화 하고 연습시키고 완전히 체득케 하는 일이다.

  -> 훈련은 최대한 실전에 가깝게 설계해야 한다. 일어나지 않을 것 같은 상황도 준비하고 훈련한다.

IV 문제는 신속하게 해결하라

Ch 19 남의 말을 경청하라

. 남의 말을 경청하지 않는 사람은 리더가 될 수 없다.

.내게 말하는 사람에게 귀를 기울이지 않는 것은 그 사람에게 나는 당신이 필요 없다라는 메시지를 전달하는 것이다.

Ch 20 아랫사람을 철저히 파악하라

.두려움을 버리고 선수들의 라커룸, 직원들의 현장속으로 걸어들어가야 한다.

.아랫사람을 파악

  - 어디 출신인지, 어떤 목표를 지향하는지?

  - 그들의 장점, 약점은 무엇인지? 

  - 하다 못해 그들이 입는 옷의 단추가 어떻게 생겼는지?

Ch 21 밤새 고민하지도 앙심을 품지도 말라

. 인사 문제를 오래 끌지 마라. 잘못되었다며 나중에 사과하면 된다.

V 중대한 고비를 정면으로 맞서라.

Ch 22 철저히 무너뜨리고 다시 일으켜 세워라

. 풀이 죽어 있을 때 아무 소리 하지 않는다

 기분이 고조 되어 있을 때, 찬물을 끼얹는다.

 약팀도 부풀렸다. 약체일수록 더 부플렸다.

Ch 23 혁신보다 제대로 된 실천을 강조하라

. 모든 것은 실천으로 귀결된다. 훌륭한 아이디어 보다도...

. 기본기가 잡혀 있지 않으면 구급기술도 할 수 없다.

  -> 지열대에 물건이 가지런히 놓여 있는지?

  -> 잘 팔리는 물건은 떨어지지 않게.

  -> 인사를 잘한다.

Ch 24 연설 대본은 찢어 버려라

. 연설을 잘하고 싶다면, 열정을 품고 있는 주제를 말해야 한다.

. 대본은 찢어 버려라. 마음에서 우러난 이야기를 하는 편이 백배 낫다.

Ch 25 현실에 기반을 두고 작전을 변경하라

. 같은 일을 고집하면 매번 같은 결과를 얻을 뿐이다. 다른 결과를 원한다면 다른 일을 해야 한다. 함게 일하는 보좌진의 말을 경청하고 기존의 작전을 변경하는 것은 절대 나약함의 상징이 아니다. 실패하는 작전을 고수하는 것이야 말로 나약함의 상징이다.

Ch 26 위기를 기회로 바꿔라

. "Sudden Change" 공이 상대에게 넘어 갔을 때, 좌절하지 않고 상대의 피를 말릴 수 있는 기회로 여겼다.

Ch 27 포화 속에서도 중심을 잃지 마라

.선수들의 눈과 귀가 열려 있을 대 최대한 활용해야 한다.

 실재 고객과 마주할 때 한참 중압감에 시달릴 때 몇미리는(??) 직원이 사회 생활을 하는 내내 중요한 지침이 되어 줄 것이다.

. 손수 모범을 보이는 일 또한 중요하다.

Ch 28 기본을 다시 세워라

. 감독을 오래 하다 보면, 한번쯤 실망스러운 해를 겪어야 하는 때도 온다.

. 문제의 핵심을 파고 들어 고쳐야 한다.

. 과거에 정립했던 기본 원칙에 맞춰 조직의 잘못된 면을 고쳐가면 간단하다.

Ch 29 세간의 비평은 무시하라

. 중요한 것은 조직원들의 생각이다.

돌아 보며...

이 책에는 인생 경험이 녹아있다. 아마도 인간적이며, 카리스마 넘치는 리더가 있다. 다분히 개인 특징이 있을 수도 있다고 생각한다. 내가 나로서 받아 들일 수 있는 부분에 대해서 좀 더 고민해 봄직하다.

참고문헌

[1] 보 스켐베클러, 존 U. "베이컨, 전설의 리더, 보", 서돌, 2008년 (원제 : Bo's lasting lessons)

업무를 하면서, 코드 리뷰에 대해서는 지속적으로 이야기가 많았다. 하지만, 나는 상당히 오랫동안 코드 리뷰를 하지 않았다. 실무를 하고 있을 때에는 Pair-programming을 하거나 하면서 사람들과 자연스럽게 코드 리뷰를 하거나 코드를 함께 논의 하는 경우가 많았다. 하지만, Project Lead를 하기 시작하고 실무와 거리가 생기면서 여러명이 큰 코드 변경 사항에 대해서 Offline으로 코드 리뷰를 하거나 하는것 이외에는 기회가 없었다고 할 수 있다.

최근에는 그룹에서 일어나고 있는 코드 리뷰 한 것들에 대해서 전반적으로 리뷰를 하게 되면서 코드 리뷰의 리뷰를 하게 되었다. 회사에서 이러한 전반적인 방향성을 받으면서, 가이드를 정리하게 되어 새롭게 느끼고 배우게 되는 부분을 정리해 본다. 

1. Coding Style

Coding Style은 코드 리뷰의 가장 기본적인 사항이다. Baseline이라고 할수 있다. 이는 언어의 특징을 이해하고 Readability를 위한 가장 기본이 되는 룰이다. 이에 관한 것은 회사 마다 다를 수 있다.

- Google Coding Style (Language-dependent): Android를 개발 하는 사람들에게는 기본룰이라 할 수 있다.

  Google 코딩가이드(Java, C++ 등 언어별): http://google.github.io/styleguide/

  안드로이드 기여자를 위한 AOSP 자바 코드 스타일: https://source.android.com/setup/contribute/code-style

- 회사 마다 다른 룰이 있을 수 있다. 하지만 기본적으로 읽는 사람을 위주로 만들어져야 한다.

2. 문화 관점

코드 리뷰는 상호 존중 문화가 기본이 되어야 한다. 함께 좋은 코드를 작성한다는 기준으로 리뷰를 작성해야 한다.

- You나 I 대신에 This code나 We를 주어로 리뷰를 한다. 우리가 리뷰하는 대상은 동료가 아니가 코드이고, 같이 해결해야하는 것이이 때문이다.

- 마침표나 느낌표 대신에 물음표로 리뷰하자. 지시보다는 제안이나 질문의 형태가 좋다. 리뷰어도 사람이라 실수가 있을 수 있고, 리뷰이의 마음에 상처를 준다면 안된다.

- 리뷰 의견 작성 시 질문이나 제안 위주로 작성한다.

- Merge되어도 좋다고 판단되는 경우  “수고하셨습니다” 또는 LGTM(Looks Good To Me) 등 코멘트 작성한다.

3. Review Skills

이제 스킬을 이야기 하는 것은 위에 것들이 정말 중심이 되기 때문이다. 코드를 리뷰하는 사람(Reviewer) 입장에서 뿐만 아니라 리뷰를 요청하는 사람 입장(Reviewee)에서도 스킬이 필요하다는 것을 알게 되었다.

- Reviewee

  + 코드리뷰 Description에 이슈, 체크방법 등 상세 기술

    내가 중점적으로 확인했으면 하는 부분에 대해서는 더 자세히, 필요한 링크가 있다면 그 부분도 포함하여 설명하는 친절한 요청이 좋다.

  + 패치는 짧으면 짧을 수록 좋다. 리뷰 시간이 줄어들고, 품질도 올라간다. 브랜치 머지때 merge conflic도 줄어든다.

    1시간 내 리뷰를 고려하여 Patch Set(Commit) 고민. (50 LOC 이하 & 6개 파일 이하 권장 )

    하나에 한가지 수정에 집중하는 것이 리뷰에도 편하다.

- Reviewer

  + 상대방을 존중 한다.

  + 선/후배 간에 격의 없이 리뷰 한다. 정말 이렇게 하기 위해서 문화가 만들어져야 한다.

  + 아래 다양한 관점에서 리뷰 한다. 특히, 자신의 강점 분야에서 리뷰를 하는 것이 좋다.

  + 지속적으로 다른 사람들의 좋은 리뷰를 보면서 배워야 한다.

- 다양한 리뷰 관점

  + 여러 사람들에게 피드백이 있어야 한다. 특히, 큰 변화/중요한 변화라면 더 많은 사람들의 리뷰 필요하다. 관련 모듈이 있을 경우 초대하여 리뷰 받는 것도 좋다.

  + 요구 사항 관점: 기능/비기능 요구 사항에 영향을 미치는 예상 결함에 대한 코멘트들이 제공. UX/GUI 가이드에 따르는 리뷰 코멘트도 중요하다.

  + Logic 적인 관점: Memory Leak 등 프로그램 로직 관점에서 리뷰도 기본적이라고 할 수 있다.

  + Architecture 관점: 코드의 구조적 개선에 의견이 코멘트 될 수 있다. (긴 함수, 중복 코드, 미사용 코드, 복잡도 등 뿐만 아니라, Design Pattern, Architectural Style 등 포함)

  + Domain Knowledge 관점: 기술 도메인에 따른 특징들이 반영된 코멘트들도 매우 중요하다.

  + 이슈 해결의 근본 원인: 문제점의 경우, 원인을 근본적인 원인을 찾아 내려는 토론 예를 들어, Null Check만 하더라도, 현상만 보지 않고 원인이 무엇인지 찾는 리뷰가 더 좋다.

마치며

다양한 측면에서 지속적으로 고민되어야 하고, 좋은 사례는 계속 공유되어야 한다. 이를 위해서 조직의 코드를 지속적으로 살피고 좋은 사례, 나쁜 사례, 중요한 사례가 지속적으로 공유 되어야 한다.

이 글은 어느 강의를 듣고, 거기서 인용한 YouTube Link[1]를 찾았고, 추가 검색을 통해서 트랜스크립트[2]도 찾아서 이를 번역한 것이다.

첫번째 추종자

리더십과 변화에 대해 많이 배웠다면, 3분 내의 비디오로 변화가 처음 부터 끝까지 어떻게 일어어나는지 보고, 몇 가지 교훈을 살펴 봅시다.

리더는 혼자여서 우스워 보일 수도 있는 배짱이 있어야 합니다. 하지만, 그가 하는 일은 매우 간단합니다. 배우기 쉽습니다. 이것이 핵심입니다. 따라 하기 쉬워야합니다!

이제 첫 번째 추종자가 결정적인 역할을 합니다. 그는 모든 사람에게 공개적으로 어떻게 따르는지를 공개적으로 보여줍니다. 리더는 그를 평등하게 그 사람으로 받아들이므로 더 이상 지도자만의 것이 아니라, 그 들의 것, 즉 복수의 것이 됩니다. 첫 번째 추종자가 친구들에게 함께 하자 부르는것을 알 수 있습니다.

첫 추종자가 되려면 용기가 필요합니다! 당신은 눈에 띄고 용감하다 조롱을 받을 것입니다. 첫 번째 추종자가되는 것에대한 리더십은 저평가 되어 있습니다. 첫 번째 추종자는 고독한 괴짜(Nut)을 리더로 변화시킵니다. 리더가 부싯돌이라면 경우 첫 번째 추종자는 불꽃을 일으키는 불꽃입니다.

두 번째 추종자는 전환점입니다. 첫 번째 추종자가 성공했다는 증거입니다. 이제는 고독한 괴짜가 아니며 둘의 괴짜가 아닙니다. 셋은 군중이고 군중은 뉴스입니다.

변화는 공개되어야합니다. 외부인이 지도자뿐 아니라 그 이상을 보게하십시오. 새로운 추종자는 지도자가 아닌 추종자를 모방하기 때문에 모든 사람이 추종자를 볼 필요가 있습니다.

이제 여기에 두 명이 더옵니다. 그리고, 세 명이 더옵니다. 이제 모멘텀이 생겼습니다. 이것이 티핑 포인트입니다! 이제 변화가 생겼습니다!

더 많은 사람들이 참여 할 수록 더 이상 위험하지 않습니다. 그 들이 이전에 울타리 밖에 있었다면 지금 참여하지 않을 이유가 없습니다. 조롱받지 않고 눈에 띄지 않으며 서두르면 군중 속의 일원이 될 것입니다. 다음 순간에는 참여하지 않아서 조롱 당하기 때문에 군중의 일부가되기를 원하는 나머지 사람들을 보게 될 것입니다.

그리고 신사 숙녀 여러분, 이것이 변화가 이루어지는 방식입니다! 배운 내용을 요약 해 보겠습니다.

당신이 처음의 벌거벗은 춤추는 사람이라면, 처음 몇 명의 추종자를 동등하게 키우는 것이 중요하다는 것을 기억하십시오.

공개적으로 따라 가기 쉽게 해야 합니다!

그러나 여기서 가장 큰 교훈을 아셨습니까?

리더십은 과장되었습니다.

그렇습니다. 셔츠가없는 남자부터 시작해서 모든 크레딧을 얻었지만 실제로 일어난 일을 보세요.

고독한 괴짜를 리더로 변신 한 것은 최초의 추종자였습니다.

첫 번째 추종자가 없으면 변화는 없었을 것입니다.

우리는 모두 리더가 필요하다는 말을 들었지만 실제로는 효과가 없습니다.

정말로 관심이 있다면 변화하는 가장 좋은 방법은 용기있게 따라가는 방법을 다른 사람들에게 보여주는 것입니다.

훌륭한 일을 하는 고독한 괴짜를 발견하면, 용기있게 일어 서서 참여하는 첫 추종자가 되도록하십시오.

참고 링크

[1] Leadership Lessons from Dancing Guy: The First Follower, https://youtu.be/Z61W5d2ePpw

[2] Derek Sivers, First Follower: Leadership Lessons from a Dancing Guy, https://sivers.org/ff 

역할 기반(Role-based)와 위계 기반(Rank-based)조직에 대한 이야기가 주변에 들리기 시작한 것은 벌써 한 두 해 전이다. 회사 내부에서 이야기가 나오기 시작했고, 외부에서도 Facebook[1]을 통해서 듣게 되어 이에 대해서 알아 두어야겠다고 생각이 들었다. 하지만, 둘에 대한 비교만 있지 정보가 충분하지는 않았다. 많은 사람들이 이에 대해서 글을 쓰기 시작했고, 참고 할 만한 내용들이 있는 것들을 여기에 정리해 본다.

Rank vs Role driven [2]

위계기반(Rank-driven) vs. 역할기반(Role-driven)

아래 표는 두가지 조직 체계를 비교 한 것이다.

가장 큰 차이점은 결정과 책임이 어디에 있느냐이다. 모든 것에 대한 결정과 책임이라기 보다는 역할 기반 조직에서 담당자가 책임 져야 하는 역할, 업무, 제품에 대해서 결정권과 책임에 관한 것이다. 요즘과 같이 복잡한 상황에서 상사가 모든 결정을 한다면 결정 시간에 너무 많은 시간이 소요되고 기회를 잃게 되는 경우가 발생할 수 있다. 반대로, 여러 고려 요소로 인해 여러 담당자가 의견이 충돌해서 결정이 되지 않는 경우라면, 이 또한 기회를 놓칠 수 있는 상황이 될 수도 있다.

위계 기반 조직은 실행에 초점을 맞추고 있다. 위의 예와 같이 이해 관계자들의 충돌이 있을 경우, 상위 랭크에 있는 사람이 빠르게 결정을 내리고 실행할 수 있다. 역할 기반 조직은 담당자들의 책임과 아이디어를 통해서 혁신이 일어날 수 있도록 환경을 만들어 주는 것을 목표로 하는 것이 목표이기도 하다.[2]

실제는 어떨까?

이분법적으로 역할 기반 혹은 위계 기반 조직으로 실제 회사를 분류할 수는 없다[3]. 단지, 어느 쪽에 좀 더 치우쳐 있는가가 될 것이다. 위의 내용은 역할과 눈에 보이는 위계에 대해서 중심으로 이야기 했다. 이를 다른 측면으로 보기 위해서 역할 대신 네트워크 측면으로 눈을 돌려 보자. Management 3.0[4]에서는 팀의 설계 측면에서 소통이 네트워크를 따라 흐르기 때문에 기존 결정(Decision-making)을 위한 위계 구조와 정보 흐름을 위한 네트워크가 필요하다고 강조하고 있다.

네트워크와 계층[4]

결국은 팀을 구조화 하기 나름이지만, 사람들이 많아 질 수도록 위계(Hierarchy)가 생기게 된다. 또한, 위계가 있다고 하더라도 네트워크(Network)는 위와 유사한 형태로 생겨나게 되고 이 흐름이 좋을 수록 정보 공유가 원할하게 된다.

정리해 보면...

역할 기반 조직이라는 것은 결국은 위계 보다는 이 네트워크가 활발하게 되게 하고, 위계에서 생기는 권한(Authority) 혹은 의사 결정(Decision-making)권이 위임(Delegation)되어야 하는 것이다. 어느 것이 더 좋은 것인지 가치 판단 보다는 어느 것이 더 적절할 것인지가 맞는 질문이다. 많은 기업들이 급변하는 환경에 적응하기 위해서 창의적인 결과물들을 내기 위한 역할 기반 조직 체계로 가고자 한다. 하지만, 약육강식의 세계에서 역할 기반 조직만으로 살아 남을 수 있을지는 여전히 고민해야 하는 부분일 것이다.

참고 문헌

[1] 실리콘밸리를 그리다 에어비앤비 유호현, https://www.facebook.com/tyzapzi/videos/701114140250462/UzpfSTEwMDAwMDYzMTU5Njc5NDoyMDY2MTE2MTMzNDE5NDIw/

[2]구글과 애플의 조직문화, 역할 조직과 위계 조직, https://www.midashri.com/blog/rank-and-role

[3] '구글'과 '애플'의 조직 문화는 어떻게 다를까?, https://www.huffingtonpost.kr/svillustrated/story_b_18925876.html?ncid=engmodushpmg00000003

[4] Jurgen Appelo, "Management 3.0- Leading Agile Developers, Developing Agile Leaders," Addison-Wesley (한국어판, 조성빈 역)

더 읽어 보기

위계 조직과 역할 조직, https://brunch.co.kr/@svillustrated/6

대기업 Aaron과 실리콘 밸리 Bryan, https://brunch.co.kr/@svillustrated/12

"팀이 빠지기 쉬운 5가지 함정" 이 책은 절판된 상태이다. 그래서, 구하려면 헌책을 뒤져야 한다. 예전에 구할 수 있는 가격 보다 일반적으로 더 높다. 이는 구하고자 하는 이는 많이 않을지 몰라도 정말 찾아서 보는 이가 있어서 인지, 실재로 구하려 할 때 실재 가격 보다 더 주고 사야만 했다.

책에서는 새로운 CEO가 보드 멤버들을 만나면서어떻게 팀을 만들어 가는지 이야기를 통해 풀어 낸다. 이야기 속에서는 책에서 말하고자 하는 이런을 설명하고 있다. 여기에서는 공동의 목표를 찾아 내는 것만 아니라 이를 향해 나아가면서 맞이하게 되는 5가지 함정을 이야기 하고 이와 관련된 법칙을 설명한다.

팀을 위기에 빠뜨리는 5가지 함정

책에서는 아래와 같이 5가지 함정을 설명하고 있다.

팀을 성공으로 이끄는 5가지 법칙

이 함정을 반대로 접근하면 팀워크를 높일 수도 있다는 것이 책에서 설명하는 바다.

1. 첫 번째 법칙 팀원 간에 서로를 신뢰한다.
2. 두 번째 법칙 논쟁이 벌어졌을 때 거리낌 없이 의견 충돌을 일으킨다.
3. 세 번째 법칙 한번 내려진 결정과 실행 계획에 헌신을 다해 노력한다.
4. 네 번째 법칙 정해진 계획에 어긋나는 행동을 했을 경우 책임을 묻는다.
5. 다섯 번째 법칙 공동의 목표를 이루는 데 초점을 맞춘다.

재미 있는 것 중에 하나는 논쟁에 관한 것이다. 즉, 의견에 대한 충돌 관련이다. 대 부분의 경우 충돌을 일으키게 하는 것이다. 하지만, 결정이 내려지면 거기에대해서는 헌신을 한다는 것이 특이한 것이다. 책에서는 "동의하지 말고 헌신하라"라는 말이 있다. 

다른 이야기들

책에서는 여러 도구나 설명을 하는데, 아래 내용들은 인상적이어서 추가로 기술해 둔다.

개인사 알기 

책에서는 개인사를 알아서 팀원들이 가까와 지는 다섯가지질문을 가지고 있다.

1. 고향은?
2. 형재관계는?
3. 어린시절 즐겼던 취미는?
4. 자라면서 겪은 가장 큰 시련은?
5. 처음 가졌던 직업은?

이와 같은 질문을 통한 이야기는 팀원들을 가깝게 느끼게 한다. 하지만, 이 것만으로 신뢰 관계가 구축되지는 않는다.

신뢰의 구축

신로의 구축은 장점과 약점 찾기, 그리고 의견 충돌을 통한 결정 내리기가 그 부분을 차지하지 않는가 싶다. 책에서는 이러한 과정을 통해서 팀원을 떠나 보내기도 하고 다시 받아들이기도 하면서 단단해 진다고 이해가 된다.

개요

이 글은 한글로 번역된 책[1]의 내용을 읽고 난 글이다. 이 책은 여러 글을 모은 것이고, 여기서는 2장인 "성장과 시장"의 내용을 주로 하여 정리한다. 이 책은 이 2장 이외에도 해커 문화라고 하는 Open Source의 역사에 대해서도 설명하고 있다. 이러한 Open Source의 역사는 [2]에서도 만화로 잘 설명되어 있어서 틈이 나면 읽어 보는 것도 좋겠다.

성당 모델 vs 시장 모델

책에서는 2가지 소프트웨어를 개발 방식을 소개 한다.

• 상용 소프트웨어의 '성당" 모델
• 리눅스 세계의 '시장' 모델

사실 성당 모델은 상용 뿐만 아니라, Open Source 혹은 자유 소프트웨어 (Free Software)를 만드는 초기에도 적용되었다. 초기 Unix 기반의 Open Source들도성당을 건축하듯이 만들어 져야 한다고 믿었다. 특히, Emacs등은 그렇게 만들어 졌다. 

성당 모델에는 다음과 같은 특징으로 만들어 졌다.

• 몇몇의 도사 프로그래머 혹은 작은 모임의 뛰어난 프로그래머에 의해서 조심스럽게 만들어 진다.
•  때가 되기 전에 발표되는 베타판도 없이 만들어 진다. 

이와는 다르게 시장 모델은 Linux가 만들어지면서 다음과 같은 방법으로 만들어 졌다.

• 일찍, 그리고 자주 발표 한다.
• 다른 사람에게 위임할 수 있는 것은 모두 위임한다.
• 뒤 범벅이 된 부분까지 공개한다.

파트타임으로 해킹하면서 인터넷이라는 가느다란 선만으로 연결된 전 세계 수천명의 개발자에 의해서 만들어 진다. 리눅스는 '충분히 많은 사람이 있다면, 찾을 수 없는 버그란 없다'라는 생각으로 만들어 졌다. 그러면서, 리눅스 아카이브 사이트가 이것을 시장 같은 개발 모습을 보여준다 

Open Source 프로젝트도 처음 부터 시장 방식으로 개발할 수 없다는 것은 자명하다. 테스트, 디버깅, 그리고 개선은 시장 방식으로 할 수 있다. 개발자 공동체는 초기에 실행하고 테스트할 수 있는 장난감이 필요하다. 초기에 해야 할 것은 잠재적인 공동 개발자들에게 이것이 머지 않은 미래에 정말 괜찮은 무언가로 진화할 수 있다는 것을 이해 시키는 일이다

격언들

저자도 fetchmail이라는 Open소스를 만들면서, 시장 모델을 도입하였고, 거기서 발견한 격언들을 아래와 같이 정리하였다.

1. 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로 부터 시작된다.
2. 좋은 프로그래머는 어떤 프로그램을 만들어야 할지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할지 그리고 재사용해야 할지 안다.
3. '갖고 있는 것을 버릴 계획을 세우라. 언젠가는 버리게 될 것이다." (프레더릭 브룩스, "맨먼스 미신" 11장 중에서)
4. 절절한 태도를 갖고 있으면, 흥미로운 문제가 당신을 찾아갈 것이다.
5. 프로그램에 흥미를 잃었다면, 프로그램에 댛나 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다.
6. 사용자를 공동개발자로 생각하면 코드가 다른 어떤 방법보다 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.
7. 일찍 발표하고 자주 발표하라. 그리고 사용자의 소리에 귀를 기울여라.
8. 충분하게 많은 베타 테스터와 공동 개발자가 있으면, 거의 모든 문제는 빠르게 파악될 것이고 쉽게 고치는 사람이 있게 마련이다. ('보는 눈이 충분하게 많으면, 찾지 못할 버그는 없다.' - "Linus's Law")
9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대 경우보다 훨씬 잘 작동한다.
10. 베타 테스터를 가장 종요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어 준다.
11. 좋은 아이디어를 생각해 내는 것 다음으로 중요한 일은 사용자가 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 나을 수도 있다.
12. 종종 가장 충격적이고 혁신적인 해결 책은, 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못돼 있다는 것을 깨닫는 것에서 나온다.
13. "설계에서 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다."
14. 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았떤 용도에 알맞게 된다.
15. 어떤 종류든 게이트웨어 소프트웨어를 만들려고 한다면 데이터 스트림에 가능한 한 최소의  조작만 가하라. 그리고 수신자가 강제로 하게  하지 않는다면 정보를 '절대로' 잘라 버리지 마라.
16. 언어가 '튜링-완전(Turing-complete)'하지 않다면 구문상의 유연성이 필요하다.
17. 보안 시스템은 그것이 보호하려는 비밀만큼만 안전하다 가짜 비밀에 주의 하라
18. 재미있는 문제를 풀어보고 싶다면, 자신에게 재미있는 문제를 찾아 나서는 것부터 시작하라.
19. 개발 조정자가 최소한 인터넷만큼 좋은 매체를 갖고 있으면 강제력을 사용하지 않고 어떻게 이끌어야 할 지 알고 있따면, 한 명보다는 여러 명의 지도자가 필연적으로 더 낫다.

마치며...

이미 많은 상용 Software도 Open Source를 기반으로 만들어 지고 있고, 위와 같은 시장 모델도 채용하고 있다. 어떤 개발 모델이던지, 그대로 받어 들이는 것 보다는 왜 그런지 어떻게 다르게 할 수 있는지를 고민하면서 채용해야 한다. 결국, 개발 조직이나 개발 프로세스도 이전과는 다르다. Agile이 그 하나이고, 상용 Software에 대한 Beta Testing도 이와 일맥 상통하고 있다.

References

[1] 에릭 레이먼드 지음, 정직한 외 옮김, "성당과 시장", 한빛 미디어

[2] 만화로 나누는 자유/오픈소스 소프트웨어 이야기, http://joone.net/

이력서: 경력의 재무제표

부서에 새로운 후배가 들어왔다. 신입인력으로 아직 경력은 낮았지만, 학교에서 Programming 경진 대회를 계속 나가는 개발 분야에 관심이 많은 친구이다. 그리고, 온지 얼마 되지도 않아 회사의 Programming Certificate를 Professional Level까지 획득하였다. 일도 차근 차근 배워 가는 모습을 보이고 있었다. 이친구와 이야기를 나눌 때였는데, 무엇을 해야 할지 잘 모르고 멈춰있다는 생각이 들었다. 개발자가 되어야겠다는 방향성은 있지만, 무엇을 해야할지를 잘 모른다는 느낌이었다. 그래서, 경력 관리를 위해서 이력서를 쓰라고 이야기 했다. 다른 회사를 가기 위해서만 이력서를 쓴다고 생각했던 후배는 조금 놀란 눈치였다. 아직 시작도 하지 않은 것 같지만, 예전 부터 해오던 내 기억과 새롭게 글을 찾고 읽어 보며 공부 하면서 공감이 가는 내용들을 여기 정리해 본다.

사실, 이력서 혹은 Resume를 새로운 회사에 지원하기 위한 문서이다. 하지만, 실재 내용은 내가 가고 있는 경력 상의 목표, 현재 상태를 보여주는 스냅샷과 같다. 회사의 경우는 대차대조표, 재무상태표 혹은 재무제표와 같다고 볼 수 있다. 그렇기 때문에, 나의 경력 관리를 위해서도 지속적으로 이력서를 써보는 것이 중요하다고 생각한다. 어릴 때, 용돈 관리하는 수준에서 자신이 돈을 벌기 시작했다면 제무제표를 관리하면서 어떻게 자산을 관리할 것인지 고민해야 한다. 경력도 마찬가지이다. 학교를 졸업하고 이제 직업을 선택하여 시작하였다면, 어떻게 이 직업에서도 성장해 갈 것인지 고민이 필요한 것이다.

관리자의 입장: 부메랑 직원

관리자의 입장에서 후배 직원에게 이력서를 쓰라고 이야기 하는 것은 어떤 의미일까? 대 부분 어떤 의도인지 모른는 경우가 많고, 심지어 다른 곳에 가라는 의미로 파악하는 사람도 있는 것 같다. 그렇기 때문에 이를 잘 설명해야 하는 부분이 있다. 꼭 가라는 것이 아니고, 정말 좋은 기회가 무엇인지 같이 살펴 보자는 것이다.

관리자 입장에서 직원을 유지(Retain)하는 문제는 쉽지 않다. 자연 감소적인 부분도 있지만, 새로운 기회를 찾아 떠나는 나에게는 어려운 부분이었다. 하지만, 요즘 들어 사원들이 복귀(Return)하는 경우를 종종 보게 된다. 상황이 바뀌고 있는 것이다. 한 글에서는[1] 2/3이상의 젊은 밀레니엄 근로자들은 직업을 자주 바꾸는 것이 도움이 된다고 생각하고 있다고 합니다. 이의 기저에는 자기 개발 욕구가 깔려 있다 것을 알아채는데는 어렵지 않다.

직원의 자기 개발에 대해서 관리자-직원 양자관계는 매우 중요하다. 또한, 관리자가 직원의 성장을 위해서 다른 곳으로의 이직도 포함되어 있다는 것을 보여 주는 것이 필요하다는 의견이다. 이는 관리자가 직원을 위해서 가능한 모든 옵션을 고려한다는 것을 보여 주는 방법이라는 뜻이다. 더 상세히 말한다면,  양자 관계에서 제시할 수 있는 조건 중에는 조직 내에서 성장할 수 있는 한계가 있다고 하면, 다른 곳에서 일할 수 있도록 하는 공동의 노력까지 포함한다는 것이다. 아이러니하게도 이는 결국 매니저 자신에게도 도움이 된다고 설명하고 있다. 이것이 직원의 복귀(Return)에 관여할 수도 있고 이러한 부메랑 직원(Boomerang Employees)이 늘어 나고 있다는 것도 보여 주고 있다. 

Basic Contents: 커리어 목표, 경험 그리고 스킬셋

이력서이든 경력 관리를 위한 것이든 먼저 정리되어야 하는 것이 커리어 목표(Career Goal, Career Objective)이다. 이는 자신이 다다르고자 하는 꿈[2]이라고 표현하는 사람도 있다. 그리고, 이를 위한 경험 그리고 스킬셋이 셜명되면 된다. 이 경험과 스킬셋이 부족하다면 이를 채울 방법을 고민해야 하는 것이다.

이력서도 문서이다. 어떤 문서라도 읽는 사람들을 고려해서 작성해야 한다. 즉, 채용 담당자들이 주목하는 부분[3]을 눈에 띄게 명료하게 사용해야 한다. 채용 담당자들은 많은 이력서를 살펴야 하기 때문에 10초 안, 대부분 6초에 이력서 하나를 본다고 하고, 아래 내룡을 주로 본다고 한다.

• 이름
• 현재 직장과 직책, 시작일
• 이전 직장과 직책, 시작일과 종료일
• 학력 수준
• 스킬셋

앞에서도 말했지만, 위의 내용은 결국 자신의 경력 목표(Career Objective)를 지지하는 뼈대이다. 커리어 목표가 주제이므로 이 것이 분명해야 하고 그 내용이 경험과 스킬셋에 녹아 들어야 한다.

CEO의 면접 질문[4]은 어떻게 내용을 담아야 하는지 혹은 어떻게 준비를 해야 하는지를 를 잘 보여 주어 추가한다.

. "당신의 상사, 동료, 팀은 당신을 어떤 사람이라고 설명할 것 같습니까?"

. "최종적으로 당신이 꿈꾸는 직무는 무엇입니까?"

. "지금까지 가장 어려웠던 문제는 무엇이고, 어떻게 해결했습니까?"

Killer PM Resume: 어떻게 다듬어야 하는가?

이는 PM 강의[5]를 들었을 때 나왔던 Resume에 관한 이야기 이다. 많지 않지만, 중요한 포인트가 있어서 옮겨 놓는다. 단지 3가지이다.

• 이력서에 키워드를 다듬어라 (Tailor your resume to fit job description)
• Relevant keywords and phrases (For passing applicant tracking system)
• Never Submit the same resumes, Always: Submit customized resumes
• Use Key Words: 이 것이 자기 분야에 대한 주요한 키워드를 사용하는 것이 중요하다.
• 경험이 없는 경우는 어떻게 해야 하는가? Side projects를 수행하고, 업무도 관련 있는 것을 찾아서 해야 한다.
• Build your own app, Redesign a website, Beta test products for free, Join a Startup Weekend or Hackathon
• 업적을 수치화 하라 (Quantify your accomplishments) 
• Check how many numbers in your achievements. Give your accomplishments more credibility
• Examples
• Sales volume, Increase in conversion %, Increase in market share, Increase in profitability, Number of direct reports, Number of people managed, Size of teams led, Number of products launched, % of increased efficiency, Process improvement %, Number of patents,
• "Designed the fastest mobile ticket purchase flow in industry, reduced number of steps to purchase by 50%+"
• "Invent 3 digital ticket technologies (2 patents pending) Successfully scoped, designed, executed, launched product with less than $10,000."
• "Recruited and led sales team to forge partnerships with over 40 restaurants in Standford, Berkeley, and Davis."
• Words for alternatives: 이 부분들도 큰 도움이 된다.
• First, Only, Best, Most, Top, and Highest
• Convey your brand
• 기본을 지켜라 (Basics again)
• No typos
• No Personal Information (사진, 정치, 종교, 취미)

위의 3가지를 염두해 두고, Resume를 계속 업데이트 해야 한다. 이러한 내용을 만들기 위해서 업무 목표가 잡혀야 하고, 필요한 경우 Side Project를 해야 한다.

예제: 개발자의 이력서

우아한 형제들의 구인본님의 예제[6]이다. 무엇 보도도, 첫 페이지에 Impact가 있다. 빠진 내용없고, 개발자로서 보여주어야 할 역량을 잘 보여주는 것으로 판단된다. 무엇보다도 이 이력서의 뒤에는 자신감이 배어 있어 이 부분이 너무 좋다. 하지만, 좀 과하다는 느낌을 거두기는 어렵다. 그렇기에 조금 건조해야 할 상황이라면, 빼야 하는 부분도 있다.

References

[1] Why I Encourage My Best Employees to Consider Outside Job Offers, https://hbr.org/2018/09/why-i-encourage-my-best-employees-to-consider-outside-job-offers

[2] 커리어브릿지가 알려주는 취업준비 방법 - [커리어 목표], http://careerbrdg.tistory.com/1286

[3] 10초 안에 채용 담당자를 사로잡는 영문 이력서 쓰기, http://blog.weirdx.io/post/1349

[4] CEO의 면접 질문, https://hrbulletin.net/talent-management/ceo%EC%9D%98-%EB%A9%B4%EC%A0%91-%EC%A7%88%EB%AC%B8/

[5] The Complete Product Management Course, https://www.udemy.com/the-complete-product-management-course/

[6]이직초보 어느 개발자의 이력서 만들기, http://woowabros.github.io/experience/2017/07/17/resume.html

우리 조직에 어벤저스 팀이 필요할까?

Google의 Project Oxygen과 Project Aristotle을 알게 된 것은 "우리조직에 어벤저스 팀 필요할까?"[1]라는 글을 통해서였다. 이 글은 개인 능력들이 좋은 어벤저스의 멤버들과 같은 팀원들이 있다면 조직이 효과적으로 운영이 될 것인가라는 질문을 던지는 글이라고 볼 수 있다. 사실 개인 능력들이 좋다고 해서 팀의 결과가 항상 좋은 것은 아니다. 그렇다면, Google이라는 세계 최고의 기업의 팀의 Leader들은 어떻고, 그의 팀은 어떻게 효율을 만들어 내는가? Google이 알아낸 비밀을 살펴 보자.

Project Oxygen: What makes great manager

한 때, Google에서는 매니저들을 다 없애는 것을 고려 했다고 한다. 그런데, 도리어 문제가 심각해져서 결국에는 그 이유를 분석을 했다고 한다. 이것이 

2008년에 진행한 

Project Oxygen[2]이라고 한다. 팀장급 이상에 관한 자료 100종류, 1만 건 이상을 수집해 ‘좋은 리더야말로 조직의 산소’와 같다는 뜻으로 좋은 리더의 요건을 알아내기 위해 분석하였다. 이를 통해서 좋은 리더가 가지는 10가지 조건이 추려졌다. (처음에는 8가지였다고 한다. 

행동 3과 6은 업데이트되었고 행동 9와 10은 새로운 것이다.)

1. 좋은 코치인가
2. 팀에 권한을 부여하고 마이크로 매니지먼트를 하지 않는다
3. 성공과 복지에 대한 관심을 나타내는 포괄적인 팀 환경 조성한다
4. 생산적이고 결과 중심적이다
5. 좋은 커뮤니케이터인가? 정보를듣고 공유한다.
6. 경력 개발 지원 및 성과에 대해 논의한다
7. 팀에 대한 명확한 비전 / 전략이 있다
8. 팀에 조언을 제공하는 핵심 기술 능력이 있다
9. Google에 여러 팀들과 공동 작업을 한다
10. 강력한 의사 결정자이다.

직원들은 기술적인 우수성(전문성)을 가진 리더도 중요하다고 생각하지만, 1대 1 미팅을 자주 만들어 대화하고, 직원들의 삶과 경력관리에 관심을 가져주는 리더를 선호한다고 한다. 즉, 좋은 리더가 되려면 업무능력과 인간미를 균형 있게 갖춰야 한다는 것이 Project Oxygen의 결론이었다.

Project Aristotle: 5 secrets of team's effectiveness

Project Aristotle(아리스토텔레스 프로젝트)[3] 는 Project Oxygen 이후 효과적인 팀의 비밀을 밝혀 내기 위해 진행 한 것이라고 한다. 이는 Google의 180개의 팀을 인터뷰해서 정량적, 정성적인 분석을 통해 얻어는 결과이다.

1. 그 첫 번째가 심리적 안전(Psychological Safety)이다. 이는 팀원이 팀 내의 대인 관계에서 두려워하지 않고 기꺼이 위험을 감수할 수 있는지에 대한 것이다. 예를 들자면, 자신의 실수를 이정하거나, 질문을 하거나, 새로운 아이디어를 제안하는 것이 다른 사람을 난처하게 허가나 자기가 처벌받지 않을 것이라는 확신을 가지는 것이라 설명하고 있다.

2. 두 번째는 신뢰성(Dependability)이다. 팀 멤버가 제시간에 일을 해낼 수 있느냐 하는 것이다. 반대의 경우는 책임을 회피하는 것과 비교할 수 있다.

3. 세 번째는 조직 구조와 투명성(Structure & Clarity)이다. 팀 멤버의 업무 기대(Job Expectation)과 목표(Objectives and Key Results)에 대한 이야기이다. 업무 기대(Job Expectation)은 사실 Job Description을 의미하는 것으로 보인다. 즉, 개인에게 기대하는 업무 내용이라 할 수 있다. 이를 기반으로 한 특정 기간 내의 목표와 주요 결과를 이를 달성하는 것으로 보여 진다.

4. 네 번째는 일의 의미(Meaning)이다. 즉 일이나 결과의 목적의식을 찾는 것이 팀의 효율성에 중요하다는 의미이다. Why를 찾는 것이라고 할 수 있겠다. 

5. 마지막은 일의 영향력(Impact)이다. 지금하는 일이 회사와 사회에 어떤 영향을 주고 어떤 변화를 가져오는지 알게되어, 자신이 어떻게 기여하고 있는지 알게 될 수 있다.

 

위의 순서는 중요도 순이다. 즉, 첫 번째 항목이 나머지의 가장 기본이라고 볼 수 있다는 것이다. 이것이 전제되지 않으면 개인은 역량을 발휘하지 못하며 팀의 신뢰도 무너진다. 위 그림이 이러한 내용을 잘 보여 준다.

결론은?

앞에서 Google에서 진행한 Project Oxygen과 Aristotle을 통해서 좋은 리더와 좋은 팀에 대해서 살펴 보았다. 좋은 리더는 업무 뿐 아니라 팀원의 직원들의 삶과 경력관리에 관심을 가지고 있어야 한다는 팀원들의 생각을 알 수 있었다. 효율적인 팀은 여러가지 특징이 있었지만, 무엇 보다다 심리적인 안정감을 가지고 있는 것이 기본이 었다. 이를 기반으로 책임과 목표를 가지고 업무를 수행할 수 있어야 한다. 이는 일의 의미와 영향을 팀이 잘 이해하는 것이 중요하다는 것을 알 수 있다.

이러한 결과는 늘 그렇듯이 흉내 내거나 따라만 한다고 되는 것은 아니라 생각된다. 표면 위에 나와 있는 속에 숨은 뜻에 대해서 파악해야 하겠다. 즉, 이것이 끝이라기 보다는 숨어 있는 핵심이 무엇인지 고민을 시작해야 한다. 조금 지나서 이 글을 살펴 보니, OKR이 보이고, 다른 것들도 조금씩 더 보이기 시작한다. 더 생각하고 필요하면 업데이트를 게속해야 할 것이다.

References

[1] 우리 조직에 어벤저스팀이 필요할까?, https://blog.naver.com/summerxmas/221241241058

[2] Great managers still matter: the evolution of Google’s Project Oxygen, https://rework.withgoogle.com/blog/the-evolution-of-project-oxygen/

[3] Guide: Understand team effectiveness, https://rework.withgoogle.com/print/guides/5721312655835136/

발표자[1]는 김창준님으로 거의 초창기 국내 XP를 소개하고 Agile Consulting을 하는 분이다. 

중요한 것은 미신이기 때문에 틀리다는 것이다.

아래는 발표의 요약이다. 

1. 프로그래밍을 잘하는 것과 협업을 잘하는 것은 별개이다.
   (Sonnentag 연구, Frey, Osborne 연구): 사회적 요소의 중요성, 사회적 지능, 협상, 설득, 타인을 돕고 돌보는 것.

2. 팀의 퍼포먼스는 협업이 아니라 가장 뛰어난 사람이 결정한다.
   (Woolley, Chabris, Pentland 연구): 팀내의 문화의 중요성. MIT Wooley 연구. CQ(집단 지능) 결정항목 3가지 중 2가지가 공감력과 말을 골고루 하는 것. Google 아리스토텔레스 프로젝트. 심리적 안정감의 중요성.

3. 전문가들을 모아두면 협력을 잘 할 것이다.
   (Woolley, Gerbasi, Charbis 연구): 의식적인 협력의 중요성. 일을 시작하기 전에 어떻게 협력할 것인가, 일하는 방식에 대한 논의 하는 것이 중요함.

4. 협업을 잘하는 것은 서로 좋은 관계를 유지하는 것이다.
    (Stephens, Carmeli 연구): 갈등에 대한 처리. 신혼 때 적게 싸운 부부들이 이혼할 확률이 높다. 갈등을 잘 처리하지 못한다.

5. 분업을 잘하는 것이 협업을 잘하는 것이다.
   (Salas 연구, Hackman 연구): 팀 vs 워크 그룹. Peer Review.

선문답 같지만,, 이 내용에 대해서 내가 무의식적으로 그냥 믿고 있지는 않은지 생각해 봐아겠다.

[1] 협업에 대한 5가지 미신, http://agile.egloos.com/5904102

테크니컬 리더" [1]를 알게 된 것은 회사 도서관에서 우연한 기회였다. 동기 부여와 성장에 대해서 고민하고 있던 나는 이 책을 몇번이고 대출을 연장하고서도 결국에는 별도로 구매하게 되었다 교과서 공부하듯, 요약 정리를 하게 되었고, 여기에 정리해 보고자 한다. 여기서는 2부까지의 내용 중에서 내 마음에 와 닫는 부분을 정리해 본다. 상세한 내용은 역시 책을 읽어 보기를 권한다.

역자는 조승빈님이라는 분인데, Agile에 관심을 많이 가지고 있고, 최근에는 같은 회사로 옮기셔서 세미나와 Agile Meetup에서 얼굴을 가까운 곳에서 뵙고 있다. 

테크니컬 리더가 하는 일

책에서 테크니컬 리더들은 혁신의 가치를 통해 사람들의 능력을 발휘하게 하는 사람이라고 정의 하고 있다. 여기서 혁신은 좀 더 좋은 방법으로 무엇인가를 한다는 가치라고 설명하고 있다. 문제 해결형 리더들은 다음 3가지에 대해서 특히 노력한다고 한다.

  . 문제를 이해하기

  . 아이디어의 흐름을 관리하기

  . 품질을 유지하기

각 항목에 대해서도 행동 양식에 대한 상세한 내용은 책을 참조하도록 하자. 이 항목들은 이미 수행하고 있는 것들도 있을 것이다. 새로운 것들은 곱씹어 볼 필요가 있는 부분들이다.

리더는 어떻게 만들어 지는가?

책에서는 리더가 되기 위해 변화가 일어나는 방식을 이해하는 것을 강조하면서, 모델을 자기가 경험한 것을 빗대어 설명한다. 자신의 Career와 관련된 발전이라기 보다는 저자 자신이 개인적으로 좋아하는 핀볼 게임(쇠구슬을 플리퍼를 이용하여 점수를 내는 게임)의 점수의 향샹 경험에 빗대어 설명하고 있다. 이 부분은 개인적으로 내 영어 능력의 발전에 대해서도 유사한 경험을 했고, 공부를 좀 한사람이라면 공감이 가는 부분이기도 하다.

저자가 제시하는 모델은 반복되는 두 개의 주요 단계로 이루어진다. 즉, 느린 성장을 하는 고원(Plateau) 단계와 빠른 성장을 하는 협곡 (Ravine) 단계이다. 이 단계들은 반복되는 싸이클을 형성한다. 아래의 왼쪽 그림이 모델을 설명하는 성장 곡선(Growth Graph)이다. 오른쪽은 실재 게임 점수에 관한 것이라고 설명하고 있다.

이 성장 곡선을 설명하는 3가지 포인트는 다음과 같다.

. 연습을 통한 완벽

연습은 느린 성장 단계에 해당, 연습이 도움이 된다는 것은 의심할 여지가 없다.

. 큰 도약

대부분의 성장은 한 고원에서 다른 고원으로 갑작스러운 도약을 통해 이루어지고 있다. 돌파구는 게임을 더 잘하기 위해 새로운 아이디어를 생각해 낼 때 찾아 왔다.

. 협곡으로의 추락

더 좋은 전략을 위한 아이디어가 있더라도 함정에 빠질 수 있다.고원의 앞쪽에는 협곡이 있다. 실력을 향상시키려고 할 때마다 약간의 퇴보를 겪기 전에는 큰 도약을 경험할 수 없었다. 이미 잘하고 있는 방법에서 벗어나서 협곡으로 떨어질 위험이 이쓴 곳을 향해 발을 딛고 선자리를 떠나야 한다.

사실 게임이기 때문에 점수로 환산되어 분명한 부분이 있다. 하지만, 기술적인 성장은 점수화 하기 힘들다. 그렇기 때문에 책에서도 성장의 느낌을 설명한다. 이를 사실에 기반한 세부사항 보다 더 밑을 만하다고주장한다. 또한, 만족감은 고원 단계의 중간 정도에 있을 대 못볼 수 있는 흔한 느낌이라 이야기 한다.   힘든 오르막길에서 살아남았지만, 아직도 배우는 중이며, 그것을 정체된 상태라고 이야기 할 수 없다이야기 한다.

고원-협곡 모델을 사이클을 설명하고 있지만 메타사이클(소라집과 같은 나선 구조인 사이클에 대한 사이클)에 대해서도 설명하고 있다. 저자는 하나의 협곡을 극복했을 대 단순히 새로운 고원으로 올라선 것만이 아니고, 성장 과장 그 자체를 학습함으로써 계속해서 더 높은 메타고원으로 몇발자국 올라섰던 것이다. 그러면서, 이러한  메타학습을 이루기 위해서는 협곡에서 살아남아야 한다고 주장한다.

혁신을 방해하는 세가지 큰 장애물

처음에 이야기 했듯이, 여기서 혁신은 좀 "더 좋은 방법으로 무엇인가를 한다는 가치"로 정의 하고 있다. 이를 수행하는데 방해가 되는 세가지 장애물을 자신에 대한 무지, 문제 없어요 증후군 그리고 단 하나의 해결책만 존재한다는 믿음이라고 이야기 하고 있다.

. 자신에 대한 무지

다이어트를 하면서, 자기가 무엇을 먹는지 모르는 사람과 같다고 이야기 한다. 많은 프로그래머들이 자신이 잘못된 생각에 사로잡혀서 엉뚱한 곳에서 오랫동안 하나의 오류를 찾아 해맨다. 스스로를 볼 수 있는 유일한 방법은 다른 사람을 통해서이다. 즉, Feedback을 통해서 이를 벗어 날 수 있다고 생각할 수 있다.

. '문제없어요' 증후군(No-Problem Syndrome, NPS): 두 번째 장애물

이 부분도 스스로 알기 쉽지 않다고 이야기 하면서, 4단계 조기 진단법을 제시하고 있다.

1. 자신이 갖고 있는 아주 어려운 문제를 설명한다.

2. 상대방에게 ' "문제 없어요!"라고 말한다.

3. 당신은 "대단한데요? 그러면 그 문제를 내게 다시 설명해 주실 수 있나요?"라고 말한다.

4a. 만약 상대방이 그 문제를 설명해 준다면, 비록 설명에 문제가 있더라도 NPS가 아니고 그냥 열정의 증거 뿐이다.

4b. 만약 상대방이 문제 그 자체가 아니라 해결책을 설명해 준다면, 유감스럽게도 NPS에 걸린 사람이다. 모두를 위해 할 수 있는 최선의 선택은 그저 슬며시 웃으면서 가장 가까운 출구로 힘차게 걸어나가는 것이다.

. 단 하나의 해결책만이 존재한다는 믿음: 세번째 장애물

문제해결형 리더가 되고자 하는 사람들에게 이러한 사고방식을 믿는 것은 자신을 쇠약하게 만드는 질병이며 문제 해결형 리더가 되는 데 세번 째 쟁애물이 라고 이야기 하고 있다..

자기 인식을 높이는 방법

책에서는 자기 자신을 바꿀 수 있는지 충분한 동기를 가지고 있는지 테스트하는 방법을 제안하고 있다. 바로, 3개월간 5분씩 일기를 작성하는 것이다. 나도 몇번 시도하였지만, 정말 쉽지 않다. 이 내용은 습관 만들기[2]와 일맥상통한다. 즉, 변화에 대한 시작을 하더라도 체화 하기 위한 기간을 3달로 하고 있다. 또한 내가 생각하기에 중요한 부분은 멈추게 되더라도 다시 시작하는 것이다. 나도 몇번을 멈추었지만, 일기 쓰기는 다시 시작하고 있다. 내가 하는 공부와 마찬가지이다.

. 언제 쓰는가? 

5분간 방해 받지 않은 시간에 한다. 또한 쓰고 싶다는 마음이 들지 않을 때 쓰는 것이 더욱 중요한 일. 스스로를 관찰할 시간을 꼬박꼬박 마련하기 어렵다면, 리더십 개발은 중대한 어려움에 처해 있는 것이다.

. 무슨 내용을 써야 할까

대부분, 사실(fact), 감성(Feeling), 발견(Finding)이라는 공식에 따르면 된다. 5분 일기 쓰는 것은 다른 책이나 인터넷에서도 회자 되고 있다[3].

일기의 역할은 모든 내용이 자신과 관련되어 있어서, 무엇을 배울 수 있을지 가르쳐 주지는 못하지만 무언가를 배우게 될 것이라는 것만 장담한다고 한다. 즉, 자신에 대해서 배우게 되는 것이다.

아이디어의 힘 키우기

문제해결형 리더십은 "모든 문제에는 아직 아무도 찾아내지 못한 다른 해결책이 존재한다는 믿음에서 시작한다. 아이디어에 의한 리더십이기 때문에, 아이디어의 힘을 키우는 전략도 필요하다. 아래는 책에서 설명하는 전략들이다.

. 창조적 오류

실수/실패를 통해 아이디어를 얻는 것을 이야기 한다. 책에서는 모든 실수는 준비된 사람에게는 새로운 아이디어나 다름 없다고 이야기 하고 있다.

. 훔친 아이디어

책에서는 표절(한사람의 아이디어를 훔치는 일)과 조사(많은 사람들의 아이디어를 훔치는 일)로 구분한다. 특히, 저자는 조사의 방법을 좋아하며, 이를 "나의 일을 전부 다른 사람들이 하도록 만들 수 있다"라고 말한다.

. 훔친 아이디어의 변형

다른 사람의 아이디어를 오해하면서, 그것이 새로운 아이디어가 되는 것을 말하고 있다.

. 결합

두개의 아이디어가 각각의 원래 아이디어 보다 훌륭한 것을 만들어내는 결합의 가치를 보여준다.

엔지니어, 혹은 Research하는 사람과 같이 아이디어를 만들어 내야 하는 사람들이라면, 위의 내용들은 생소하지 않다. 도리어, 친숙하다고 할 수 있다. 새로운 아이디어는 갑자기 하늘에서 떨어지지 않는다. 마치 창작하는 사람들의 뮤즈를 만나는 것과 같이 열심히 지속적으로 하고 있을 때, 갑작스럽게 찾아 오는 것과 같다.

비전

일기는 단기적으로 자신을 돌아보는데 도움을 준다. 이력선은 자신의 전체 이력을 그림으로 그려봄으로써 장기적 안목을 얻을 수 있도록 해준다고 설명하고 있다. 그리는 방법은 시간에 흐름에 대해서 자신의 감정은 높낮이를 그리는 것이다. 책에서는 여기서 중요한 것이 사건이 아니고 사건에 대한 반응이 중요하다고 한다.

감정이 낮아 지는 침체는 외부 요인 혹은 자신의 결점으로 인한 것일 수 있다. 혹은, 아무런 문제가 없는 데 침체가 일어나기도 한다. 때로는 성공으로 인해 너무 높은 곳까지 올라갔기 때문에 많은 조건을 바꿔 침체가 일어나기도 한다. 이러한 이유로, 실패하지 않기 때문에 리더가 되는 것이 아니라 시래에 반응하는 방법 때문에 리더가 되는 것이다. 성공한 리더들은 자신의 패배를 새로운 성공의 발판으로 삼아 뛰어 오르는 아니 실패를 극복하고 기어 오르는 능력이 있다고 설명하고 있다. 

책에서는 비전은 자신에게서 찾아야 한다고 이야기 한다. 바꿀 수 있다고 생각하지 않는다면 왜 무언가를 하려 하는가? 만약 그런 비전이 없다면, 아마 단지 어딘가에서 잃어 버렸기 때문이다. 과거에 어딘가에서 무언가가 중요하다는 사실을 믿었다면, 그 무언가가 세상을 바꿀 수 있었을지도 모른다. 

돌아보기

여기 있는 내용만 보더라도, 책이 상당히 어렵다. 하지만, 여기 요약한 몇가지만 보더라도 책이 얼마나 영향력있는 내용을 설명하고 있는지 쉽게 알 수 있을 것이다. 사실 책을 사놓고 요약을 했음에도 많은 부분을 잊고, 요약도 부족한 상태였다. 1, 2부를 요약했으니, 나머지도 다시 요약하면서 정리해 봐야겠다.

Reference

[1] Gerald Weinber, 조승빈 옮김, "테크니컬 리더: Becoming Technical Leader (BTL)", 1월 2013

[2] 공신의 습관 만들기, https://gongsin.com/discuss/130684

[3] 하루 5분 일기를 통한 자기 발견: https://1boon.daum.net/ppss/5afd4001ed94d20001c06dab