성공적인 외노자/직장인으로 살아남는 법 #2
지난번에 이어 이번에도 아무도 관심 없는 스킬을 공개하고자 한다. 바로 "백문이불여일견"이 그것이다. 알고는 있지만 실천으로 옮기기 쉽지 않은 이 기술에 대해 조금 더 자세하게 다뤄보자.
서바이벌 스킬 #2: 백문이불여일견 (Seeing is Believing)
보여주는 것이 백 번 듣는 것보다 낫다.
동서고금의 이 진리는 당연히 해외에서도 통한다. 아니, 오히려 해외에서 더 통하는 진리라고 할 수 있다.
경영진들의 관심사는 "결과"이지 누구의 말이 더 "합리적인지"가 아니다. 그러나 회의를 할 때 우리는 이 사실을 종종 잊고, 토론에서 이기려는 노력을 한다. 토론에서 이기는 것은 결국 자기만족에 불과할 뿐, 경영진을 설득하는 것은 확실한 "결과" 혹은 "결과"에 가까운 것이다. 이 사실을 깨닫게 되면 경영진을 설득하는 데 있어 훨씬 유리한 고지를 취할 수 있다.
이번에도 두 가지 예를 들어보자.
첫 번째 사례는 미국 팀에 갓 조인했을 때 있었던 일이다. 당시 우리 팀은 무려 16가지나 되는 서로 다른 보고서 양식을 사용하고 있었는데, 복잡한 규칙에 따라 서로 다른 양식을 선택해야 했기 때문에 오류도 많고 효율도 무척 떨어지는 상황이었다. 경영진은 이 문제를 해결하고자 직원들을 모아 브레인스토밍을 했다.
사공이 많으면 배가 산으로 가는 법. 계속 변죽만 두드리는 아이디어들만 난무하는 가운데, 괜찮은 아이디어가 하나 떠올랐다. 양식의 각 항목을 모듈화 해서 통일된 양식에 담고, VBA를 통해 조건부로 각 모듈을 보여주자는 아이디어였다. 당시 미국에 온 지 얼마 안돼 영어가 서툴렀던 나는 한참을 망설이다 아이디어를 제안했다. 그러나 반응은 너무나 냉랭했다. 마치 내 얘기를 듣지도 않은 것처럼 무시하고 지나가버린 것.
돌이켜 생각해보니 영어도 형편없었고, 직원들이 IT 관련 지식이 없다 보니, 무슨 말인지 이해조차 못했을 거라는 생각이 들지만 당시에는 무척 상처가 컸다. 나름 회심의 아이디어라고 낸 것이 완전히 무시를 당했으니 말이다.
결국 회의는 다음 주에 후속 회의를 하는 것으로 결론이 났다.
나는 내 아이디어에 확신이 있었고, 후속 회의에서는 반드시 내 의견을 다시 피력하고 싶었다. 그러나 영어는 형편없었고, 신입 팀원에게는 많은 신뢰가 주어지지 않았다.
그래서 유튜브를 보고 Stack Overflow를 보며, 생전 처음으로 VBA를 써가며 통합된 양식을 만들었다. 물론 완벽하지는 않았지만, 어떻게 작동하는지 보여줄 만큼은 되었다.
후속 회의시간이 되었고, 모두들 회심의 아이디어를 준비해온 가운데, 나는 스크린에 양식을 띄워놓고 사람들을 기다렸다. 사람들이 모두 들어서자 나는 내가 준비해온 것을 보라며 내가 만든 양식을 시연했고, 결과적으로 경영진은 내 아이디어를 채택하게 되었다. 다른 이들은 여전히 "말"뿐인 아이디어를 가져온데 반해 나는 이미 작동하는 "제품"을 가져왔으니 말이다.
이때 얻었던 경험은 내 업무 방식에 커다란 변화를 가져왔다. 그때부터 말로 누군가를 설득하기보다는, 최대한 결과로, 그리고 훗날 MBA에서 배우게 된 MVP(Minimally Viable Product, 핵심 기능만 보여줄 수 있을 정도로 제작된 시제품)의 개념으로 보여주게 되었던 것이다.
두 번째 사례는 바로 지난번에도 다루었던 매니저와의 대결(?)이다.
당시 매니저는 계획이 완벽했다. 다만 매니저 자신이 IT 스킬이 없기 때문에, 모든 개발을 IT팀에 맡겨야 하는 약점이 있었다. 식당 주인이 요리를 못하면 요리사가 식당을 좌지우지하듯, 전적으로 IT팀에 의존하는 모델이 제대로 작동할리가 없었다. IT팀은 매니저의 요구를 늦게 들어주거나, 제대로 들어주지 않기 일수였고, 그 때문에 기존에 2년으로 계획한 시스템 개발 프로젝트가 4-5년이나 걸리게 되었던 것이다.
반면 나는 계획은 별로 없었지만 앞서 말한 MVP가 있었다. 이 팀에 오기 전에 관련 스킬인 파이썬과 태블로 등을 익혔고, 배운 기술을 활용해 프로젝트의 꽃인 데이터 대시보드와 데이터 처리 엔진을 스스로 만들었다. IT팀의 지원 없이 스스로 개발했기 때문에 속도도 빨랐고, 요구사항을 IT팀에 전달하는 과정에서의 오류 또한 전혀 없었다. IT팀은 처음에는 회의적으로 보다가, 우리 팀에서 직접 개발을 해버리니 나중에는 위기의식을 느껴서인지 적극적으로 지원에 나서기까지 했다.
경영진이 결국 두 사람 중 누구의 손을 들어줄지는 불 보듯 뻔한 일이었다.
처음에는 일견 완벽해 보이는 매니저의 계획을 수용한 경영진이었으나, 거의 실시간으로 발전하는 내 MVP 대시보드를 본 경영진은 생각을 바꾸고 매니저의 계획에 의문을 던지기 시작했다. 가장 결정적인 포인트는 역시 시간이었다. 경영진이 어떤 아이디어를 제시하면 바로 대시보드를 업데이트해서 가져오는 나와는 달리, 매니저는 계획서를 수정해서 들고 올 뿐이었다. IT팀에 전적으로 의존하는 매니저로서는 달리 다른 수도 없었기 때문에, 내가 들고 온 대시보드의 단점을 애써 부각하는 것 외에는 할 수 있는 일이 없었다.
결국 매니저가 그동안 개발했던 시스템은 거의 폐기처분에 가까운 결정이 내려지고, 내가 개발한 대시보드가 채택되면서 프로젝트까지 리드하게 되었다. 게다가 부수적인 성과로 부서의 MD가 있는 런던으로 근무지를 옮기게 되었으니, 완벽한 결과라고 할 수 있다. (영국으로 가는 것은 예정에 있었으나 이 성과로 많이 앞당기게 되었다)
물론 두 번째 사례에서는 운이 많이 따라주었다. 팀을 옮기는 과정에서 공부해두었던 스킬들이 적재적소에 쓰였을 뿐 아니라, 매니저의 기존의 방식이 새로운 비즈니스 요구를 따라가지 못했다. 매니저가 개인적인 집착 때문에 기존 시스템을 버리지 못한 것도 오히려 내게 좋은 기회로 작용했다. 그러나 핵심은 결국 설득에 있어 "보여주는 자"가 "말하는 자"를 압도한다는 것이다.
만약 이 글을 읽는 분께서 말주변이 없다거나, 직급에서 밀리거나, 다른 이유로 사람들을 설득하는데 어려움을 겪고 있다면, 말이나 글로 설득하는 것을 중단하고 조용히 결과물로 보여주자. 놀라울 정도로 다른 반응을 보게 될 것이다.
자, 정리해보자.
백문이불여일견:
경영진들은 '합리성'보다는 '결과'에 관심을 가진다.
MVP를 만들어라.
관련 스킬을 익혀라. MVP를 만드는 데까지 들어가는 스킬은 그리 어렵지 않다.
"보여주는 자"가 "말하는 자"를 압도한다.