조직이 성장하면서 겪는 가장 큰 성장통 중 하나는 의사결정의 병목현상이다. 갑자기 작은 일에도 시시콜콜 허락을 받아야 하는 것 같고, 분명 우리 팀의 일인데 다른 팀이 끼어들어 감 놓아라 배 놓아라 지휘하고 있는 것을 발견하여 치고받고 감정적으로 싸우면서 일은 정체되고…
이런 상황들이 점점 더 자주 발생하게 되면 조직은 점점 관료적으로 변해가며 빠르게 성장해 나가는 ‘스타트업’의 느낌은 먼 추억으로 남게 된다. 성장은 분명 좋은 것이지만 성장 과정에서 나타날 수 있는 이런 조직상의 ‘부작용’을 제대로 관리해 주지 못하면 인재 유출 및 기업 문화의 변질 등 빠져나올 수 없는 나락으로 고속질주하게 된다.
내가 다녔던 링크드인도 고속 성장을 경험하면서 (입사 당시 천명 남짓에서 퇴사 당시 만 명이 넘었다) 의사결정의 효율성을 높이기 위해서 많은 시도를 했었는데, 다음 두 가지가 원론적이지만 실제 업무에 적용하면서 가장 큰 도움이 되었다고 생각된다.
의사결정 요소들의 명확한 정의
소프트웨어 개념 중 GIGO라고 있다. Garbage in, garbage out. 쓰레기를 집어넣으면 쓰레기가 나온다는 것이다.
두루뭉술하고 부실한 자료를 이용하여 의사결정을 한다면 결코 고퀄의 결론을 끌어낼 수 없다. GIGO 현상을 방지하기 위해 다음과 같은 의사결정 요소들의 명확한 정의가 정말 중요하며, 이를 통해 속도와 질의 균형을 맞출 수 있다.
1. What (무엇)
- Define what decision needs to be made
무엇에 대한 의사결정인지를 구체적으로 정의한다. 예를 들어 ‘다음 분기 중요한 안건들’ 이라고 정의하는 것은 너무 애매모호하다. ‘다음 분기 중남미 시장의 목표 매출액 달성을 위해 필요한 마케팅 예산’처럼 구체적으로 의사결정 사안을 명기하자.
2. Who (누구)
- Clarify roles for stakeholders
의사결정 과정 및 사후 관련될 사람들을 미리 식별하고, 또 그들의 역할을 분명하게 명기한다. 나중에 ‘왜 나한테 미리 안 알려줬어?’, ‘나는 그런 바보 같은 것에 동의한 적 없는데?’ 등의 태클을 미연에 방지할 수 있고, 의사결정을 주도하는 측에서도 야비하게 ‘날치기 통과’를 할 수 없게 된다.
3. How (어떻게)
- Define quality vs. speed requirements
의사결정을 내리기 위해 필요한 조건들을 기술한다. 예를 들어 양산에 들어가기 전 기존의 벤치마킹 자료만을 이용한다면 빠른 결정을 내릴 수 있겠지만, 시제품 생산을 생략함으로써 실제 공정에서 생길 수 있는 문제점들을 발견하지 못할 수 있다. ‘How’의 기술을 통해 의사결정 조건의 장단점을 충분히 심사숙고할 수 있는 기반을 제공한다.
4. When (언제)
- Clarify timeline and milestones
언제까지 결정을 내리고, 그 과정에서 확인해야 할 사항들을 정한다. 저번 포스팅에서 ‘실용적 유의미’가 없는 경우 삽질의 위험이 있다고 언급한 것처럼, 의사결정 과정에서도 삽질의 위험성이 존재한다. 이를 최소화하기 위해 구체적인 시간표와 이정표들을 정립하여 실제 의사결정의 ‘결정’을 이룰 수 있게 해야한다.
의사결정 역할의 분배
링크드인에서는 RAPID 프레임웍을 사용하였는데, 사실 어느 프레임웍을 사용하는지 크게 상관은 없다. (엑센츄어에서 이베이 컨설팅을 할 때는 RASCI 모델을 사용하였는데, 다 비슷한 목적을 가지고 있다). 이런 프레임웍은 의사결정 과정에서 누가 어느 역할을 하는지 사전 정의를 하여 정보의 유통을 촉진시키고 해당 담당자들에게 분명한 책임감을 가지게 하는 것이다.
- R: Recommend 의사결정 방향 (찬성/반대/중립 등)을 제안하는 사람
- A: Approve 의사결정에 중대한 이견이 있을 경우 최종 승인을 하는 사람 (웬만해선 여기까지 안 가려고 노력)
- P: Perform 의사결정 결과를 이행하는 사람
- I: Input 의사결정에 주요 정보를 제공해 주는 사람
- D: Decide 의사결정의 최종 결정을 내리는 사람
출처: bridgespan 웹사이트
실례: 링크드인 온라인 사업부
나는 링크드인 B2B 제품 중 하나인 영업 솔루션 (Sales Solution)의 온라인 사업부 마케팅팀을 총책임지고 있었다. 그때 당시에는 온라인을 통해 개인 혼자 사용할 수 있는 제품만 구입할 수 있었고, 팀 단위 사용 및 관리가 가능한 제품은 영업팀을 통해서만 구매할 수 있었다.
어느 날 웹사이트 분석팀이 나에게 ‘문의하기’ 메뉴를 통해 팀 단위의 온라인 구매를 물어보는 질문들이 계속해서 들어온다고 알려주었다. 또한 온라인에서 소규모의 팀 단위 제품을 판매할 수 있다면 일 년에 수백억 원 이상의 추가 매출이 가능하다는 결론의 분석도 나왔다.
이런 ‘꿀정보’를 받은 후 웹사이트를 고쳐 팀 단위의 판매를 가능하게 하려고 하려는 차에 영업팀 부사장님으로부터 강한 백태클이 들어왔다.
여보세요 마케팅씨, 팀 단위 구매는 우리 영업팀의 고유 영역이라고요. 가뜩이나 온라인 고객지원이 형편없는데 더 복잡한 제품을 온라인에서 팔게 되면 고객만족도가 최악으로 떨어질 것이라고요! 그리고, 가뜩이나 우리 고객들이 온라인에서 구입할지 우리 영업팀을 통해 구입할지 헷갈려 하는데, 당신의 사업을 추진하게 되면 고객들은 큰 혼란에 빠져서 우리 다 망할 거에요!
이런 정체된 상황에서 나는 RAPID 프레임웍을 이용하여 온라인 사업의 최종 책임과 결정은 나에게 있음을 분명히 하고 (즉, 나는 D, 영업팀 부사장은 I), 객관적인 분석을 공동으로 의뢰하여 반박 항목에 대해 차례차례 대응하였다. 고객지원 문제는 작은 팀 단위 지원에 대해서는 영업팀이 더 형편없는 것으로 드러났고, 고객이 헷갈려 할 것이라는 우려는 전혀 근거가 없음으로 결론이 났다.
결국 온라인 상으로 팀 단위의 제품 구매를 허용하는 것으로 결정을 내렸고, 이를 통해 회사의 매출 및 이익률에 큰 기여를 했을 뿐만 아니라 오히려 실력 없는 영업 사원들을 솎아내는데도 도움이 되었다.
마무리하며
실리콘밸리의 큰 회사들을 비롯하여 많은 스타트업들이 수평적인 조직 구조를 강조하며 전 사원의 의견을 수렴하는데 많은 시간과 노력을 들인다. 다 좋은 말이긴 하지만, 전 사원의 의견을 수용하고 전원 합의를 이끌어 내려는 일부 회사의 접근 방법에는 동의하지 않는다.
회사는 동아리가 아니다. 살벌한 경쟁속에서 살아 남아야 하는 사업체이고, 이러기 위해서는 신속하고 책임감 있는 의사결정이 필수이다. 성장통을 겪고 있는 회사들이 RAPID 프레임웍 등의 도입으로 효율적이고 질 높은 의사결정을 이끌어내고, 의사결정 과정에서 오는 조직간의 갈등도 최소화 시킬 수 있길 수 있길 바란다.
원문: Andrew Ahn
