Management

좋은 전략 나쁜 전략 커버

Book: 좋은 전략 나쁜 전략

댓글 달기 / Book, Management / /
좋은 전략 나쁜 전략 커버

Richard Rumelt의 Good Strategy Bad Strategy의 번역서인 좋은 전략 나쁜 전략이라는 책을 읽었다.

트위터에서 박상민 님의 강력한 추천으로 이 책을 알게되었고 아마존 평도 굉장히 좋고, 마침 올해 첫번째 책으로 무엇을 읽을까 하던 차여서 바로 주문해서 읽게되었다.

저자인 리처드 루멜트에 관해서 몰랐지만, 책을 읽으면서 경영 및 전략에 대해 깊게 연구했으며, 기업 뿐만 아니라 군사나 외교 전략에 대해 조언을 해온 분이라는 것을 알게되었다. 또한, 책에서 다루는 다양한 케이스 스터디들이 필연적으로 기술이나 이에 기반한 경쟁력에 관해 다룰 수 밖에 없는데, JPL 엔지니어 출신이라는 것도 신뢰감을 주었다.

이 책에서 가장 중요하고 강렬한 메시지는 1부에서 등장하는데, 바로 기업들이 좋은 전략을 가지지 못하는 이유는 그 자리를 나쁜 전략이 차지하고 있기 때문이라는 것이다. 자연스레 무엇이 나쁜 전략인가에 관한 이야기로 넘어가고, 나쁜 전략의 전형들을 제시하는데, 실은 목표에 해당하는 것을 세우고 이것이 전략이라고 착각하는 경우, 전략이 목표로 하는 문제를 제대로 정의하지 않는 경우, 비현실적인 전략적 목표를 세우는 경우 등을 들고 있다.

이러한 나쁜 전략이 만연하는 이유들도 설명하고 있는데 좋은 전략을 세우기 위해서는 서로 상충하는 목표들 사이에서 어느 하나에 집중하는 고통스러운 결정을 해야하지만 사람들은 그러한 어려운 결단을 회피하려는 경향이 있다는 것이다. 또한 비전, 가치, 전략과 같은 템플릿에 칸을 채우는 방식으로 전략이 정해지거나, 열심히 하면 또는 정신력으로 해낼 수 있다는 근거없는 믿음 등을 들고 있다.

기업들의 나쁜 전략들의 유형이나 그것이 발생하는 이유들은, 내가 그동안 일해오면서도 어렵지 않게 관찰할 수 있었고, 나조차도 그 일부에 해당햇던 것 같아서 깊이 공감이 되었다.

그렇다면 좋은 전략이 무엇인가라는 질문으로 이어지게 되는데, 이 책의 두번째로 중요한 메시지는 좋은 전략의 핵심 구성요소들에 관한 것이며, 1. 문제의 진단, 2. 추진 방침, 3. 일관된 행동 계획 이라는 3가지로 이루어진다.

문제의 진단이 없이 전략을 세웠을 때 어떤 일이 일어나는지, 문제의 진단과는 동떨어진 추진 방침을 세우는 경우들, 타당한 방침까지 세웠지만 실제로 행동 계획은 모호하거나 실행하기 어려운 경우들을 사례들을 통해 설명하면서 왜 이 3가지가 전략의 핵심 구성요소인가를 명확하게 드러내주고 있다.

아마도 내가 대학교를 나온 후 회사에서 본격적으로 일을 하기 전에 이 책을 읽었다면, 너무나 당연한 얘기를 하고 있네 정도로 받아들였을 것이다. 하지만, 이 책에서 이야기 하고 있는 것처럼, 좋은 전략을 세우기 위해서는 가장 본질적인 문제를 파악하기 위한 매우 어려운 작업들을 해야하며, 서로 상충하는 목표들 사이에서 설득하고 결단을 내리는 것과 같은 고통스러운 일을 해야한다. 그래서, 그 어떤 기업이라고 하더라도 좋은 전략들만 보유하고 있지는 않을 것이고, 기업에 따라서 나쁜 전략의 비중이 얼마간 차지하고 있을 것이다.

지금 일하고 있는 회사에서는 3개월마다 우선순위를 제안, 검토하고 경영진이 결정하는 구조를 가지고 있는데, 물론 완벽하지는 않겠지만, 문제의 진단과 방침, 구체적으로 어떤 일을 할 것인지를 정의하기 위한 작업들로 구성되어있다. 물론, 여기서도 상충하는 목표들이 공존하는 상태에서 명확한 결정에 시간이 걸린다든가, 문제의 진단을 위해서는 너무 많은 비용이 들어가기 때문에, 피상적인 진단인 경우, 때로는 어떻게 실현할 것인가에 대한 계획이 뚜렷하지 않은 경우 등이 종종 발생한다. 다만, 그럴 때마다 올바른 궤도로 돌아가기 위해서 여러 사람들이 지적을 하고 수정을 해나간다는 사실이 중요한 것이 아닐까 싶다.

