리더가 없어도 의사결정할 수 있어야 한다.
나 없이 조직이 돌아가지 않으면 내가 트롤이다
조직의 중요한 결정은 다 나 몰래 내려진다. ‘윗분들은’ 정말 쉬쉬하고 싶은 것일까?’ <엉터리 스프린트는 왜 반복되는가?>에 이어 다시 IT 원주민들의 회사 생활을 엿보자.
원준팀의 ‘애니메이션 커뮤니티’ 서비스는 점점 성장해서 직원 수도 100여 명이 넘고 다음 시리즈 유치도 성공하며 업계에서 꽤 이름 난 스타트업이 되었다. 이제는 기능조직을 세분화할 수 있을 만큼 여유가 생겼기 때문에 프로덕트의 유저 경험을 따로 분석하기 위해 UX리서처 유빈을 채용했다. 유빈은 세 달의 온보딩을 마치고 매니저인 동준에게서 본격적인 리서치 프로젝트 스스로 찾아서 진행해 보라고 주문받았다.
“00의 거인” 게시판 매번 찾아들어가기 어렵네요.
유빈은 최근 유입된 고객의 VOC를 면밀히 살펴보았고, 이 과정에서 PC 사용자들의 사이트 첫 화면에서 원하는 게시판을 찾기 어려워한다는 불만이 다수 접수된 것을 확인하였다. 여기서 힌트를 얻어 지난 3주간 사이트 방문자들의 탐색 사용성을 알아보는 리서치를 수행했다. 고객들을 취향에 따라 세그먼트를 몇 개 나눈 열정 넘치게 주말 사이에 초고속 리포트를 작성해 보고하려던 찰나였다.
그런데 PM 부서의 구현이 슬랙에 공지를 하나 올린다.
내일부터 사이트 메인화면이 변경됩니다.
네?? 뭐라구요!?
유빈은 급하게 구현에게 DM(Direct Message)을 보내 지금까지 홈 화면 사용성을 바꾸기 위해 리서치를 진행한 것과 대략적인 개선안을 보냈다. 구현도 유빈이 리서치를 진행하고 있었던 사실을 전혀 몰랐다며 그제야 리포트를 살펴보았지만, 시기적으로도 구조적으로도 그대로 적용하기엔 무리가 있었다.
구현은 화면의 방향성도 바뀌었고, 이제 와서 어느 부분을 적용하고 어느 부분을 적용할지가 애매해졌기 때문에 배포된 이후에 다시 리서치를 처음부터 수행하는 게 좋겠다는 의견을 유빈에게 건넸다. 우울해하는 유빈에게 구현은 한마디 보탰다.
저.. 근데 유빈님. 프로젝트 진행하면서 동준(유빈님의 매니저)과는 이야기를 한 적이 있었는데.. 동준님이 말하지 않으시던가요?
구현의 말을 들은 유빈은 잽싸게 동준에게 찾아갔고, 동준이 돌아온 대답은 이랬다.
아차.. 죄송해요. 정신이 없어서 깜빡했나 봐요. 그러고 보니 유빈 님이랑 마지막 1on1이 언제였죠?
동준은 정말 나쁜 놈이었을까? 조직에서 정보가 제대로 흐르지 않는 원인과 해결책에 대해 Araboza.
나 없이 조직이 돌아가지 않는다면 내가 바로 트롤이다.
작은 조직에서는 정보가 흐르는 구조가 복잡하지 않다. 책상 두 개 이내 크기 (8~10명 미만)이라면 알고 싶지 않아도 조직의 아주 세세한 정보까지 다 알게 된다. 백엔드 엔지니어가 마케팅 문구까지 같이 고민한다. 본인이 직무 외에도 제품과 조직의 세세한 디테일에도 참여할 일이 많아진다.
하지만 열 명이 넘어가게 되면 각자의 기능이 분리되고, 점점 옆자리 사람이 무슨 일을 하는지 알 수 없게 된다. 그것이 가끔 삭막해진 아파트 이웃 주민처럼 느껴질 때도 있지만 업무상의 큰 문제는 없다. 스무 명, 오십여 명이 되면 유빈의 팀처럼 곪아왔던 문제가 터지기 시작한다. 초기에는 정보가 부족해서 문제였는데, 이제는 사내에 문서와 정보가 넘쳐나는데도 일을 제대로 할 수 없어진다. 정보는 많아지는데 아이러니하게도 정작 ‘내 일’을 잘하기 위해 필요한 정보를 얻는 일은 점점 어려워진다.
조직의 규모가 커지면 알고 있는 정보가 권력이 된다.
CASE 1: 위계 조직
위계 조직에서는 직급에 따라 정보의 양이 제한되기 때문에 직급이 높으면 아랫사람한테 “네가 뭘 안다고 결정을 해?” , “내가 해봤는데 안 되던데?” 같은 말을 할 수 있다. 상무님이 알고 있는 정보의 일부만 부장에게 전달되고, 부장이 알고 있는 정보의 일부가 과장에게 전달되고, 다시 대리에게 그중 일부가 전달되는 방식이다. 사원은 정보가 부족하니 좋은 의사결정을 할 수 없고, 직급 높은 사람이 없으면 안 돌아가는 방식이다.
이러한 방식이 반드시 나쁘다고 할 수 없다. 자동차 공장에서 바퀴를 조립하는 사람이 자동차 엔진의 원리와 마케팅 전략을 (당연히도) 알 필요가 없다. 결과물의 산출 방식이 순차적이라면 구성원이 모든 정보를 알게 하는 것은 시간의 낭비다.
CASE 2: 역할 조직
정보가 흐르지 않아서 우리가 느끼는 좌절감은 역할조직에 있기 때문에 생겨난다. IT기업은 대부분 역할 조직의 형태를 따르고 있다. 디자인, 프로젝트 매니징, 개발, 마케팅 등 각 분야의 전문가들을 채용하고 그들이 스스로 의사결정할 수 있도록 한다.
역할 조직에서는 각자 ‘일당백’을 하므로 ‘나 없으면 돌아가지 않는 조직’이 되는 것이 일 잘하는 것이라 생각할 수 있지만 정반대다. 역할 조직에서는 누군가 없어져도 언제든 대체할 수 있다. 내가 없어도 잘 돌아가고, 내가 있으면 더 잘 돌아가야 한다. 내가 없어져서 조직이 멈춰버리거나 급격히 성능이 저하된다면 조직 엔지니어링에 실패한 것이다. 팀장이 빠져도 팀원이 70~80% 수준의 의사 결정과 결과물을 낼 수 있어야 한다.
중요한 의사결정이 리더십끼리 밀실에서 이뤄진다거나, 이해할 수 없는 방식으로 전달된다고 느낀다면 문제는 ‘리더가 의사결정을 마음대로 해서’가 아니다. 의사결정은 리더의 고유 권한이고 주요한 업무 중 하나라는 것을 구성원도 모두 이해하고 있다. 불만은 리더가 의사 결정해서가 아니라 의사결정에 필요한 정보와 과정을 구성원이 알 수 없기 때문에 불만이 생긴다. 이러한 정보 비대칭은 리더 - 구성원뿐 아니라 기능조직 간에도 생긴다. Product Owner가 디자이너에게 ‘내가 지표를 보니 이게 중요하다. 내 말을 따르라’ 고 하거나 (그 지표는 어디서 본 건데요, 도대체?) 혹은 디자이너가 ‘디자인이란 무릇 이렇게 하는 게 원래 맞다.’
내가 모르는 사이에, 모르는 장소에서, 모르는 사람들이 의사결정을 하는 조직에서 구성원은 불안함을 느낄 수밖에 없다. 불만을 제기하려고 해도 ‘네가 모르는 구두로 전해진 어딘가에서 정해진 것이라 받아들여’라는 대답이 돌아오기 때문이다. 리더가 해야 할 일 중에 가장 중요한 일은 ‘팀원들이 나와 비슷한 수준으로 의사결정할 수 있도록 정보가 흐르게 하는 것이다.
역할 조직에서 정보가 제대로 흐르지 않고 정치가 심화되면 각자의 정보 독점이 일어나면서 각자 성과보다는 ‘지위 관리’에 집중하게 된다. 각자의 지위와 권력을 유지하기 위해 역할을 나누고, 쪼개고, 허락을 구하고 결재받는 시간이 길어지며 의사결정과 업무 속도가 느려진다. 회의 아젠다로 ‘역할 나누기’가, ‘000팀, 검토해 주세요.’라는 요청이 업무에 자주 등장하게 된다. 의사결정을 위해 무슨 팀을 찾아갈지 찾는 일이 일상다반사가 된다. 정보의 독점으로 인해 각자의 정보 의존성을 이겨내지 못하면 업무 자체가 진행되지 않기 때문이다.
속도가 곧 경쟁력임을 표방하는 스타트업에서는 이보다 큰 위기신호가 없다.
리더가 없어도 스스로 의사결정할 수 있어야 한다.
마케팅 팀원 A은 마케팅 페이지에 특정한 로직을 추가하고 싶고 엔지니어 팀원 B는 리소스의 한계 때문에 거절합니다. 이 둘 사이의 업무적 갈등이 생겼다면 어떻게 해결해야 할까?
가장 자주 보는 풍경은 팀원 A의 마케팅 팀장, 팀원 B의 엔지니어 팀장이 만나 문제를 해결하는 것이다. 그러나 그들은 실무의 디테일을 알 수 없고 문제의 원인을 파악하기 위해 필연적으로 시간을 오래 사용한다. 게다가 마케팅 팀장은 팀원 A로부터 정보를 수집하고, 엔지니어 팀장은 엔지니어 관점에서 팀원 B에게 정보를 수집하니 서로의 관점이 더욱 멀어지기만 한다. 운이 나쁘다면 조직 간 알력싸움으로 변질되거나 더 상위리더십이 개입하면서 작은 불씨가 산불로 번진다. 중요한 것은 ‘이 정도로 시간과 노력을 투자할 만큼 큰 사안이 아니었다는 것’이다.
팀원들은 ‘팀장님이 문제를 해결해 주실 거야.’라고 생각하고 팀장은 ‘팀장인 내가 팀원 간 문제를 해결해야지.’라고 생각하지만 반은 맞고 반은 틀리다. 좋은 원칙이 있고 정보가 잘 흐른다면 누구나 좋은 의사결정을 할 수 있어야 한다.
예를 들면 담당자끼리 이야기하다가 풀리지 않으면 상위 담당자끼리 이야기해서 문제를 해결하는 시도는 자칫 편리해 보이지만 다음과 같은 문제를 야기한다
팀 자체적인 문제해결 능력이 약해진다 : 가장 전문성을 갖춘 개개인이 스스로 문제해결을 하고 실패 속에서 배우는 시스템이 구축되지 않는다.
의사결정 속도가 느려진다. 언제든 상위 의사결정자를 부를 수 있다는 것은 결국 실무자 둘이 이야기할 것을 상위 의사결정자가 결정한다는 뜻. 의존성을 만들면 당연히 의사결정 속도가 느려진다.
상위 리더십이 더 중요한 결정에 시간을 쓸 수 없다. 팀장들이 매사 ‘불 끄러’ 다닌다고 더 중요한 전략적 의사결정과 로드맵 수립 같은 일에 투자할 수 없다. 이는 모호한 전략과 애매한 실행으로 이어져 성과가 안 좋아지고, 성과가 안 좋아지면 조직 간 갈등이 증가하는 악순환이 시작된다.
의사결정자, 담당자, 커뮤니케이션 채널을 명확하게 지정한다.
프로젝트 중 구성원이 사람이 아니라 팀을 찾게 하는 현상(00일은 00팀과 이야기해 보시죠)은 발생하면 안 된다. 모든 일에는 담당자와 의사결정자가 있다. 팀은 일을 하지도 않고 결정도 내리지 않는 추상적인 존재일 뿐이다.
리더는 프로젝트에 앞서 다음과 같은 정보를 반드시 확보하고 담당자를 명확하게 위임한다. 00 프로젝트 담당자는 00님입니다. 하고 대충 넘어가지 말자.
Approval (책임자) : 이 프로젝트의 결과물을 책임지는 사람. 마케팅 프로젝트라면 마케팅 결과물과 유입자수, 비용에 대해 이야기할 때 논의할 사람.
Driver (실행자) : 프로젝트의 실질적 실행자. 가능한 책임자 = 실행자인 경우가 좋음. 프로젝트의 실행할 업무를 실제로 결정할 수 있는 사람.
Contributor (협업자) : 실행자를 도와 일을 프로젝트를 함께 할 사람들. 경우에 따라 하나의 부서만으로 구성될 수도 있고, 유관부서의 팀원들도 포함되는 경우가 있다.
Informed (관련자) : 프로젝트를 진행할 때 영향을 받는 사람. 위의 구현의 프로젝트 예시의 경우 메인홈화면과 관련된 리서치를 수행할 수도 있었던 유빈이 해당된다.
리더는 프로젝트 시작 전에 책임자를 분명하게 정해야 한다. 개인 실무자가 조직의 역학관계를 파악하는 것은 불가능하다. 정리된 내용은 관련 담당자 모두가 볼 수 있는 채널에 공유되어야 하며, 프로젝트 중 담당자 변경이 있다면 같은 채널에 이를 알려야 한다.
프로젝트 관련된 정보가 공유되고 원칙이 세워진다.
이번 프로젝트는 일정이 가장 중요합니다. 예산을 30% 정도 더 쓰더라도 기한 내에 마칠 수 있도록 해주세요. 비슷하게 진행되었던 작년 프로젝트 정보와 예산 관련 내용은 00 폴더에 정리해 두었습니다.
앞서 언급한 것처럼 모두가 좋은 결정을 하기 위해서는 프로젝트 관련된 정보가 투명하게 공유되어야 한다. 각 담당자는 프로젝트에 관련된 정보를 ‘파악하는 것’뿐 아니라 적절한 대상에게 공유하여 모두가 접근할 수 있도록 해야 한다.
또한 프로젝트의 ‘전략적 원칙’이 수립되어야 하는데, 여기서 말하는 전략적 원칙이란 프로젝트 목표를 달성하기 위해 ‘무엇을 얻고 무엇을 포기할지’ 명확하게 선언된 것을 말한다. 위에서 언급된 예시에서, 팀원들은 일정 산정과 예산 중 고민해야 할 때 오랜 회의가 필요 없이 특별히 많은 추가 예산이 요구되지 않는 경우 주저 않고 추가 인력을 채용하는 결정을 빠르게 내릴 수 있다. 명확한 프로젝트 원칙은 리더 없이도 구성원이 좋은 결정을 내릴 수 있도록 돕는다.
정보를 적시에 전달한다.
유빈은 왜 홈화면이 개편된다는 정보를 알 수 없었을까? 정보가 적시에 전달되지 않았기 때문이다. 정보는 필요한 사람이 찾아보기 전에 의사결정을 내린 사람이 책임지고 전달해야 한다. 이는 리더나 실무자 모두에게 해당되며 프로젝트 진행 중 개개인 구성원이 노력이 필요하다.
시점은 의사결정된 즉시가 가장 좋다. 위에서 정리된 의사결정자, 담당자, 커뮤니케이션 채널을 참고해서 담당자에게 전달한다.
예 : 지난주에 결정된 마케팅 디자인이 B안으로 채택되었으며 사유는 00와 같습니다. 관련되어 개발을 해주실 D님, 디자인팀 리더 F님 태그 드릴게요. F님은 담당 디자이너가 추가로 있다면 전달해 주시겠어요?
중요한 결정의 경우, ‘각자의 일’과 해당 결정이 어떻게 연결되어 있는지, 요구사항은 무엇인지 연결되어 전달되어야 한다.
(O) 전사적으로 이번 프로젝트의 주목도가 높아졌어요. 잘 진행되면 신규회원 유치에 더욱 도움이 될 것 같아요. 순간적으로 많은 트래픽이 몰려도 괜찮은지 한 번 체크해 주시겠어요?
(X) 이번 프로젝트 중요하니까 잘 좀 부탁해요.
마무리
다시 유빈의 이야기로 돌아오자.
유빈과 구현의 첫 합은 엉망이었지만, 이내 제대로 돌아오게 되었다. 유빈과 동준은 리서치 프로젝트가 시작되기 전에 관련된 담당자를 취합하는 업무 프로세스를 추가했고, PM 조직은 회사에서 진행되는 주요 런칭 일정을 공유하는 캘린더를 만들어 배포했다.
구현과 유빈은 창작자들이 후원금을 모을 수 있는 프로세스를 추가하는 프로젝트를 일사불란하게 함께 했고 덕분에 회원당 결제액이 140%나 증가했다.
2차 창작 크리에이터 이코노미를 키워가는 유빈의 조직. 앞으로의 여정은 계속된다!!
