Product manager와 Product owner (3편)

* 이 글은 ‘Product owner, Product manager’의 세 번째 글로 아래의 두 글을 먼저 읽는 게 좋습니다.

Product owner? Product manager?

Product manager와 Product owner (2)

위 두 글을 짧게 요약하자면, 첫번째 글에서는 PO(Product Owner)와 PM(Product Manager)이 거의 동일한 일을 한다고 주장했으나, 두번째 글에서는 Tomtom과 같은 회사의 예에서 볼 수 있듯이 PM과 PO이 서로 다른 역할로 함께 일하는 케이스도 있다고 했다. 이번 3편(아마 마지막 편이 될 것 같아요)에서는 최근에 여러 회사와 인터뷰를 하면서 발견한 또 다른 조직 구조들을 포함하여 정리해 보겠다.

쉽게 그림으로 정리하자면 (내가 알고 있는 케이스들은) 아래와 같이 나눌 수 있다.

  • 1번 : 제 첫번째 글의 케이스. 회사는 PO 혹은 PM 직무 중 하나만 운영한다. 제가 일하는 Booking.com이나 예전에 있던 쿠팡이 이런 케이스였다. (참고로 Booking.com은 원래 Product owner로 운영하다가 약 2년 전에 모든 PO를 PM으로 바꾸었다. Role의 변화없이 정말 이름만 바꾸었다)
  • 2번 : 제 두번째 글의 케이스. 회사는 PO와 PM 둘 다 운영하며 두 직무의 책임과 역할의 범위는 다르다. 내가 직접 확인한 케이스는 Tomtom이라는 글로벌 Navigation & map 업체.
  • 3번 : 이번에 새로 발견한 케이스. PO가 PM에게 보고를 하는 구조이다. 두번째 글에서 확인할 수 있듯이 PM은 좀 더 멀리 바라보는 직무로, 제가 좋아하는 문구 “Build the right product to the right customer”에서 ‘right product’와 ‘right customer’ 부분에 포커스(어떤 고객군에게 어떤 제품을 제공해야 하는지)를 하는 직무라면, PO는 그 비전을 feature set으로 breakdown 해서 제품팀(개발자, 디자이너 등)과 함께 최대한 빨리 결함없는 right product을 ‘build’하는 쪽에 포커스를 한다고 볼 수 있다. 그러기에 어떤 회사에서는 자연스럽게 PM이 PO를 매니징하게 되는 경우가 생긴다. IKEA와 PVH(Calvin Klein, Tommy Hilfiger 등 패션 브랜드 회사)의 IT 조직에서 확인할 수 있었다. IKEA의 경우 PO —> Sr. PO —> PM 과 같이 직급이 올라가는 구조로 Product Manager가 실제 Group Product Manager(여러 명의 PM을 관리하는 직책)이나 Director급의 직급이었다.

이번 편이 Product Owner? Product Manager? 편의 마지막이라 한 이유는, 이제 굳이 이걸 구분하는 게 의미가 있을까? 라는 생각이 들어서이다. 올해 하반기에 10개 회사와 최소한 한 차례 통화나 인터뷰를 했었고 이를 통해 확인한 것은 ‘각 회사마다 해당 직무(PO, PM)에 대한 정의와 기대는 다 다르다’라는 것이다. 회사가 순수한 인터넷 기반의 비즈니스를 하는지, 조직의 IT에 대한 이해도와 활용도가 어느 수준인지, 작은 스타트업인지 이미 조직이 많이 커진 기업인지 등 각자의 상황에 따라 해당 직무에 대한 기대는 다 다르다.