책의 2부와 3부에서는 행동과 자원의 집중을 통한 레버리지의 활용, 현실성 있는 근접 목표를 제시하는 것, 여러요소를 통합해서 전략을 설계하는 것, 경쟁우위를 확보하는 것, 변화의 디테일을 이용하는 것 등 좋은 전략을 세우기 위한 구체적인 주제를 다루고 있다. 다만, 1부에서의 내용의 경우에는 아마도 누구나 따라해볼 수는 있는 내용이라면, 여기서부터는 깊은 고민과 노력, 통찰력이 필요한 영역이라고 느껴졌다. 한번 읽는 것만으로는 완전히 체화하거나 반복하기 어려운 내용들이기 때문에, 앞으로 주기적으로 다시 읽어보면서 그때 고민하는 전략의 영역에서 통찰을 얻어가는 것이 좋을 것 같다.

엔지니어링 조직의 헤드로서 전략을 세우고 이를 조직 내의 사람들이 인식하고 행동에 반영할 수 있도록 노력하고 있다. ‘비전’이나 ‘방향성’, ‘목표’라는 단어로 표현될 때가 있지만, 실은 ‘전략’이어야 한다는 생각이 든다. 이를 위해서 앞으로 추구해야하는 방향에 대한 고민과 생각들을 전사적인 발표 등에서 얘기하려고 노력하고 있다. 이 책을 읽고나서 크게 깨달은 한가지는 이러한 고민과 생각들을 얘기하는 것만으로는 부족하다는 것이다. 문제의 진단과 추진 방침이 있다고 하더라도 구체적인 행동 계획이 있어야만, 조직 내의 다른 사람들이 자발적으로 실천에 옮길 가능성이 높아진다는 생각이 들었다. 그래서, 앞으로는 방향성과 함께 구체적으로 어떠한 기술을 확보해야하고, 첫단추로 어떤 작업으로 시작해야하며, 근접 목표는 무엇으로 잡아야하는가를 정의하고 이야기에 포함시켜야겠다는 결론을 얻었다.

회사 또는 조직 차원에서의 전략, 방향성, 목표를 고민하고 결정하고 이끌어나가야 하는 사람들에게는 이 책을 강력하게 추천하고 싶다. 그렇지 않다고 하더라도 앞으로 회사나 조직에서 올바른 전략을 세우도록 하기 위해서 자신의 자리에서 어떠한 기여를 해야할지 고민하시는 매우 훌륭한 분들에게도 추천하고 싶다.

Book: 좋은 전략 나쁜 전략 더 읽기"

Hard Things: 불확실성

댓글 달기 / Management / /

올해의 방향성을 논의하면서 여러가지 사업 기회나 제품의 방향성에 관한 아이디어들이 다루어진다. 어떤 것들은 새로운 것이 아니고 오랫동안 논의되어오고 그동안 중요하게 고려되어온 것들도 있다. 하나하나의 아이디어들을 보면 모두 좋은 기회들과 고객에게 전할 수 있는 가치들이 숨어있다.

이어서 얼마나 많은 자원이 투입되어야 하는가, 이를 둘러싼 비즈니스 환경이 어떠한가, 마일스톤 내에 가능한가와 같은 의견들이 개진된다. 물론, 여러가지 어려움이 있지만, 그러한 어려움을 헤쳐나간다는 가정 하에 어떤 것들은 실행가능해보인다. 어떤 것들은 그렇지 않다. 추가적인 투자가 필요하거나, 마일스톤 내에 성공이라고 부를만한 충분한 진척을 내기 어렵거나, 결코 녹록치 않은 경쟁 환경인 경우들이다.

그러한 기준들을 통과한 아이디어들에 대해서, 마지막으로 매우 구체적인 숫자로 표현된 회사 목표를 달성할 수 있는지를 검토한다. 여기서 많은 아이디어들은 ‘불확실’하다. 아마 누구라고 하더라도, 어떠한 사업이나 제품 방향성이 완벽하게 실행이 되었을 때, 100%의 확률로 구체적인 기한 내에 구체적인 매출이나 이익을 낼 수 있을거라고 장담하기 어렵다. 실은 50%의 확률로 그러하다고 장담하는 것도 쉽지는 않다.

