영향력으로 조직을 이끄는 법

동료 제품 담당자들과 이야기를 하면 항상 나오는 이야기가 엔지니어들이 자신의 말을 너무 안듣고, 본인들이 원하는 제품을 만들기 위해 대부분의 시간을 엔지니어들을 설득하고 설명하는데 시간을 낭비 한다는 불평으로 끝이 나곤 한다. (물론, 엔지니어들은 답답하고 무능한 제품 담당자 때문에 인생이 피곤하다고 불평을 할 것이다).

이런 고충이 있는 이유는 제품을 책임지고 있는 제품 담당자가 제품에 기여를 하는 팀원들에 대한 인사권이 전혀 없기 때문이다. 대부분의 테크 회사들은 직군 별로 조직이 나뉘어져 있고, 다양한 직군에 있는 사람들이 제품을 중심으로 모이는 XFN (= cross-functional) 구조로 팀이 조직되다 보니 팀 내 본인 상관이 아닌 사람의 말을 듣지 않아도 되는 여지가 생기게 된다. 예를 들어, 제품의 완성도를 높이기 위해 골치 아픈 버그를 몇 개 잡아 달라고 제품 담당자가 어느 엔지니어에게 고쳐달라고 하면, 엔지니어는 해당 버그를 잡기 위해 개고생 해야할 것이 눈에 선한데 다음 인사 평가때 멋진 업적을 써서 낼 수 없을 것 같아 (= ‘불과 버그 몇 개 잡았음’) 각종 핑계를 대면서 제품 담당자가 부탁한 일을 미루거나 빠져나가려고 한다.

제품 담당자 직군을 mini-CEO 라고 소개되는 경우가 종종 있는데, 위의 상황처럼 제품 담당자가 팀을 효과적으로 이끌지 못하는 상황이 계속되면 제품 담당자는 nano-CEO는 커녕, 권위는 하나도 없고 책임은 무한대로 지는 욕받이 역할만 하게 된다. 😭 급하게는 욕받이를 면하고, 궁극적으로는 제품 담당자의 원래 역할인 제품에 큰 임팩트를 주기 위해서는 제품 담당자는 인사권이 없이 영향력으로 조직을 이끄는 법을 필수적으로 체득해야 한다 (= ‘lead by influence’).

영향력으로 조직을 이끌기 위해서는 그 무엇 보다 의사소통 능력이 좋아야 한다. 제품 담당자가 의사소통 능력이 좋다고 하는 것은 상대방에게 내 의견을 잘 전달한다는 것을 넘어, 궁극적으로 나의 주장을 상대방이 수용하고 행동에 옮긴다는 것을 뜻한다. 즉, 설득력이 높아야 한다는 것. 남을 설득 시키기 위해서는 말을 많이 해야 하는 경우가 대다수여서 (이렇게 설명하고, 저렇게 설명하고, 부연 설명하고… 등등) 한국인 MBA / PM 지망생들이 흔히 ‘PM 하려면 영어를 잘 해야 되나요?’라는 질문을 하는 것 같은데 (그런 분들은 이 블로그 글 참고), 영어 자체를 잘해야 하는 것은 아니지만 논리 정연하게 나의 생각을 전개할 수 있어야 하고, 상대방의 의도를 파악하고 상황에 맞게 강약 밀당을 조절할 수 있는 active listening 실력이 필요하다. 이런 의사소통 실력 향상에 도움이 되는 책들과 기법들이 물론 여럿 있지만 (예: The Pyramid Principle), 결국엔 많은 연습과 실전을 통해 경험을 쌓고 지속적인 피드백을 받는 것이 가장 중요하다.