이에 두번째 글의 말미에도 언급했지만 이직을 위해 Job apply를 할 때 Job description을 상세히 읽어보고, 조직의 크기, 구조, 책임의 범위 등에 대해 리쿠르터와 꼭 먼저 확인을 하자. 그래서 회사가 본인에게 기대하는 게 어느 정도 수준인지 파악할 수 있고, 이를 토대로 내가 할 수 있는 일인지, 내 경력상 도움이 될 경험인지 등을 판단할 수 있을 것이다. 나의 경우 리쿠르터와 통화를 할 때 아래의 질문들을 꼭 하는 편이다.

  • 현재 조직이 어떤 상황인가? 해당 Job을 Posting한 이유는 뭔가?
  • PM(PO)의 숫자 그리고 전체 개발팀의 크기는 어느 정도이며, 나는 누구에게 보고 하고, 전체 조직 구조는 대략 어떻게 되는가?
  • (첫번째 질문과 유사하지만) 나에게 거는 기대는 무엇인가?
  • 조직에서의 성장에 대한 기회는 어느 정도인가? 회사에서 이 조직에 거는 기대는 무엇이며 앞으로 어떤 성장/확장 계획을 갖고 있는가?

짧지만 하고 싶었던 말을 (오랜만에) 포스팅한다. 독자들의 삶에 크게 도움이 될 진 모르겠지만 최소한 ‘알아두면 좋을’ 정보라 생각해서 글을 적고 싶었다. 본 Product Owner? Product Manager? 편의 글들 중 1번과 2번 글은 ‘PO나 PM이 무슨 일을 하는지’에 대한 이해를 돕기 위한 글로 활용했으면 좋겠고, 이번 마지막 글은 ‘그냥 이런 게 있구나’ 정도의 정보성 글로 (독자분들이) 받아들였으면 좋겠다.

RICE – 일에 우선순위를 매기는 방법

퍼블리 뉴스에 큐레이션해서 올린 글입니다.

원문 : RICE, simple prioritization for product managers


<RICE – Simple prioritization for PMs>

Product Manager의 중요한 역할 중 하나가 바로 어떤 프로젝트나 태스크의 우선순위를 결정하는 일이라 볼 수 있습니다. 이게 쉬운 일은 아니죠. 같은 프로젝트라도 상황에 따라(예, 코로나 전/후), 회사의 전략 방향에 따라, 조직의 목표에 따라, 주요 고객이 누구냐에 따라, 개발팀의 리소스나 디펜던시(다른 팀과 일이 엮여있는 정도) 등에 따라 그 중요성이 달라질 수 있습니다.

그렇기에 ‘이것만 따르면 돼’라고 할 수 있는 방법은 없습니다만 그래도 일반적으로 사용될 수 있는 프레임워크가 여러 가지 있습니다. 이번에 소개할 글은 그 중 RICE framework에 대한 설명입니다. 우선순위를 매기는데 있어 중요한 4개의 단어의 앞글자를 따서 RICE라고 이름 붙였으며 각 단어의 의미는 아래와 같습니다.

  • Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지
  • Impact : 그 임팩트의 크기는 어떠할지
  • Effort : 이를 수행하는데 있어 드는 노력이 얼마나 클지 (시간, 인력)
  • Confidence : 내가 측정한 위 R, I, E의 값에 얼마나 자신이 있는지(예, 구체적인 증거가 있다면 자신감이 높음)

그리고 최종적으로 RICE 점수는 = R * I * C / E 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이라고 보는 거죠.

사실 모든 일을 이렇게 계산할 수 있다면 좋겠지만 각자의 상황에 따라 이런 프레임워크가 유용할 수도 있고 아닐 수도 있습니다. 저의 경우는 우선순위를 계산할 때 위와 같이 점수를 매기는 방식을 활용하는 경우도 있지만 아닌 경우가 더 많습니다. 여러분들도 일단 이와 같이 우선순위를 계산할 수 있는 프레임워크가 있다는 것만 알아두고 본인의 상황에 맞게 적절히 활용하셨으면 좋겠습니다.

  • 저의 경우는 위의 값과 데이터를 쭉 늘어놓고 디펜던시, 리소스 상황, 현재 회사의 방향, 앞으로 몇 개월 동안 예상할 수 있는 장애물/난관 등 여러가지를 고려해서 우선순위를 결정합니다. 그리고 이렇게 결정한 로직을 제 매니저 그리고 제 개발팀, 디자이너, 마케팅 담당자에게 잘 설명하여 이해를 얻어내려 합니다. (물론 더 복잡한 경우도 많지만 지면상 생략합니다)

Product manager에서 Product leader로 성장하기 위한 길 (Publy News 큐레이션 글)