자리로 돌아와서 모호하게 표현된 가능성에 대한 의견들을 수치화할 수 있는 방법에 대해서 생각한다. 구체적인 숫자로 표현된 회사 목표에 대해 잠시 눈을 감을 수는 없는가 생각을 한다. 좋은 아이디어들은 많이 있다. 분명히 회사의 가치에도 제품의 품질이나 고객의 만족에도 도움이 될 것이다. 구체적인 숫자는 잠시 무시하고 가장 커다란 가치를 줄 수 있는 것에 ‘도전’할 수는 없나 생각을 한다. 하지만, 곧이어 짧은 기간의 성공 가능성도 확신할 수 없다면, 어떻게 장기적인 성공 가능성에 주어진 자원을 모두 투자할 수 있는지, 또한 장기에 걸친 실행 자체도 구체적으로 표현된 마일스톤 없이는 위태로운 것이 아닌가 하는 생각으로 이어진다.

어렵다. 아마도 모든 회사의 대부분의 사업 기회들과 제품 아이디어들은 그러할 것이다. 기회들과 아이디어들은 대개 제어할 수 없는 요인들과 불확실성을 가지고 있다. 훌륭한 아이디어처럼 보이는 것들에 대해서 얘기하는 것도 그에 대해서 동의하는 것도 쉬운 일이다. 하지만, 실제로 그 훌륭하다고 말하는 아이디어에 가장 중요한 무언가를 걸고 헌신하는 것은 완전히 다른 문제이고 어려운 일이다.

그러한 불확실성 속에서 가장 좋은 결정을 할 수 있는 능력 만큼이나 용기도 중요한 것 같다. 어쩌면 그 둘은 같은 것일지도 모른다.

Hard Things: 불확실성 더 읽기"

규칙은 마지막에 고려하세요

댓글 달기 / Management / /

규칙과 규칙에 대한 보상과 벌을 설계하고 운영하는 일은 아주 어려운 일이다. 조직에서 어떤 부정적인 행동들이 관찰될 때 매니저로서 즉각적으로 드는 생각은 규칙을 만드는 것일지도 모른다. 하지만, 실제로는 많은 경우 가장 마지막에 고려해야 하는 방법이다.

‘9시 – 6시를 근무시간으로 한다’라는 규칙을 가진 회사를 가정해보자.

인간이 살아가는 세상이 늘 그렇듯이 9시보다 늦게 출근하는 사람들이 생겨나기 시작한다.

정시에 회사에 도착하려고 지하철역에서 뛰어왔지만 1분 늦어버린 사람, 그래도 아침에 맛있는 커피는 필수니까라고 생각하며 카페에 들르다보니 9시 10분에 도착한 사람, 어젯밤에 오랜만에 만난 친구들과 새벽까지 회포를 풀다보니 늦잠을 자버려 10시가 좀 지나서 출근한 사람.

약 20%의 사람들이 한달간 1번 이상 9시 정시 출근을 지키지 않았다. 반대로 정시에 출근하는 사람들의 20% (전체의 16%)는 늦게 출근하는 사람들로 인해 업무에 방해가 되거나 또는 불공평함을 느낀다고 생각했다.

조금 보수적인 회사의 인사부서에서는 이러한 현상을 막기 위해 9시 정시 출근하지 않는 사람들에게 직접적인 불이익을 주는 방법을 고려하다가 그 해의 인사고과에 정시 출근 여부를 반영하기로 했다. 또한, 한달 동안 시스템에 기록된 출근 시간 중에서 9시 이후인 시간이 한 번 이상 있다면 인사부서에서 매니저와 본인을 대상으로 규칙 위반을 통지하고 이는 인사고과에 반영될 것이라는 이메일을 보내기로 했다.

효과는 즉각적이었다. 정시 출근을 지키지 않던 그룹이었던 20%의 80% (전체 중 16%)가 정시 출근을 지키기 시작했다. 다만, 규칙을 지키기 시작한 20%-80% 중에서 다시 80% (전체 중 약 13%)는 다시 규칙을 지키기 시작했음에도 불구하고, 이러한 규칙에 대해 불만이 생겨났다. 살다보면 발생할 수 있는 여러가지 사고와 실수로 인해 10분 늦는 것에 대해 너무 과도한 불이익이 주어진다는 것이었다. 어떤 사람들은 자신은 아침마다 반드시 등교를 돕고 빠듯한 시간 내에 최선을 다해 출근을 하는데도 이러한 불이익은 너무 가혹하다는 논리를 폈다. 반대로, 그래도 정시 출근을 지키지 않던 그룹이었던 20%의 20% (전체 중 4%)의 출근 지연 시간은 평균 10분에서 평균 20분대로 더 늦어졌다. 어차피 불이익을 볼거라면 별 차이가 없지 않냐는 논리였다. 한편, 정시출근을 하지 않는 사람들에 대한 불만은 해소되었지만, 정시출근을 원래부터 지키던 80% 그룹 내에서도 20%의 사람들은 자신이 혹시라도 지키지 않았을 경우 발생하는 불이익에 대해 스트레스를 느꼈고 그것이 불만으로 이어졌다.