이해 관계자들과 1:1을 자주 하는 것 역시 영향력을 효과적으로 행사하는데 큰 도움이 된다. 1:1 미팅을 통해 영향력을 행사할 수 있는 방법이 세 가지가 있는데, 첫 째는 상대방의 숨은 동기 및 욕망을 이용하는 것이다. 아까 예로 든 버그 따위(?)는 고치기 싫은 엔지니어가 인사 평가에 도움이 되는 ‘executive visibility (임원들의 주목)’를 굉장히 원한다는 것을 제품 담당자가 1:1을 통해 알아낸다면 이 정보를 이용하여 ‘사용자 경험 개선 경과 보고’ 임원 미팅에 엔지니어를 초대함으로써 그의 마음을 움직일 수 있을 것이다. Skip level 1:1을 통해 간접적인 영향력을 행사하는 것이 두 번 째 방법이다. Skip level 1:1 이란 내 보스의 보스, 혹은 내 이해관계자의 보스와의 1:1 미팅을 지칭한다 (= 나랑 직접 연결된 사람을 ’skip’하고 그 윗 사람을 만난다는 뜻). Skip level 들에게 나의 주장에 대한 피드백과 동의를 받은 후 이해 관계자들과의 1:1에서 ‘너네 보스도 나랑 비슷하게 생각하는거 같어’ 라고 말을 하면 내 주장이 조금 더 무게감 있게 전달 될 것이다. 물론 여기서 조심해야 할 것은 이해 관계자들들의 권위가 무시 당했다는 느낌이 들지 않도록 선을 잘 조절하는 것. 마지막 방법은 1:1 미팅을 통해 이해 관계자들 한 명 씩 설득하여 서서히 ‘대세’를 만들어 나가는 것이다. 한 명이 설득되면 ‘저 옆에 누구도 여기에 동의해’라고 말하여 그 다음 사람을 설득하고, 이 작업을 반복하여 모두가 대세에 참여를 하게 되는 구조를 만들어 버리면 가랑비에 옷 젖듯 조직이 이미 내가 원하는 방향으로 향해 있을 것이다.

본인의 아이디어를 문서화 하여 적시에 이용하는 것도 좋은 방법이다. 문서로 나의 생각을 정리해 두면, 우선 그 과정에서 아이디어가 조금 더 정제되는 효과도 있을 뿐더러, 발표 자리나 시간에 구애 받지 않고 조직 내의 더 많은 사람들에게 아이디어를 공유할 수 있고, 또한 아이디어가 ‘공식화’ 되었다는 느낌도 조직 전반에 줄 수 있다. 어떤 문제에 대해서 여러 이해 관계자들이 중구난방할 때 ‘이렇게 생각해 둔 문서가 있는데 참고 하시죠’ 라고 한다면 의견의 교통 정리를 나에게 더 유리한 방향으로 끌고 가기가 더 수월할 것이다. 단 문서화된 아이디어는 개개인의 ‘발표 전달력’에 관계없이 많은 사람들에게 높은 설득력을 가져야 하므로 주장, 논거, 데이터/수치 등이 명확하고 논리적으로 정돈된 문서를 작성해야 한다. (그렇지 못한 경우엔 공개적으로 더 많은 사람들에게 망신을 당할 수 있기에, 문서 작성 시 정말 신중을 기해야 함)

모든 ’soft skill’이 그렇지만 위의 방법들이 성공 공식은 전혀 아니며, 개인의 성향과 능력에 따라 자신에게 맞는 방법을 체득해야 할 것이다. 자신의 스타일에 맞게 조직을 효과적으로 영향을 줄 수 있는 실력이 갖추어진다면 제품 담당자는 비로서 mini-CEO가 될 수 있는 여지가 생기는게 아닌가 싶다.

우리 동료 제품 담당자 분들… mini-CEO 함 가즈아! 💪👊

클리브랜드의 도굴꾼

예전 링크드인에 다닐 때 있었던 일이다. 신제품 관련 업무를 많이 하다보니 업무의 많은 부분이 새로운 제품 컨셉에 대한 사용자 반응 조사, 그리고 시장 분석에 따른 새로운 기능들을 제품에 추가하거나 변경하는 일이었다. 애자일한 자세로 사용자의 반응을 열심히 제품에 반영하기를 반복하며 신제품을 만들어 나갔다. 그리고 어느 순간 전체적인 제품을 검토해보니 초반에 기획했던 특정한 사용자 집단을 위한 단순하고 빠른 업무 효율 제품이 아닌 회사 전체 조직을 대상으로 한 복잡한 데이터 포털이 되어버린 것을 발견하였다. (앜!!)