지난 6월 중순부터 Publy News 라는 서비스에 주 2~3회 씩 짧은 기사를 큐레이션해서 올리기 시작했다. Google Play에서 퍼블리 뉴스를 검색 후 다운받으면 무료로 사용할 수 있는 앱으로 각 분야에서 일하는 전문가들이 각자 관심분야의 글을 큐레이션하여 올려줍니다. 제가 올리는 글/기사 중에서도 제 블로그의 성격과 맞다고 생각하는 글들을 이곳에도 올리려고 합니다.


원문 : Crossing the Canyon: Product Manager to Product Leader

<Product manager에서 Product leader로 성장하기 위한 팁>

제가 다니는 Booking.com이나 본 사례에 나오는 회사들(Airbnb, LinkedIn, Dropbox, Uber, Amazon)은 Product 조직의 규모가 크죠. 이에 Product manager들도 PM —> SPM(Senior PM) —> GPM(Group PM) —> Product director 등 직급 체계가 짜여져 있습니다.

본 글에서는 PM/SPM와 같은 실무자급에서 GPM(보통 3~5명의 PM을 매니징하는 단계라고 보시면 됩니다)과 같은 관리자/Producer leader로 성장하기 위해선 기존의 능력과는 성격이 다른 능력을 길러야 한다고 합니다. PM에서 PL(Product Leader)로 성장하기 위해서는 아래와 같은 능력의 transition이 필요합니다.

(왼쪽 : PM/SPM에게 필요한 능력 —> Product leader에게 필요한 능력)

  • Depth in one type of product work → Breadth across multiple types of product work
  • Being good at your job → training others to be good at theirs
  • Solving with the resources you have → Solving by allocating resources and influencing others
  • Gaining more personal scope → Creating more scope for the organization

단순히 SPM 에서 GPM으로 승진하기 위한 팁은 아닙니다. Product manager에서 leader로 성장하기 위한 조언이라 생각하고 한 번쯤 읽어보시길 권합니다.

Product manager와 Product owner (2편)

내 블로그의 첫 글 <그래서 Product owner는 뭐하는 사람이에요?>이 브런치에서만 조회수가 6천이 넘었다. 그리고  <Product owner? Product manager?>라는 글도 꾸준히 읽히고 있다. 한국에서 Product owner에 대한 관심이 높아지고 있긴 한가보다.

<Product owner? Product manager?>의 주요 내용 중 하나는 Product manager(이하 PM)과 Product owner(이하 PO)는 하는 일이 기본적으로 같다는 것이다. 하지만 어느 날 독자 분이 브런치 댓글을 아래와 같이 남겨주었다. 엄밀히 말하면 완전히 같은 건 아니라고 한다. 이론적으로 말이다.

<내 글에 달린 댓글 중 발췌. 참고로 SAFe는 Scaled Agile Framework로 나도 자세한 내용은 모른다. 공식 웹사이트 검색해보시길>

다시 한 번 말하지만 실제 내가 다녔던 회사(쿠팡, Booking.com)나, 면접 봤던 회사들이나, 지인들이 일하는 회사 등에서 PM과 PO가 따로 구분되어 있는 경우는 본 적이 없었다. 대부분 PM or PO 였고 그 둘이 하는 일은비슷했다.

하지만 최근에 내 주위의 한 회사에서 PO와 PM이 함께 있는 사례를 발견했다. 바로 암스테르담에 본사를 두고 있는 Tomtom이라는 디지털 지도 관련 회사(tomtom.com)이다. 나름 유명한 네덜란드의 IT 회사로 이 분야에선 유명한 회사다. 위의 사실을 알게 된 계기는 아래와 같다.