여러가지 경로로 이러한 문제점들을 들은 인사부서는 규칙을 조금 개선하기로 했다. 10분 지각까지는 경고를 하되 한달간 3회 누적이 되면 원래 대로의 불이익을 주기로 했다. 다시 규칙을 지키기 시작한 그룹 중에서 80%는 실수로 인한 위험이 줄어들어 어느 정도 만족을 했지만, 그 중 20%는 불만이었다. 그 이유는 다양했는데, 여전히 오는 경고 이메일은 두렵다는 것, 10분 이상의 지각이 일어날 수도 있는 가능성에 대한 불안, 3회 누적 시 불이익은 여전히 너무 강한 불이익이라는 것 등이었다. 정시 출근을 원래부터 지키던 80% 그룹 내에서 스트레스로 인한 불만이 줄어들었다고 대답했지만 여전히 그들 머리 속에는 불안이 자리잡고 있었다.

임원진으로부터 너무 불이익을 주는 방법만 생각하지말고 정시 출근을 하는 사람들에게 이익을 주는 방법도 생각해보자는 의견이 나와서 인사부서는 또 고민을 하게 되었다. 3년 동안 정시 출근을 빠짐없이 한 직원들을 개근 표창하고 보너스 20만원을 지급하기로 했다. 어차피 정시 출근을 하는 사람들이 80% 이상을 차지하고 있기에 3년 개근을 달성하는 것은 약 64%가 달성할 것으로 기대되는, 아주 어려운 일은 아니었다. 그래서 보너스 액수도 적을 수 밖에 없었다. 64%나 받는 표창이기에 어떤 뿌듯함 같은 것은 없었다. 어차피 정시 출근을 지키지 않던 그룹은 이 액수를 보고 마음을 바꾸지 않았다. 반대로 정시 출근을 하던 그룹의 사람들에 대해서 지각을 할 것 같으면 휴가를 사용하라는 웃지 못할 이야기도 돌았다.

‘9시 출근’이라는 어떤 회사에서 반드시 지켜야 하는 어떤 규칙을 사례로, 어떤 규칙을 지키도록 만들기 위해 어떤 일들이 일어나고 그런 과정이 얼마나 험난한지 이야기 식으로 풀어보았다. 어떤 규칙을 지키지 않는 사람들이 발생하고, 규칙을 더 많은 사람들을 지키도록 만들기 위한 과정에서 당근과 채찍을 동원하고, 규칙 그 자체에 대해 불만을 가진 사람들과 채찍에 대한 불안감을 가진 사람들, 당근에 대한 효과와 공정성에 의문을 가진 사람들이 발생한다.

사실 우리들이 모든 일에 대해서 규칙을 원하는 것은 아니다. 우리가 실제로 무엇을 원하는가를 잘 생각해보면, 실은 어떤 긍정적인 행동에 대해 여러 사람들에게 그것이 무엇인지, 그리고 왜 정당한지를 설명하고, 더 많은 사람들이 그러한 행동을 하도록 하고 싶은 것이 대부분이다. 더 좋은 단어가 있을지 모르겠지만 나는 보통 ‘규칙’ 대신 ‘가이드라인’이라는 단어를 쓴다. 가이드라인이라면, 일부가 그렇게 행동하지 않아도 큰 문제가 없다. 오히려 가이드라인이 제시하는 방식에 얽매이지 않고 다른 방식의 행동을 통해 새로운 돌파구를 찾아내는 길을 열어놓아야 할 때도 있다.

물론, 규칙이 필요한 경우도 있다. 모든 사람들이 같거나 비슷한 행동을 할 때 발생하는 시너지가 있다. 하지만, 규칙이라고 해도 여전히 이를 지키지 않는 사람들이 발생할 것이다. 처음에 규칙이 만들어질 때는 모두의 합의에 기초를 했더라도 시간이 흐르면서 또는 새로운 사람들이 들어오면서 규칙을 지키지 않는 사람들이 늘어나는 경우가 있다. 규칙을 지키지 않는 사람들이 너무 늘어나면 규칙이 유명무실해 지므로, 일정 비율 이하로 유지해야할 필요성이 있다.

