스타트업 3년차 개발자가 생각한 팀을 신나게하는 리더(PM)의 특징 - 2부

같은 주제로 작성한 1부글에는 명확한 문제 인식과 태도에 관련된 이야기가 있습니다.

스타트업 3년차 개발자가 생각한 팀을 신나게하는 리더(PM)의 특징 - 1부

 

프로덕트에 참여하는 "느낌"을 준다

해결 방법을 기획하는 것이 PM의 일이다. 그렇지만 PM 혼자서 다 기획해버리면 팀을 신나게 할 수 없다. 무슨말일까?

자신이 공을 들여 고민한 문제일수록 해결했을 때의 기쁨도 커진다. 그래서 메이커를 신나게 하려면 문제를 주고 시간을 줘야한다. 던져진 문제를 고민하면서 본인의 문제가 되도록 메이커를 숙성시켜야 한다. PM이 모든 문제를 혼자서 해결해서 "이렇게 만들어만 주세요~" 라고 하면 팀은 힘이 빠진다. 메이커는 적당히 고민을 하게 해줘야 신나게 일을 한다. 

 

기획의 일부를 맡기라는건 아니다. 전반적인 기획은 PM이 하는 것이다. 기획하는데 문제가 있으니 도와달라고 해야 한다는 것이다. 개발자의 머리로, 디자이너의 눈으로 PM이 마주한 문제를 같이 고민하게 하면 된다. 당장 만족할만한 답이 나오지 않아도 상관없다. 중요한 것은 "느낌"이니까. 문제를 같이 고민하면서 프로덕트를 같이 만들어 간다는 느낌을 느끼게하면 충분하다.

 

메이커에게 데이터를  전달한다

위임을 통한 성장과 관련된 이야기이다. 구성원이 성장하려면 구성원의 의지가 담긴 결과물이 있어야하고, 그 결과물로 피드백을 받을 수 있어야한다. 구성원의 의지가 담긴 결과물이란 것은, PM이 준 문제를 오로지 자신이 고민한대로 구현해낸 결과물이다. 예를 들어, PM이 보기에 디자이너의 디자인이 구리게 "느껴질" 수 있다. 그렇게 느껴져서 피드백을 하는건 실무자에게 별 도움이 안된다. 아무 근거도 없는 PM 개인의 "느낌"일 뿐이다. 심지어 맞는말이라고 하더라도 그런 피드백이 많아질수록 디자이너의 생각이 담긴 결과물은 없고 PM이 시킨대로 만든 결과물만 남게될 것이다. 

그림1. 서비스와 관련된 데이터

PM이 원하는 목적을 정확히 설명했고, 디자이너가 그 목적에 맞는 디자인을 구현했다고 설명할 수 있다면, 실제로 그 디자인이 그 목적을 수행하는지는 데이터로 확인하면 된다. 최대한 많은 사람이 송금을 하는 것이 프로덕트의 목적이었다면, 몇명이 그 화면에서 송금을 했는지 공유하면 그게 올바른 피드백이다. 결과가 좋든 나쁘든 데이터를 통해 디자이너는 경험을 완성시킨다. "송금 유도를 위해 디자인 해봤습니다" 가 아니라 "송금 유도를 위해 이런 디자인을 했더니 X% 만큼 개선이 되었습니다"라는 문장을 쓸 수 있게 된다. 그 반대의 결과가 나왔다면 디자이너 스스로 학습하고 다시 도전할 것이다. 이것이 PM으로서 메이커의 전문영역을 올바르게 존중해주는 방법이다. 실행을 통해 배우는게 있다면 메이커는 신나게 일할 수 있을 것이다. (사실 잘하는 메이커들은 알아서 데이터를 챙겨보더라.)

 

전략, 로드맵을 제시한다

나는 개발자로 일할 때 항상 상황이 바뀔 수 있다는 생각을 했다.

"한 사람이 한 번밖에 구매하지 못하는 상품이 앞으로는 여러번 살 수 있게 될까?"

"지금 1:1로 하는 코칭이 2:1, 3:1로 변할 수도 있을까? 그렇다면 그런 시기는 언제일까?"

뭔가 바뀔 가능성이 있는지, 그 시기가 언제인지에 따라 나의 코드 설계도 바뀐다. 물론 따로 누가 말해주지 않아도 변할거라고 알 수 있는 부분도 있다. 하지만 말해주지 않으면 개발자 마음대로 짐작할 수 없는 부분도 있다. 이럴 때 전략이 있다면 설계가 훨씬 쉬워진다.

그림2. 전략을 설명하는 리더

전략이 무엇일까? 전략을 얘기하기 위해서 먼저 필요한 것은 이상향이다. 실제로 우리 팀의 상황을 각색하여 만들어 보았다. 먼저 이상향이 "대면 코칭을 통한 업무능력의 향상" 정도라고 하자. 조금 더 구체적으로 아래에 작성해보면,

• 우리 팀은 대면한다는 것이 코칭의 본질이라고 생각한다.
• 업무 능력이란 코칭 이전과 이후에 수치를 통해 나타나야한다.
• 우리 팀은 업무 능력 향상에 가장 강하며, 이 분야에 집중한다.

이상향을 저렇게 크게 작성했다면, 전략은 저 모습에 다가가기 위해 할 수 있는 선택으로 구성된다.

1. 먼저 부하직원과 소통에 문제가 있다고 생각하는 중간관리자의 문제에 집중한다. 
2. 우리가 더 많은 가치를 전달하는 타겟을 찾을 때까지 3~4 집단 정도의 문제를 시도해본다.
3. 가장 강한 가치를 느끼는 타겟의 문제에 다대일 코칭, 혹은 코칭보조 앱 등의 시도로 더 많은 가치를 줄 수 있는지 시도한다.
4. 3에서 느낀 노하우로 타겟을 넓혀간다.

이런 전략이 있다면, 팀원은 "사람이 없는 코칭을 할 가능성은 없겠구나.", "앞으로 우리가 할만한 다른 타겟을 미리 찾아보면 도움이 되겠구나.", "타겟의 업무능력을 수치화 할 수 있는 방법을 생각해야겠구나" 정도로 미래를 그리며 준비를 하게된다.

 

전략을 설정함에따라, 위 주제에서 얘기했던대로 팀원에게 고민거리를 던져주게된다. 팀원은 어떻게 이상향으로 가는 데 기여할 수 있는지 고민할 수 있게 된다. 방향을 먼저 일치시켜 놓았으니 자신의 노력이 헛수고가 될 확률도 적어진다. 제시된 전략과 이상향을 고민할수록 자신의 문제가되고, 회사가 성장하면서 곧 나의 문제가 해결되는 짜릿한 경험을 하게될 것이다.

 

덧붙임

https://www.youtube.com/watch?v=WVvFRh1vGv8

위 영상은 배달의 민족을 서비스하는 우아한형제들에서 기술이사를 하셨던 김영한님의 영상이다. 이번 글과 비슷한 주제의 영상이라 가져왔는데, 참 재밌게 말씀하시면서도 정곡을 찌른다. 개발자를 움직이는 마법의 단어가 나오니 개발자와 협업하는 사람이라면 꼭 보시길.