이 회사의 Senior PO 직무가 Linkedin이 떴었고, 제품이 재밌어 보여서 내 주위의 Tomtom 출신 동료에게 회사는 어떤지, 그 팀은 어떤지 그리고 PO라는 직무가 어떤 권한을 갖고 있는지 물어볼 기회가 있었다. 그때 이 친구가 이렇게 얘기했다.

  • 동료 : “Tomtom은 PM과 PO가 나뉘어져 있어. 난 Tomtom 외엔 IT 회사 경험이 없어서 모든 회사가 그런 줄 알았어. 그래서 오히려 Booking.com에 처음 왔을 때 Product owner가 하는 일의 범위가 넓어서 놀랐어.(이 당시 우리 회사에서는 Product owner로 부르고 있었고, 2019년부터 Product manager라고 이름이 공식적으로 바뀌었다. 나는 당시 Product owner였고 지금은 Product manager가 공식 직무이다) Tomtom에서는 PM은 고객과 만나고 데이터 분석을 하고 장기 계획과 로드맵을 짜는 일을 주로 했고, PO는 개발팀(제품팀)이 효과적으로 일할 수 있도록 일의 우선순위를 결정하고 개발 요구사항을 명확히 하고 백로그를 관리하는 일을 주로 했었거든. Booking.com의 PO는 그 둘을 다 하고 있잖아.”
  • 나 : “어? 나는 모든 회사의 PO나 PM이 이름만 다르고 똑같은 일을 하는 줄 알았어. 내 경험상 그랬고 주위에서도 Tomtom과 같은 사례는 들어본 적이 없었으니까.”
  • 동료 : “어, 그래서, 내가 아는 너는 Tomtom 기준에서의 PM일은 즐겨할 것 같은데, PO일은 안 맞을 수도 있을 것 같아. 그래서 얘기해주는 거야. 한 번 그쪽과 확인해봐.”

위의 대화를 통해 얻은 인사이트를 확인하기 위해 온라인상으로만 알고 있던(LinkedIn connection) Tomtom의 PM에게 직접 물어봤다.

  • 나 : “I heard from ex-TomTom employee that there is also a Product Manager role in TomTom who’s mostly in change of the vision/roadmap/user research and so on, while POs are mostly in charge executing the roadmap in agile method. If so, I am not interested in PO role. I wanted to clarify this and I thought about you.”
  • 그녀의 대답은 ‘그렇다’ 였다.

그렇다. 내 글에 댓글 달아주신 분 덕분에 알게된 사실을 실제 내 주위에서 사례로 검증을 했다.

더 궁금해져서 이것 저것 자료를 찾아보다가 아래와 같은 Atlassian의 동영상을 찾게 되었다. 참고로 Atlassian은 개발 협업 툴 Jira와 Trello(인수함)로 유명한 호주의 소프트웨어 업체이다.

위 동영상의 2:40 정도를 보면 PM과 PO에 대해 설명하는 부분이 나온다. 요약하자면 아래와 같이 역할과 책임을 구분한다.  (위 동영상과 같은 내용으로 Atlassian blog 글도 있다)

  • Product manager : Mission, vision, high level problems, what success looks like
  • Product owner : break down and translate the vision to day-to-day activities

즉, PM은 장기적이고 큰 그림을 그리고 비즈니스 목표를 정의하는 직무이며, PO는 그 큰 그림을 실제 디자이너와 개발자들이 구현할 수 있도록 작은 태스크로 나누고, 요구사항을 명확히 정의하며, 태스크의 우선순위를 정하여 제품팀이 최대한 효과적이고 효율적으로 일할 수 있게 이끄는 직무이다.

이 글에선 위와 같이 PM과 PO를 구분하는 사례가 있다는 것을 보여주고 싶었다. 조금 부끄럽기도 하다. 몇 천명이 읽은 내 예전 글에서는 PM과 PO가 하는 일이 거의 동일하다고 했기 때문이다. 하지만 여전히 누군가 내게 PM과 PO가 뭐가 달라요? 라고 물어보면 ‘대부분의 회사에선 비슷하다. 그러나 회사마다 역할과 책임을 다르게 정의하기 때문에 정답은 없다‘ 라고 대답할 것이다. 물론 ‘일부 회사에선 그 둘을 나누기는 한다’라는 것을 덧붙이며 말이다.