이런 어처구니 없는 상황에 당황하고 있을 때 팀 내 전략을 담당했던 직원이 한 마디를 한다. ‘우리는 클리브랜드의 도굴꾼을 위한 제품을 만든 것 같아. (We built for gravediggers in Cleveland’).’ 링크드인은 전문가 기반 소셜네트워크 서비스이기에 어떠한 특정 직종의 사용자들의 업무/커리어와 관련하여 어떻게 성공을 도울 수 있을지를 고민하며 제품 개발을 한다. 대도시의 리크루터, 인사담당자, 영업사원, 마케터, 구직자 등이 주 대상인데 클리브랜드의 도굴꾼이라니… 한마디로 쓸데 없는 사용자 집단을 대상으로 제품을 만들었다는 자조 섞인 한탄이었던 것이다. 

열정이 있는 제품 담당자라면 자신의 제품이 완벽하기를 원한다. 설령 그것이 불가능하다는 것을 알고 있더라도 완벽에 최대한 가깝게 갈 수 있도록 아주 세세한 부분까지도 극진한 노력과 시간을 투자하여 제품의 완성도를 높이려 한다. 하지만 가끔 이런 열정이 과해 주 사용자가 아닌 집단(= 클리브랜드의 도굴꾼)의 니즈마저 완벽하게 반영하려고 하여 전체적인 제품이 너무 복잡해지고 사용성이 되레 떨어지는 경우가 생긴다. 이런 경우 해당 제품은 모두가 사용할 수 있지만 그 누구도 이상적인 제품 경험을 할 수 없게 된다. 말 그대로 과유불급.

이런 경우를 방지하기 위해선 내 제품의 잠재 고객에 대한 확실한 정의와 이에 따른 냉혹한 선택과 집중을 필요로 한다. 아무리 페르소나 기법을 통해 사용자들에 대한 깊은 이해를 했더라도 페르소나가 너무 많거나, 페르소나의 니즈들이 상충하는 경우는 제품이 산으로 가는 지름길이다. (예: 이탈리아 밀라노 고급 패션쇼 느낌이 나는 옷을 구매하고 싶은 페르소나와 건설 현장에서 편하게 작업할 수 있는 옷을 원하는 페르소나를 모두 만족시키는 옷가게를 만드려고 해봐라).

애자일, 페르소나, 사용자 중심 디자인 등 멋진 제품 개발 기법을 다 동원 하였음에도 최종 제품이 찜찜하다면 잠시 돌아서서 생각해보라… 우리는 혹시 클리브랜드의 도굴꾼을 위한 제품을 만든 것은 아닌가.

.

Launching? Landing!

https://commons.wikimedia.org/wiki/Apollo_11#/media/File:Apollo_11_Lunar_Lander_-_5927_NASA.jpg

구글 내부에서 높은신 분들과 회의를 들어가면 자주 받는 질문이 있다. ‘앤드류 지금 하고 있는거 언제 착륙 시킬꺼야? (Andrew, when will you land this [product name]?)’ 초반에 이런 질문을 들을 때 속으로 ‘응? 착륙? 뭘 착륙하지? 나 제품 관리자인데? ‘앤드류, 그 제품 언제 출시 (launch) 할꺼야?’가 더 맞는 질문 아닌가?’라고 생각하곤 했다. 나중에 주변 연차 많은 분들께 물어보니 몇 년 전 어느 구글의 엔지니어링 리더께서 의미 없는 론칭 지향적인 (launch-oriented) 문화를 바꾸고자 아폴로 11호 사건을 예로 들면서 제안한 개념이라고 한다. (실제로 이에 대한 내부 문건도 있음).

<참고: 아폴로 11호 세 줄 요약>