그럼에도 불구하고, 규칙을 보상과 벌을 이용해 제어하려는 생각도 가급적이면 뒤로 미루는 것이 좋다. 모든 것을 규칙으로 제어하려고 하면 위에서 본 것처럼 규칙을 만드는 사람과 따르는 사람 모두가 그 규칙에 얽매여서 불행한 삶을 살아가야한다. 규칙에 대해 많은 제어를 하지 않기 위해서는 다음과 같은 고려들이 필요한 것 같다.

  • 먼저, 많은 사람들이 현실적으로 지키기 힘든 규칙이어서는 안된다.
  • 가능하다면 규칙의 설계 상 인간으로서 할 수 있는 실수는 어느 정도 허용해야 한다.
  • 규칙을 운영하면서 발생하는 작은 위반들은 그냥 눈감아주되 정상적인 상태로 올 수 있도록 가벼운 자극을 주는 것이 좋다.
  • 규칙의 목적에 반하는 매우 커다란 위반들에 대해서도 규칙을 만들지 말고 하나의 예외로서 처리하는 것이 좋다.

이러한 방식으로 규칙을 만들 때 나는 ‘정책’이라는 단어를 쓴다. ‘정책’은 조직을 운영해나가려는 의도를 통해서 조직의 방향을 제시해 사람들의 혼란을 방지할 수 있고, 규칙을 위반하는 사람들을 어느 정도 포용하면서 논의를 통해 더 나은 방법을 찾아나갈 수 있는 메시지를 준다고 생각한다.

나도 처음 매니저 역할을 경험하면서 명확한 규칙과 엄정한 실행이 답이라고 생각했던 적이 있었기에, 새롭게 매니저 역할을 하시는 분들에게 조금이나마 도움이 되기를 기대하면서 아침에 떠오른 생각들을 정리해봤다.

결국은 더 많은 규칙이 더 효과적인 조직을 만들어주지는 못한다.

규칙은 마지막에 고려하세요 더 읽기"

Article: An Inside Look at Facebook’s Approach to Automation and Human Work

댓글 달기 / Management, Software Development / /

An Inside Look at Facebook’s Approach to Automation and Human Work

Facebook의 VP of Engineering인 Jay Parikh와의 자동화에 관한 인터뷰.

하드웨어의 실패에 따른 자동화된 진단과 복구를 위한 FBAR라는 자동화 시스템에 대해 이야기하고 있다.
FBAR에 대해서는 조금 오래된 글 (2011년)이지만, 다음 글에서 조금 더 자세한 내용을 볼 수 있다.
https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920

We built a system we call FBAR, for Facebook Auto Remediation, to do a very basic set of hardware remediation tasks. Before, if a server had a hard drive failure or some hardware error, an alarm would go off and some human would have to log in, or walk to the computer, and try to debug or fix it. You’d do some things to try to fix it in software, you’d reboot the machine, you might try to reimage it. A lot of that software remediation and debugging is all automated now. No person has to be involved with that. The system will detect the error– it could be a disk drive, it could be a CPU, it could be a networking card or power failure—and can go ahead and do a bunch of things that it knows how to do.

당연한 이야기이지만, 자동화의 이점 중 하나는 휴먼 에러를 방지하는 것이다.

You don’t have to worry about that with automation, because work consistently gets done in the same way every time. And cluster turn-ups which used to take three or four months now can be done in the course of a week – sometimes in just a couple of days.

자동화를 통한 효율에 관한 이야기인데, 일반적인 IT 회사에서 200~500대의 서버당 1명이 일하고 있다면, Facebook에서는 25,000대당 1명의 효율을 가지고 있다고… 예전에도 들은 바가 있는 것 같지만, 2000대를 1명이 담당하는 정도가 되니 불안함을 느꼈던 것을 생각하면 대단한 것 같기는 하다.

So we have done a lot of work on the software automation side of this, to the point that we only need one technician in the data center for every 25,000 servers. That is a ratio that is basically unheard of. Most IT shops have ratios of one to 200, or one to 500.

이 인터뷰에서 자동화의 이점으로 가장 강조하고 있다고 느끼는 점인데, 상당히 단순한 부분들을 자동화하고 나면, 똑독한 사람들이 더욱 높은 수준의 일을 할 수 있고 미래에 대해서 생각할 수 있도록 한다는 것이다.  그리고, 그런 똑똑한 사람들이 오랜 시간에 걸쳐 평범한 일을 하게 된다면 결국 번아웃과 불행함으로 이어지고, 결국 이직을 하게 마련인데, 업무가 지루하고 반복적인 단순 업무가 되지 않도록 지속적으로 자동화를 하고 아키텍쳐를 바꿔나가야한다고 얘기하고 있다.

I think one of the major ways you do this is by continuing to keep them out of their comfort zone. If they end up doing “humdrum” work for a long time, they’re not learning anything, yet they’re spending a lot of time doing it. That leads to burnout and unhappiness, and then they’re going to go somewhere else. So, I think, if growing your company depends on keeping these brilliant technologists engaged, the necessity is that you have to keep automating and rearchitecting your systems so that things don’t become boring, monotonous, and repetitive. Automation serves your talent objectives.