이런 리서치와 검증 과정을 거치면서 내가 배운 점은 딱 하나다. 독자분들께도 이 한 마디 마지막으로 하고 싶다. 모든 회사마다 PM과 PO의 역할과 책임의 범위가 다 다르다. 그러니 이직할 때, 입사 지원할 때 그 자리가 어떤 자리인지, 회사에서(위에서)는 어떤 기대를 하는 자리인지, 개발팀과는 어떻게 일하는지, 의사결정의 권한은 얼마나 있는지 등을 꼼꼼히 확인하고 지원하라는 것이다. 인터넷 검색으로 잘 모르겠으면 면접 과정에서 리쿠트링 담당자나 면접관에서 물어보면 된다. 나도 면접할 때 면접관에게 늘 하는 질문이 “그 회사, 그 자리에서 내가 의사 결정할 수 있는 권한이 얼마나 있는가?”이다. 물론 어떤 조건이 좋을지는 사람마다 다르니 무엇이 좋다 나쁘다 라고 얘기할 순 없지만 말이다. 

소프트 스킬, 커뮤니케이션을 여는 열쇠

2019년 4월에 ‘일하는 사람들의 컨텐츠 플랫폼’ Publy의 파이낸셜 타임스 큐레이션 글로 발행한 글입니다. Publy에서 파이낸셜 타임스 큐레이션 서비스를 중단했기에, 제가 작성했던 본문(‘큐레이터의 말’)을 Publy 동의 하에 아래와 같이 공유합니다. 


지난 12년의 경력 중 이직을 두 번 경험했다. 경력에 비해 많은 편은 아니지만, 두 번 모두 환경의 변화가 굉장히 컸다. 첫번째는 삼성전자에서 8년간 일하다 쿠팡으로 다른 직무로 이직한 경우였고, 두번째는 멀리 네덜란드에 있는 Booking.com 본사로의 이직이었다. 두 번 모두 초기에는 빠르게 적응하기 위해 업계와 제품에 대해 공부하고, 업무에 필요한 스킬을 익히기 위해 밤낮으로 노력했다. 

처음에는 해당 직무를 일단 ‘수행하기 위한’ 하드 스킬 위주로 업무를 익혔다. 그러나 어느 순간부터 ‘더 잘하기 위해서’는 소프트 스킬이 필수적이라고 느꼈다. 

삼성전자에서 스마트폰 상품기획과 해외영업 업무를 하다가 쿠팡으로 옮겨서는 ‘제품관리자(당시 쿠팡에선 Product owner라고 불렀다)’라는 타이틀로 첫 업무를 시작했다. 처음에는 당장 업무에 필요한 지식과 프로세스를 위주로 공부했다. 애자일 개발 방법론, 데이터 분석(SQL), 웹 서비스가 기술적으로 어떻게 작동하는지 등을 익혔다. 

무엇보다 당장 팀이 돌아가야 했다. 문제를 해결하기 위해 데이터를 분석하고, 개발팀과 함께 해결방안을 구상하고, 실행의 우선순위를 결정하고, 실행(신규 기능 런칭 혹은 제품 개선)한 후 다시 데이터를 확인하는 싸이클을 멈추지 않고 팀을 운영하기 위해서는 그런 하드 스킬이 필요했다.

그러나 업무가 어느 정도 궤도에 오르고 나자 더 효율적으로 일하고 더 큰 임팩트를 내기 위해서는 커뮤니케이션이 굉장히 중요하다는 것을 깨달았다. 

제품관리자의 주요 역할 중 하나는 바로 관련부서(stakeholder)와의 업무 조율이다. 새로운 결제 서비스를 런칭하는 과정에서 나는 주문 관련 개발팀, 고객서비스 담당부서, 회계 및 자금 부서, 대외정책팀, 법무팀, 그리고 금융사 및 결제 관련 협력업체 같은 외부업체들과 지속적으로 커뮤니케이션하면서 서비스를 기획하고 런칭 마케팅 계획을 세웠다. 

각자 바쁘게 돌아가는 부서에 새로운 요구사항을 전달하고, 계획한 일정 내에 작업을 모두 끝마치고 서비스를 런칭하는 건 쉬운 일이 아니다. 새로운 서비스가 왜 필요한지, 누가, 어떤 부분을, 언제까지 해야 하는지 등을 관련 부서가 모두 ‘이해’할 수 있도록 내용을 문서화해서 공유하고, 직접 만나서 설명하고 설득하는 과정을 반복했다. 