1969년 7월 16일 아폴로 11호가 미국 플로리다 주에 있는 케네디 우주센터에서 발사된다. 거대한 새턴 로켓의 엄청난 추진력으로 지구 궤도를 벋어나 달 까지 날아간 아폴로 11호는 이글 달 착륙선을 이용해 인류 역사상 처음으로 달에 발을 밟는 쾌거를 이룬다. 이 당시 닐 암스트롱은 그 유명한 ‘한 인간의 작은 발걸음이지만, 인류에게는 커다란 도약이다’라는 명언을 남기기 전 작전 수행 관련 상황 보고를 한다: ‘휴스턴, 여기는 고요의 기지이다. 이글은 착륙했다. (Houston, Tranquility Base here. The Eagle has landed.)’

우리는 아폴로 11호를 인류가 최초로 달에 착륙한 (land) 역사적인 우주 프로그램으로 기억하지, 최첨단 새턴 로켓을 이용하여 멋지게 우주선을 발사한 (launch) 사건으로 기억하지 않는다. 그 이유는 단순하다. 아폴로 프로그램의 최종 목표는 인류를 달 표면에 착륙시키고 안전하게 돌아오는 것 이었기 때문이다.

제품 관리를 대하는 태도도 마찬가지여야 한다는 것이 이 ‘랜딩 (landing)’ 개념의 핵심이다. 즉, 1) 제품 관리에서 제품 론칭은 끝이 아닌 과정일 뿐이며, 2) 중요한 것은 론칭 같은 중간 과정의 화려함이 아니라 ‘달 착륙’과 같은 궁극적인 최종 목표 달성이라는 것이다.

제품을 대하는 태도를 론칭에서 랜딩으로 관점을 바꾼다면 다음과 같은 효과를 얻을 수 있다:

용감한 (옳은) 의사결정

랜딩의 개념을 가지면 제품 담당자가 제품을 통해 이루고자 하는 최종 목표에 대해 더 명확한 정의를 내리고, 이에 기반한 의사결정을 할 수 있다. 제품 담당자의 목표가 ‘신제품 론칭’ 보다 더 명확할 수 있냐고 반문할 수 있지만 그것은 마치 자동차를 사는 이유가 통근, 레져 등이 아닌 ‘운전하기 위해서’라고 말하는 셈이다. 수단이 목적이 되는 것이다. 너무나 당연한 개념이라 이런 실수가 없을 것 같지만 일에 몰입하다 보면 본의 아니게 수단과 목적이 전도되는 경우가 허다하다. 긴박한 제품 출시일에 맞추어 이런 저런 기능을 빼거나 대거 수정하여 제품을 출시하여 ‘론칭’은 성공했지만 궁극적인 목표인 고객 문제 해결을 ‘랜딩’ 못하는 것이 대표적인 예이다. 랜딩의 개념이 확실하다면 제품 출시를 연기 하더라도 고객 문제 해결에 있어 필수적인 기능들을 고집할 수 있는 용기와 논리가 생길 것이다.

목표 달성 수단에 대한 유연함

더 이상 론칭이 최종 목표가 아닌 랜딩 과정의 한 가지의 수단이라면 제품 담당자는 최종 목표 달성을 위해 유연하게 다양한 제 2, 제 3의 수단을 고려할 수 있는 여유가 생긴다. 예를 들어 ‘레드오션 마켓에서 시장 점유율 1위 유지’라는 목표가 있는 제품이 있다고 치자. 이런 치열한 상황 속에서 해야할 일 중 하나는 당연히 더 혁신적인 제품을 론칭하여 경쟁사 보다 앞서 가는 것일 것이다. 하지만 아무리 화려한 마케팅 지원을 받으며 신제품을 론칭하여도 시장 점유율이 점점 밀린다면 어떻게 할 것인가? 론칭에만 집중한다면 더 새로운 기능, 더 새로운 제품들이 나올 때 까지는 다른 방법이 없다. 하지만 랜딩에 초점을 맞춘다면 론칭과 더불어 가격 정책, 기존 제품 확장 및 유지 등 론칭이 따로 필요 없는 수단들을 동원하여 목표 달성에 기여할 수 있을 것이다.