변화를 위한 조직 구조에 대해 – 변화를 위한 팀과, 안정적이고 효율적인 운영을 위한 팀을 분리하는 것이 전통적인 접근.

Otherwise, you put them in a position where one team, in order to hit its goals, always wants to make changes, and another team only wants to make everything stable and cost-effective. Those two are completely opposed to each other. […] When I showed up at Facebook in 2009, this is what I saw and I thought is was perfectly reasonable. It was this way when I was at Akamai, it was this way when I got to Ning.

문제는 단기적인 비용에 기반해 의사결정을 하기 때문에, 미래를 위한 투자를 하지 않게 되고, 자동화는 작은 팀의 임무로 맡겨지기 때문에, 수많은 엔지니어들의 요구에 따라가지 못하게 되는 것.

Sometimes we were making decisions that were short-term cost based, when we should have been basing them on what we would need to be ready for a year from now. In other places, the focus on automation wasn’t there, because it wasn’t a team’s own responsibility. Questions about automation were being tossed to a small team of people who just weren’t going to keep up with this swarm of engineers that we were hiring.

Facebook에서는 이를 같은 팀에 묶고 변화와 운영을 동시에 하도록 하고 있다. 이 또한 쉬운 일은 아닌데, 인터럽트들이 장기적인 목표에서 벗어나도록 하기 때문. 데드라인에 대해서 조금 유연하게 대처할 필요가 있다고 얘기하고 있다.

No, we come up with what we call big bets as a team, planning the investments in technology that will take one or two or three years to build. For example, we built a new compiler that runs the front end of our site. It took us a couple of years to build and that R&D effort was done in parallel, in the same team that was maintaining the existing run time that was running the live Facebook.

이러한 방식의 장점에 대해서, 혁신을 위한 팀은 변화에 대한 성과에 대해서 걱정하고, 전선에서 뛰는 비즈니스 팀은 언제쯤 재미있는 일을 할 수 있는지에 대한 불만을 표하는 상황 등을 방지할 수 있다고 얘기하고 있다.

But meanwhile there are so many benefits — starting with the fact that it’s done in a much more open way. No one likes it when there’s a team working in some secure undisclosed location “doing something really cool that is going to replace what you’ve got.” It’s a tough thing to manage on both ends. The innovation team worries: “We’re not making any impact now – they’ve just stuffed us in a corner and told us go deliver something great.” And the core business team you’re depending on to deal with problems and customer support issues and all the urgent things that come up, is saying, “When do we get to work on something cool? Are we second-class citizens or something?”

의견

자동화의 이점에 대해서는 100% 동감하고 적어도 IT 업계의 일정 규모 이상의 회사라면 어떤 조직이라도 항상 중요한 목표가 되어야 한다고 생각한다. 변화팀과 운영팀을 통합하는 조직 구조에 대해서는 전반적으로는 동의하나, 아마도  VP 레벨의 입장에서는 통합된 조직일지는 몰라도 실무 수준에서는 이 글에서도 제시하듯이 인터럽트와 단기적인 비용에 기반한 요구들은 장기적인 관점에서의 업무에 매우 해롭기 때문에, 일정 규모 이상의 조직이라면, 정도의 차이는 있더라도 팀 내에서라도 어느 정도의 분리는 필요하지 않는가라고 생각한다. 다만, 변화팀과 운영팀이 서로 얼굴을 맞대고 이야기할 수 없을 정도로 서로 다른 조직의 바운더리로 분리되어 있다면, 이 글에서 지적된 것과 같은 부정적인 효과는 항상 발생할 것이다.

Article: An Inside Look at Facebook’s Approach to Automation and Human Work 더 읽기"

Great teams have members that defy roles

댓글 달기 / Management, Software Development / /

The best teams I have worked in and with are those that defy the traditional roles and responsibilities.  Putting up artificial walls between extremely closely related disciplines can only be detrimental to getting great team work.  Any given set of devs, testers and PMs working on a feature have a different set of skills and experience they bring to the team.    Putting in place a structured set of expectations denies this fact.  If the developer is more senior and experienced in an area, then  you may want them leading more of the design of the feature, not just the implementation.   Likewise if the PM is very senior and an experienced software architect, you may want them to have more of an input in the actual implementation decisions.