특히 결제 서비스 런칭에는 보다 세심한 준비와 조율이 필요했다. 새로운 결제 서비스를 고객이 어떻게 사용할 수 있는지, 취소 및 환불 정책은 어떻게 되는지, 결제 및 취소 관련 내용은 (고객 및 상담원 각각의 입장에서) 어디에서 어떻게 확인할 수 있는지 등의 내용을 고객 상담원이 숙지하고 있어야 하기 때문이다. 이를 위해 본사 사무실과는 멀리 떨어져 있는 고객서비스 부서에 방문해 상담원들을 직접 교육했고, 질문과 답변을 통해 상담원의 궁금증을 해소해주기도 했다. 그 때까지만 해도 제품팀에서 직접 상담원 교육을 하는 일은 없었던 터라 고객서비스 부서에서 좋은 피드백을 받았고, 일정 내에 서비스 런칭을 하는데도 도움이 됐다. 

한국에서 10년 간 일한 후 네덜란드에서 일하게 된 것도 큰 변화였다.

유럽에서 제품관리자로 일하면서 처음에는 우리가 이걸 왜 하는지, 왜 이것부터 해야 하는지, 이걸 하면 뭐가 좋아질지 같은 질문에 계속 답하는 게 가장 힘들었다. 업무 속도는 한국이 훨씬 빠르지만, 이곳은 한국보다 ‘왜’에 더 집중한다. 데이터를 기반으로 명확한 가설을 내세우지 않으면 팀원들을 움직이게 하기 힘들다. 

사용성을 개선하는 경우처럼 통계 데이터로 증명하기 어려울 때도 종종 있는데 그럴 때는 조직 및 제품의 비전을 기반으로 그 당위성을 ‘스토리’로 풀어낼 필요도 있다. 동료들에게 우리가 가는 길과 하는 일에 대한 확신을 심어주기 위해서다. 

이런 커뮤니케이션을 더 잘 하기 위해 ‘내가 어떤 식으로 대화를 이끄는지’에 대해 동료들로부터 피드백을 받았고, 어떻게 하면 더 큰 임팩트를 낼 수 있을지 친한 동료들 및 매니저와 상의해보기도 했다. 그 덕분에 나름의 전략을 짜고 실행에 옮길 수 있었다.

예를 들어 잘 짜여진 스토리텔링이 필요한 미팅을 앞둔 경우, 에버노트 등에 내가 할 이야기를 미리 적어 논리의 타당성을 검토했다. 그런 다음 믿을만한 동료에게 피드백을 받아 메시지를 다듬고, 미팅에서 목소리가 큰 사람들과 사전 1:1 대화를 통해 핵심 메시지에 대한 피드백을 받았다. 

회사에서 제공한 ‘Art of Influence’라는 4일짜리 트레이닝도 어느 정도 도움이 됐다. 트레이닝을 통해 내 커뮤니케이션 타입을 파악했고, 상대방의 타입을 파악하는 방법을 배웠으며, 서로 다른 타입에 어떻게 대응해야 하는지를 익혔다. 이후 지금까지 실습을 계속하면서 성공과 실패를 경험했고, 나만의 방식을 찾아가고 있다.

글로벌 기업에서 일하면서 또 하나 느낀 점은 함께 일하는 동료들의 문화적 스펙트럼이 굉장히 넓다는 것이다. 

서로의 ‘다름’으로 인해 문제가 생길 때도 있다. 특히 네덜란드와 한국은 여러 면에서 반대편에 있다. 예를 들어 부정적인 피드백을 주는 경우 네덜란드인들은 직접적(direct)으로 얘기하는 반면, 한국인들은 돌려 말하는(indirect) 편이다. 또 한국에서는 상대방의 의견에 동의하지 않더라도 돌려서 말하거나 여러 사람 앞에서 강하게 부정하는 일은 피하는 편이지만(avoid confrontation), 네덜란드인들은 상대방이 나보다 몇 직급 높은 상사더라도 ‘동의하지 못하겠다’고 당당히 말하는(confrontational) 문화다. 