화려하지 않지만 중요한 일들에 대한 인정

론칭은 거의 언제나 제품 주기에서 가장 화려하고 주목받는 마일스톤이다. 그렇기 때문에 론칭을 진두지휘한 담당자도 덩달아 화려한 주목을 많이 받게 마련인데, 이런 개인적인 유명세를 맛보게 되면 ‘the next shiny launch’를 찾아 떠나고 싶은 것이 많은 사람들의 심리이다 (= ‘자.. .봤지? 내가 이 정도로 해 놓았으니까 알아서 잘 마무리 해’). 이렇게 되면 아무리 중요한 일이더라도 ‘화려하지 않아서’, ‘나한테 개인적으로 득이 되는 것이 없어서’ 간과하는 경우가 생기며, 이런 과정이 반복되면 아무리 멋진 론칭을 경험했다 한들 결국엔 ‘훌륭할 뻔 했던’ 제품 밖에 되지 못하는 것이다. 반면 제대로 된 랜딩을 목표로 한다면 중요한 일에 대해선 화려함에 관계없이 같은 열정으로 제품의 성공에 기여할 수 있게 된다.

.

모든 랜딩은 성공적인 론칭이 필요하지만 모든 론칭이 성공적인 랜딩을 가져다 주지 않는다. 론칭이 주는 피상적인 화려함의 노예가 되지 말고 최종 목표인 랜딩에 충실하자. 랜딩이 중하디.

.

사진: Buzz Aldrin removing the passive seismometer from a compartment in the SEQ bay of the Lunar Lander.

조직의 동의를 얻는 법

https://pixabay.com/en/paper-business-finance-document-3213924/

제품 담당자의 역할 중 가장 기본적이면서 동시에 가장 어려운 것 중 하나가 다양한 이해관계자들의 복잡한 관계들을 조율하고 설득하여 제품을 앞으로 끌고 나아가는 것이다. 실리콘밸리는 부서 간의 협업으로 팀이 구성 및 진행되고 (cross-functional, XFN 이라고 흔히 지칭), 제품 담당자들이 이런 협업 팀원에 대한 직접적인 권한이 없는 경우가 대부분이라 이해관계자들의 상충된 목표를 조율하는 것이 어지간히 어려운 것이 아니다. 더욱이 전략적 중요도 및 복잡도가 높은 제품을 담당할수록 다양한 부서의 높으신 분들의 ‘좋아요’까지 받아야 하는데, 이러다 보면 제품 출시일은 멀어져 가고 팀원들은 기가 빠지며 결국엔 모두가 제품 담당자를 원망하기 시작한다. 즉, 한번 꼬이기 시작하면 완전 총체적 난국. ㅠㅠ

이런 상황을 모면하기 위해서 제품 담당자는 조직의 동의를 얻는 시간을 최소화하는 것에 노력을 기울여야 한다. 조직 구성원 및 의사결정권자들의 ‘오케이’를 받는 방법은 사람마다, 또 조직 특성 마다 다르겠지만 다음은 내가 많은 시행착오를 거치며 터득한 몇 가지 ‘빠르게 동의에 이를 수 있게 하는 기법’들을 정리 및 공유:

기본 (default) 상황을 yes로 설정하고 이해관계자들에게 반박을 하도록 포지셔닝 하기

나는 예전에 이메일 상으로 어떤 안건에 대한 동의를 구할 때 그 내용에 대해 설명을 하고 ‘이렇게 해도 괜찮나요?’ 라고 묻곤 했다. 이런 경우는 이메일 수신자가 ‘오케이’라고 답변을 하지 않는 이상 기본 상황이 ‘안됨’이다. 행여나 안건에 동의를 전적으로 한다고 해도 답변이 오지 않으면 일을 진행할 수 없는 상황이기에 시간을 낭비하기 일쑤다.