내가 함께 일했던 최고의 팀들은 전통적인 역할과 책임에 반하는 팀들이었다. 서로 밀접한 관련을 갖는 분야들 사이에 장벽을 세우는 것은 팀워크에 방해가 될 뿐이다. 하나의 기능을 위해 모인 개발자, 테스터, PM들로 구성된 팀은 서로 다른 기술과 경험의 집합을 보유하고 있다. 정해진 역할과 책임을 강제하는 것은 이러한 사실을 부인하는 것이다. 개발자가 해당 분야에 있어서 경험이 깊다면, 구현 뿐만 아니라 좀 더 많은 기능 설계를 이끌어가기를 바랄 것이다. 마찬가지로, PM이 매우 숙련된 소프트웨어 아키텍트라면, 실제 구현 결정에 있어서 좀 더 관여하기를 원할 것이다.

— quoted from ‘Great teams have members that defy roles‘ by Brad Adams

Great teams have members that defy roles 더 읽기"

Dreyfus Model

8 댓글 / Management, Software Development / /

모든 관리자의 이상

관리자의 입장에서 가장 예뻐 보이는 동료는 누구일까?

여러 가지 답이 있을 수 있겠지만, 그 중 하나는 아마도, ‘주어진 업무를 수행할 때, 업무의 목표가 무엇인지 정확히 이해하고 수행하는 사람’이다. ‘상위 조직의 목표까지 고려해서, 원래 업무의 방향을 수정하거나, 업무의 우선순위를 조정하거나, 적절한 새로운 업무를 추진할 수 있는 사람’이라면 더할 나위 없을 것이다. 역설적이게도, 어떻게 보면 관리가 필요하지 않은 사람이 바로 관리자의 이상형이다.

세상은 완벽하지 않다. 모든 동료들이 위에서 얘기한 조건을 만족하기란 어려운 일이다.

관리자 M이 보기에 동료 A는 지시하지 않은 세부 사항까지 알아서 척척 처리해, 손이 닿지 않는 곳의 가려움에서 벗어나는 기쁨을 안겨 주는 반면,  동료 B는 완료했다는 일이 처음부터 업무를 처리할 방식을 세세하게 다시 설명해 주어야 할 정도로 엉망이어서, 그 사람 얼굴만 보면 짜증이 나고, 잠도 안 올 정도로 고민거리다.

왜 그럴까? 동료 B는 멍청해서? 게을러서? 여자 친구랑 헤어져서? 에어컨이 고장 나서?

그런 것은 아닌 듯 하다. 동료 B는 업무 시간에 집중해서 성실하게 일하며 책임감도 높다. 여자 친구가 없으니 헤어질 일도 없다. 관리자 M의 옆자리니까 에어컨이 고장 난 것도 아니라는 것을 안다.

업무 경험이 많고 세심한 관리자 M이 보기엔, 한마디로 딱 잘라 말할 수는 없지만, 동료 A와 동료 B와 얘기를 해보면, 둘 사이에는 업무를 대하고 처리하는 방식에는 본질적인 차이가 있다.

관리자 M이 한마디로 딱 잘라 말할 수 없는 것을, 어떤 똑똑한 사람이 딱 잘라 말한 것 중 하나가 바로 Dreyfus Model이라는 것이다.

드라이퍼스 모델 (Dreyfus Model)

드라이퍼스 모델은 철학자 드라이퍼스 (Hubert L. Dreyfus)가 그의 저서 Mind Over Machine의 도입부에서 제안한 기술 습득의 5단계 모델이다1. 요즘 읽고 있는 Andy Hunt의 Pragmatic Thinking & Learning의 2장에 소개되어 있다. 이 책의 내용과 Mind Over Machine의 발췌 부분, 전문가 시스템 비판이란 글을 이용해서, 핵심적인 내용만 간단하게 요약해 보자.

Stage 1: Novices

경험이 없기 때문에, 상황에 상관 없이 적용할 수 있는, 다시 말하면, 상황에 따라 적절하지 않을 수 있는, 조리법(recipes) 즉, context-free한 규칙이 주어졌을 때 효과적으로 과업을 수행할 수 있다.

Stage 2: Advanced Beginners

여러 가지 상황에서 의미를 가지는 요소에 대해 인지하게 되고, 이러한 요소를 context-free한 규칙에 더해서 활용하게 된다.

Stage 3: Competent

경험이 쌓이면서, 고려해야 할 요소들이 폭발적으로 증가한다. 불가피하게, 상황 하에서 어떤 요소를 중요하게 고려해야 할 지를 선택한다. 이러한 상황에 대한 모델 하에서, 상황을 분석하고 규칙에 따라 행동을 선택한다. 자신이 선택한 결과 – 성공이나 실패에 대해 책임감을 느낀다.

결과적으로 스스로 문제를 해결(troubleshoot)할 수 있다.

Stage 4: Proficient

Competent 단계에서 경험한 성공과 실패를 바탕으로, 상황에 따라 어떤 요소를 중요하게 고려해야 할 지를 결정한다.