애초에 이런 부분을 미리 염두에 두고 커뮤니케이션을 했다면 서로에게 잘 맞춰갈 수 있었을 테고, 불필요한 오해도 피할 수 있을 것이다. 하지만 나는 이런 내용을 배운 적이 없었다. 동료들도 이런 부분은 잘 몰랐고, 생각해 본 적도 없는 경우가 많았다. 

나는 네덜란드인 동료의 직설적인 피드백을 감정적으로 받아들였고, 한 동안 스트레스를 많이 받았다. 그 때 한 동료가 추천해 준 The culture map이란 책을 읽고서야 상황을 바로 볼 수 있게 되었다. 일례로 미팅 도중 러시아인 동료가 무안할 만큼 나에게 강하게 반론을 제기하거나, 네덜란드인 동료가 1:1 대화 중 “인용, 너에게 실망했어”라고 대화를 시작했을 때 기분이 나빴던 일들이 떠올랐다. 그들이 나에게 나쁜 감정이 있는 게 아니라, 서로 커뮤니케이션 하는 방식이 ‘다른 것’ 이라는 걸 알게 됐다. 내가 ‘틀린 게 아니라는 것’을 깨닫고 나서, 스트레스가 많이 완화됐다. 

이런 일들을 겪으며 ‘누가 이런 것 좀 가르쳐 줬으면 좋았을텐데’ 하는 생각을 자연스레 하게 됐다. 

펜실베이니아 대학교(University of Pennsylvania) 와튼 스쿨(Wharton School)의 사울 P 스타인버그 경영학 교수(Saul P Steinberg Professor of Management)인 애덤 그랜트(Adam Grant)는 MBA 과정에서 소프트 스킬을 가르쳐야 한다고 주장한다. 그렇게 하지 않는 것은 “잘못된 생각이며 어쩌면 위험한 생각일 수도 있다”는 것이다. 그랜트 교수에 따르면 소프트 스킬이 “가치 있을 뿐 아니라 가르칠 수 있다”는 명백한 증거가 많이 있다. “우리는 가장 중요한 스킬을 가르칠 책임이 있습니다.” (파이낸셜 타임스 기사 중)

여러 경로를 통해 배운 커뮤니케이션의 핵심 중 하나는, 우선 내가 어떻게 커뮤니케이션을 하는지 아는 게 중요하다는 것이다. 우리는 스스로를 잘 알고 있다고 생각하지만, 커뮤니케이션은 나 혼자 하는 게 아니다. 상대방과 하는 것이다. 

동료들의 피드백을 통해 나를 알아보는 것도 좋다. 솔직하고 건설적인 피드백을 잘 주고 받는 것도 스킬이며, 이런 스킬들은 모두 ‘배울 수 있다’. 관심을 갖고 나를 지켜본다면 내가 무엇을 잘 하고, 무엇이 필요한 지 파악할 수 있다. 그런 다음 책에서 길을 찾을 수도 있고, 온/오프라인 트레이닝 등을 통해 이런 소프트 스킬들을 배울 수도 있다.

경험을 통해 성장하는 방법도 있지만 필요할 때 적절한 트레이닝을 받는 것도 성장을 위한 좋은 방법이다. 세계 유수의 경영대학원들도 현장에서 피드백을 받아 꾸준히 교과과정을 개선해 나간다. 그래야 ‘경쟁력 있는 졸업생’이라는 좋은 산출물을 낼 수 있기 때문이다. 우리 자신도 마찬가지다. 

이 수업은 LBS 경력개발센터의 피드백을 반영한 것이다. “채용 담당자들은 학생들이 자신을 너무 모른다고 이야기합니다.” 졸리 교수의 설명이다. “학생들이 거만하기만 하고 타인의 이야기를 경청하지 않는다는 것이죠.” 그는 학생들이 새로운 일자리를 찾는 것 그 이상을 이 수업이 도울 수 있기를 바란다. “높은 자리에 오를수록 관계의 중요성이 커집니다. 예를 들어 이사회에 들어가면 엑셀 작업을 하는 것이 아니라 관계를 쌓아 나가게 되죠.”