요즘엔 많은 경우 ‘위 안건을 진행할 예정이니, 피드백 및 기타 의/이견 있으시면 알려주세요’ 식으로 이메일 스타일을 바꾸어 쓰고 있다. 이 경우엔 내가 강력하게 안건을 특정한 방향으로 추진하고 있다는 자신감을 수신자에게 전달할 수 있고, 동시에 ‘잘 진행되는 일인 것 같은데 정말 큰 문제가 있는 것이 아니면 굳이 꼬투리 잡을 필요 없지’식의 심리를 자극시켜 그들이 동의하는데 영향력을 끼칠 수 있다. 이런 적극적인 포지셔닝은 이메일 답변이 오지 않은 상황에서도 ‘암묵적 동의’라고 우길 수 있는 장점도 있지만, 상대방의 기분이 상할 가능성을 고려해 ‘이견이 있으시면 다음 주 수요일까지 답변 주세요’ 식으로 타임라인을 정해주면 예의마저 챙길 수 있다.

이해관계자 중 의사결정권자인 사람과 아닌 사람을 구분하기

이해관계자들 모두가 의사결정권자가 아니다. 예를 들어 신제품 출시 결정을 할 때 PR 부서는 그 제품에 대한 홍보 및 예상되는 질문/논란에 대한 대응을 제품팀에게 지원을 해 주는 역할을 수행해야 하기에 이해관계자 이지만 의사결정권자는 아니다. 즉, 예상되는 문제가 있다면 PR 부서는 제품 팀에게 그 문제의 위험성을 알리고 강력한 제품 출시 지연 권고는 할 수 있어도, 그 위험성을 이유로 제품 출시를 막을 수 있는 권한이 있는 것은 아니다. 이런 의사결정권이 없는 이해관계자들의 ‘소음(?)’을 줄이기 위해선 동의를 반드시 받아야 하는 의사결정권자들과 그들의 결정으로 인해 영향을 받는 순수 이해관계자들을 구분하고 그들의 요구를 다르게 받아드릴 수 있어야 한다.

이메일로 동의를 구하는 경우 To 에 의사결정권자를 열거하고 나머지는 Cc로 처리한 후 의사결정권자들을 직접 호명하여 그들의 동의를 구하는 방법이 꽤 괜찮은 전략이다 (예: Peter, please approve this plan) . 물론, 이것은 의사결정권이 없는 이해관계자들의 의견을 무시하라는 것이 절대 아니다 (그랬다간 제품 담당자로써 처참히 실패하는 지름길). 반드시 사전에 이해관계자들의 의견 취합 및 조율은 하되, 최종 의사결정에 있어서 최단거리의 길을 (= 의사결정을 해야 되는 사람들 관여) 택하라는 것이다.

짧은 주기의 업데이트를 통해 작은 변화에 대한 동의를 반복적으로 구하기

제품 담당 멘토링을 받으면 가장 자주 듣는 ‘제품 담당자들의 가장 큰 실수’가 있는데, 사무실 구석에서 몇 주 간 고생해 너무나 완벽하고 멋진 제품 제안서를 써 왔더니 그 모두가 무시하고 코드 한 줄 쓰여지기 전에 폐기되었다는 이야기다. 아무리 멋진 아이디어라도 조직에 공감대를 형성할 수 없으면 실현 가능성이 0으로 수렴 되기에, 제품 담당자는 제품에 대한 비전과 아이디어 만큼 그것을 구현할 수 있는 공감대 형성에 많은 시간을 투자해야 한다.

이럴 때 효과적인 것이 짧은 주기의 업데이트를 이해관계자들과 자주 하는 것이다. 잦은 만남을 가지면 동의를 해야할 부분들을 각개 격파를 할 수 있는 여지가 생긴다. 작은 부분들 하나 씩 의/이견을 취합하여 조율하고 동의에 이르는 과정을 반복하다 보면 (= agile한 공감대 형성) 큰 그림이 완성되는 상황에 더 쉽게 도달할 수 있다. 간단히 말해 개구리를 상온의 물이 담긴 냄비에 넣고 서서히 열을 가하는 것과 뜨거운 물을 갑자기 부어 화들짝 놀래키는 것의 차이인 것이다.