어떤 요소들이 더 중요하고, 어떤 요소들이 무시해도 되는가는 경험이 추가됨에 따라 직관적으로 변화한다. 반면에, 실제로 어떤 행동을 해야 할 것인가에 대해서는 분석적인 사고를 필요로 한다.

Stage 5: Expert

의식적인 사고나 규칙의 필요 없이, 직관적으로 어떤 요소를 중요하게 고려해야 할 지와 어떤 행동을 해야 할 것인가를 안다.

드라이퍼스 모델의 적용

드라이퍼스 모델이 실제로 적용된 것은 간호(Nursing) 분야였고, 자신이 간호사였던 간호 연구자 Patricia Benner가 1984년에 From Novice to Expert: Excellence and Power in Clinical Nursing Practice라는 책으로 정리해 내놓으면서였던 것 같다.

프로그래밍 분야에서 드라이퍼스 모델의 적용에 관한 좀 더 구체적인 예는 Debugging: From Novice to Expert라는 논문에 정리된 다음 표를 참고하면 좋을 듯 하다. (via 드라이퍼스 모델)

debugging

Closing

동료 A와 동료 B의 ‘본질적인 차이’란 무엇인가? 동료 A는 아마도 Competent 이상일 테고, 동료 B는 Advanced Beginner 이하일 것이다. 이것이 ‘본질적인 차이’에 대한 본질적인 대답은 아니다.

드라이퍼스 모델이 제시하는 것은 겉으로는 5단계의 구분이지만, 마치 무협지의 주인공처럼 Novice가 어느 날 갑자기 기연을 얻어서 Expert가 될 수 없다는 사실을 내포하고 있다. 즉, 한 단계 높은 숙련도에 이르기 위해서는 충분한 경험과 고민, 트레이닝, 그리고 그것들을 위한 시간이 필요하다는 것이다.

드라이퍼스 모델이 5단계의 구분에서 제안하는 중요한 요소는 바로 직관이라는 요소다. 인간은 구체적인 경험으로부터 직관을 얻을 수 있고, 이것은 컴퓨터와 같은 기계로 추론해 내는 것은 대단히 힘들다는 것이다. 물론 이것은 인간에게도 쉽지는 않으며, 위에서 언급한 것들을 필요로 한다.

대학교 CS 과정에서 프로그래머의 생산성은 10배 이상까지 차이 날 수 있다는 사실을 배운다. 이러한 사실은 프로그래머라면 누구나 현장에서 느낄 수 있다.

하지만, 관리자로서 그러한 사실을 접하는 것은 완전히 다른 경험이다. 프로그래밍 과업의 결과물의 양적 또는 질적인 차이에서 뿐만 아니라, 업무를 얼마나 깊이 이해하고, 어떤 목표를 추구하는가, 그에 따라 어떤 과정을 선택하는가와 같은 일하는 방식의 문제로까지 확장되는 것이다.

당연하기도 하지만, 실제로 그렇다는 것을 깨닫고 나서 놀랐던 사실들이 있다.

  • 일하는 방식에 있어서의 Competent 이상의 능력을 가진 사람은 정말로 소수에 불과하다.
  • 특정 스킬, 이를테면 코딩 스킬이 뛰어나다고 해서, 반드시 커뮤니케이션 방식에 있어서
    뛰어난 것은 아니다.
    즉, 스킬에 따라 숙련도는 다르다.
  • 경력이 오래 되었다고 해서, 반드시 일하는 방식에 있어서 뛰어난 것은 아니다. 반대로, 경력이 짧아도 일하는 방식이 뛰어난 경우가 있다.

개인 간의 차이는 생각보다 컸고, 기대하는 스킬과 실제 스킬의 차이의 간극도 역시 생각보다 컸다.

이제 나의 고민은, 관리자로서, 어떻게 하면 동료들이 한 단계 더 높은 스킬 숙련도에 이를 수 있도록 도와 줄 수 있는 가이다2. 우선, 자신과 함께 일하는 동료들의 주요 스킬의 숙련도가 어느 단계인가 파악해보자.

1 그의 저서나 이 모델에 관한 권위 있는 텍스트를 접해 본 적은 없으므로, 정확히는 알 수 없지만, 이러한 모델은 과학적인 검증을 거쳤다기 보다는, 인공 지능의 한계를 지적하기 위한 논의를 진행하기 위한 개념적인 모델일 뿐인 것으로 보인다.

2 Andy Hunt의 책에서도 언급하고 있지만, 모든 팀원이 Competent 이상의 단계가 되어야 할 필요는 없다. Andy Hunt는 숲을 보는 사람이 있으면, 나무를 보는 사람도 있어야 한다고 얘기한다. 나도 그러한 생각에 동의한다.

Dreyfus Model 더 읽기"