어느 크기의 변화가 동의를 얻기 더 쉬울까?

이해관계자들의 의/이견이 blocker인지 strong opinion인지 구분하기

만약 이해관계자들의 의/이견이 없다면 빠르게 동의에 이를 수 있겠지만, 다양한 의견의 충돌 및 정-반-합의 과정은 더 좋은 결과를 가져다 주는 건강한 스트레스이기에 무조건 다른 의견의 형성을 막는 전략을 택하는 것은 어리석은 일이다. 또 현실적으로도 중요한 안건의 의사결정 과정에 있어서 이해관계자들의 의/이견이 없을 수 없다. 결국 중요한 것은 이런 의견들을 빨리 취합하여 조율하는 것인데, 이것을 효율적으로 처리하는 방법 중 하나가 그들이 제시한 의견이 blocker인지 strong opinion인지 확인하는 것이다. Blocker란 제시한 문제점을 해결하지 않으면 해당 안건을 진행시킬 수 없다는 것이고 strong opinion이란 말 그대로 당사자의 (강한) 의견이라는 것인데, 의견을 이 두 가지로 분류한 후 blocker를 위주로 문제를 해결하면 많은 시간과 노력을 아낄 수 있다.

아까 위의 예를 다시 들어, 어느 제품을 출시할 때 높은 가격 책정으로 인해 부정적인 언론이 우려되어 단가를 인하할 수 있을 때 까지 출시 유보를 주장한 PR/마케팅 부서가 있다고 가정하자. 이런 경우 제품 담당자는 해당 부서에게 blocker인지 strong opinion인지 구분해 달라고 요청하고, 부정적인 언론이 제품 수요에 지대한 영향을 끼쳐 사업 성과에 문제가 있을 것 같기 때문에 blocker라고 답변을 받으면 재고를 하면 되고, 반면 부정적인 언론이 지금 상승 중인 회사 선호도 이미지에 누를 끼칠 수도 있을 것 같다는 생각이 든다고 답변을 받으면 (대체적으로, 특히 데이터가 없을 경우) strong opinion으로 취급하고 넘어가면 되는 것이다. 이 상황에서 blocker가 아니라고 의견을 폐기하는 것 보다 다음 버전 혹은 추후 집고 넘어가야 할 상황으로 명시하고 나중에 까먹지 않고 처리한다면 협업 관계를 더 돈독하게 할 수 있는 이상적인 상황까지 만들 수 있다.

나도 최근에 큰 변화와 논란이 수반되는 프로젝트 몇 개를 수행하면서 이 기법을 많이 사용하기 시작했는데 , 내가 담당하는 제품과 관련하여 받은 80%의 의견들은 blocker가 아니었다. (상상해보라, 그 80%가 blocker인 줄 알고 다 대응하고 전략을 수정하였으면 걸렸을 추가 시간과 노력을…😱)

.

아무리 위 기법들이 그럴 듯 하게 들려도 사실 모두의 동의를 빠르게 이끌어 내는 것은 정말 어려운 일이다. 그렇다고 동의를 얻지 못해 프로젝트를 진행시키지 못했다는 것은 제품 담당자의 변명이 될 수 없다. 제품 담당자는 그 제품의 성공에 최종 책임을 지는 사람이기 때문이다. 어떻게 보면 동의를 얻지 못했다는 핑계는 제품 담당자로써 능력이 없다는 뜻일지도 모른다. 정연한 논리, 제품에 대한 뜨거운 열정, 자신의 주장을 뒷받침 해 줄 수 있는 데이터, 그리고 위 기법들 + alpha를 총 동원하여 조직의 동의를 얻고 제품을 성공의 방향으로 계속 끌고 나가야 한다. (Aㅏ… 힘들어 ㅠㅠ)

똥에 광 내기: 언제 조직을 떠나야 하나

커리어를 쌓다 보면 가끔씩 자신이 잡고 있는 동아줄이 썩어 있는 상황에 직면 하거나 너무나 안좋은 조직에 엮여 있음을 발견하고 처해진 상황에서 빠져 나갈 궁리를 해야할 때가 생긴다. 나의 커리어 운신의 대부분은 가는 곳의 기회가 너무나 기대되는 긍정적인 상황이었지만 그래도 가끔씩은 ‘아 이런 썩은 조직에 계속 있다간 X 되겠다’ 라는 생각이 들어 현 상황 탈출에 모든 것을 걸었던 때도 있었다. 이런 상황들은 직면하는 순간 싸한 느낌이 바로 오는 경우가 대부분이지만 간혹 배와 같이 침몰하기 직전까지 인지하지 못하는 경우도 있기 마련이다.

컨설팅 업계에 있던 시절 ‘똥에 광 내기 (polishing the turd)’ 라는 표현을 습득(?) 했는데, 쓸데 없는 일에 많은 시간과 노력을 퍼 붙는 행위를 지칭하는 말이다. 중요한 클라이언트 발표를 앞두고 밤 새 파워포인트의 폰트 크기, 장표 줄 맞춤 등 본질에 아무 상관 없는 것들을 최적화 시키는 것이 ‘똥에 광 내기’의 좋은 예. (그래서 결국 그 전날 까지 “client_strategy_deck_final.pptx” 이였던 파일이 “client_strategy_deck_final_final_v23_edited.pptx” 로 바뀌고…-_-)

똥은 아무리 광을 내어도 똥일 뿐, 아무런 가치를 창출하지 못한다. 나는 조직 내에 이런 ‘똥에 광 내기’ 행위가 만연하다는 것을 파악하는 순간 비상 탈출 전략을 실행에 옮기곤 했는데, 지금 돌이켜 보면 내 커리어 앞에 있는 지뢰들을 피해갈 수 있게 해준 좋은 원칙이라고 생각한다.

건강하고 빨리 성장하는 유망한 조직은 사업의 본질적인 문제를 집중해서 빨리 해결하기 때문에 건강함과 성장률을 유지할 수 있는 것이다. 조직의 많은 사람들이 ‘똥에 광 내기’ 짓을 하고 있다는 것은 조직에서 본질적으로 중요한 것이 무엇인지 파악할 능력이 없거나, 중요한 곳에 자원을 효율적으로 배분할 수 있는 의사결정 구조가 없다는 것을 뜻할 수 있다. 아니면 더 슬픈 경우, 그 조직은 ‘똥에 광 내는’ 짓 보다 더 중요한 일이 없을 수 있는 것이다. 그런 조직에 자신의 커리어를 베팅하기에는 너무나 위험하지 않은가?

사장이 가볍게 던진 곁다리 질문에 완벽한 답변을 하기 위해 전 조직을 동원하고 쪼아대는 중간 관리자, 부서 간 ‘힘 싸움’ 때문에 협업 제안서를 무한 뺑뺑이 돌리는 임원, 잘 나가는 사람 밑에 딸랑딸랑 줄 서기 위해 실패가 눈에 선하게 보이는 프로젝트를 반론 하나 없이 끌고 가는 팀장… 모두 ‘똥에 광을 내는’ 사람들이다. 놀랍게도 이런 행위는 효율과 결과를 중시하는 실리콘밸리에서도 가끔씩 찾아볼 수 있다.

우리는 평생 살면서 개인적으로 만족감 넘치며 사회적으로도 의미 있는 일을 발견하고 기여할 수 있는 기회와 시간이 많지 않다. 만약 자신이 속한 조직에 ‘똥에 광 내기’ 행동이 보이고, 또 그것이 조직 전반적으로 만연하다고 생각 된다면 자신의 커리어를 위해 큰 결정을 내리는 것을 권한다.

PS – 물론, 똥인지 된장인지 구분하는 능력을 우선 갖추도록.

이미지 출처: 웹사이트