본문 바로가기
> 레벨업의 테크노트

[2편] 개발 7년차에서 매니저 3년차로(개발팀 7명에서 33명이 되기까지)

by 김병규 2021. 11. 8.

들어가면서

  [1편]에서 매니저로서 피해야 할 길(절망 편)에 대해서 이야기했다. 2편에서는 반대로 마주하고 나아가야 할 길(희망 편)에 대해서 말해보려 한다. 초보 매니저에게 도움이 되는 글이 되었으면 좋겠다.

마주하고 나아가야 할 길

작은 목소리에 귀 기울이기

  매니저가 된 이후 가장 어려웠던 부분은 구성원의 기분과 컨디션을 파악하는 일이었다. 팀원들에게 나의 의견을 강하게 전달하거나 회의에서 구성원과 반대되는 목소리를 내고 난 후에는 하루 종일 회의가 떠오르고 신경 쓰여 편히 쉴 수가 없었다. 구성원의 사기가 꺾이거나 실망하진 않았을지, 더 부드럽게 전달할 수 있는 방법은 없었는지 고민이 고민을 낳아 잠을 이루기 어려운 적도 많았다.(소심함이 문제였을지도...) 매니저로서 의사결정에 확신이 있었더라면 고민이 덜 했을지도 모르겠다. 하지만 나는 주니어 매니저였고 확신에 찬 결정을 할 수 있는 인사이트가 부족했다.
  이렇게 잠 못 드는 상황을 피하기 위해 구성원들에게 늘 반대 의견을 내어주길 요청했지만 사실 구성원들이 강한 목소리를 내는 것은 매니저인 나보다 더욱 어려움이 따르는 일이었다. 그래서 나는 구성원에게 강한 목소리를 내어주는 것을 요구하는 것에 앞서 그들이 내어주고 있는 작은 목소리를 듣는 것에 집중했다. 주니어, 그리고 비전공자로서 가지는 고민, 회사 복지 체계에 대한 개선 의견, 장비나 의자와 같은 소모품에 대한 불편함 등 흘러가듯 오가는 말들에 집중하여 피드백을 드렸다. 모든 요청에 대하여 대하여 해결책을 드릴 수는 없었지만, 작은 목소리에도 확실한 피드백을 드리는 것을 통해 구성원들의 의견 표현이 조금씩 늘어갔다. 작지만 분명한 피드백을 통해 활발한 의사소통을 이어간다면 프로덕트에 집중된 다양하고 강한 목소리도 편하게 낼 수 있지 않을까? 작은 목소리에 귀 기울이는것을 시작으로 구성원의 목소리에 집중하여 잠 못 드는 밤(서로의 상심을 걱정때문에)을 줄여가고 있다.   

 

동종 업계의 연봉 시세 확인하기

  스타트업처럼 작은 회사는 HR을 위한 전문 부서를 꾸리기 어려울 때가 많다. HR부서가 없는 작은 조직의 경우 연봉협상을 위해 사내 연봉 테이블과 업무성과 평가표에 절대적으로 의존하기보다, 1차 조직장의 리뷰와 회사와 프로덕트의 성과를 바탕으로 연봉협상을 진행하는 경우가 많다. 우리 팀은 여기에 서라운드 리뷰라는 팀 평가기준을 더했지만 정량적인 기준이 되기엔 부족한 면이 있었다. 이런 상황에서 프로덕트의 성장을 위해 함께 달려온 동료와 돈 이야기를 나누고 연봉을 결정해야 하는 것은 초보 매니저에게 여간 어려운 일이 아니었다. (당장 나의 연봉 협상 자리도 어려운걸...)

  더군다나 코로나 이슈로 인해 IT인력시장은 뜨겁게 달궈져 있었고 하루가 멀다 하고 "OO기업 신입 연봉 6천만원!", "이직 시 사이닝 보너스 1억 제공!" 등 자극적인 채용가 홍보 쏟아지며 연봉협상의 난이도를 더욱 높였다. 

  이런 상황에서 구성원의 이탈을 막고, 동기를 부여하면서도 회사까지 수용할 수 있는!! 회사와 구성원 사이에서 최대한의 협상 만족점을 찾아내야 한다는 고민에 빠졌다. 나는 그 고민을 업계 시세에 기반하여 연봉을 협상하는 방법으로 덜어 낼 수 있었다. 헤드헌터로부터 우리 팀원이 제의받은 금액, 초봉 6천이라는 기업의 인재 요구 수준, 이직한 동료가 받는 연봉과 해당 회사의 연봉 밴드, 전 직장 동료들의 재계약 연봉 등 최대한 많은 곳에서 업계 싯가?를 모았고 이를 토대로 구성원과 회사 사이에서 합의점을 찾을 수 있었다. 어렵게 모은 업계 시세정보는 나와 구성원, 그리고 회사에게도 계약 연봉을 가늠할 수 있는 좋은 척도가 되었고 연봉 협상을 조금이나마 가볍게 시작할 수 있는 출발점으로 활용할 수 있었다.

 

강약약약으로 처세하기 (강자에게 약하고, 약자에게도 약하게)

  회사의 정치적 구조를 생각하지 않고 프로덕트에 몰입할 수 있는 것은 스타트업이 가진 큰 매력점이다. 지나친 정치에서 벗어나기 위해 대기업에서 스타트업으로 이직하는 경우도 많다. 하지만 사람이 셋만 모이면 정치가 시작된다고 하지 않던가. 정도의 차이는 있겠지만, 성장하는 회사라면 구성원 간의 관계 복잡도 또한 올라가기 마련이다. 특히 매니저라는 직책은 협의를 통해 결과물을 만들어내는 것이 주요 업무이고, 정치적 구조안에서 풀어 가야 하는 일이 많기 때문에 매니저로서 협업을 위한 중심을 잡는 것이 중요하다.

  나는 그 중심을 '정정당당함'에서 찾으려 했다. '강자에게는 강하고 약자에게는 귀를 귀울이는 것'을 정정당당한 것으로 생각했고 이에 맞춰 회사에서도 강강약약의 자세로 협업을 진행했다. 특히 강강에 집중했던 나는 상위 결정권자의 의견을 더욱 엄격한 기준으로 판단했고, 팀원들에게 부끄럽지 않은 결정을 해야 한다는 생각에 몰입했다. 하지만 '정정당당'함을 지키기 위한 노력이 협업에 도움이 되거나 프로덕트의 성장에 긍정적인 영향을 미쳤을까? 아니다. 매니저로서 2년이 지난 지금 돌이켜 보면, 나의 강강약약은 프로덕트와 팀원보다 나의 자존심을 더 잘 지켜내는 방법이었다.

  회사는 수익을 내기 위해 협업을 하는 곳이다. 강자에게 강하게 대응한다고 해서 우리의 프로덕트가 눈에 띄게 성장하거나, 우리 팀이 더 편해지지 않는다. 팀과 프로덕트의 성장을 위해서는 강자에게도 약하고 약자에게도 약한 자세를 취해서 최대한 많은 의견을 끌어내고 수렴해서, 발화자의 직책 높낮이에 상관없이 프로덕트만을 위한 결정을 해야 한다. 나보다 직책이 높은 사람의 의견을 따른다고 해서 아부하는 게 아니며, 직책이 낮은 사람의 의견을 반대한다고 해서 군림하는 것이 아님을 늦게 알게 되었다. (정말 집중하고 잘 보이기 위해 노력해야 하는 곳은 유저와 프로덕트였던 것을....) 그때부터 강약약약으로 대응하려 노력하고 있으나 잘 하고있는지 판단하기 위해서는 좀 더 시간이 필요할 것 같다.

 

개밥 먹기

  개밥 먹기란 우리가 개발하고 있는 프로덕트를 일상적인 생활과 업무에서 사용해보는 것을 뜻하는 IT업계 용어다. 이스포츠 플랫폼을 개발하는 우리 팀의 경우 사내 게임대회를 레벨업지지에서 개최해 본다거나, 유저가 만든 대회에 직접 참가하는 것이 개밥을 먹는 것이다.

  매니저에게 개밥 먹기는 우리가 만들고 있는 것이 무엇인지 제작자의 관점에서 한발 벗어나서 객관적으로 볼 수 있는 좋은 도구이다. 여러 곳에서 쏟아지는 아이디어를 정리하며, 기능을 구현하고 더하는 것에만 집중하다 보면 우리가 만들고 있는 것이 무엇인지 놓칠 때가 있다. 그럴 때면 개밥 먹기를 통해 우리 프로덕트의 현황을 파악하고 해결해야 할 문제점들을 파악할 수 있다.

  그리고 개밥 먹기는 애자일 형태로 개발을 진행하는 조직에게 필수사항으로 업무시간을 들여서라도 진행 하는 것을 추천한다. 무엇을 만들 것인지, 어떻게 만들 것인지, 이번 변경사항이 얼마나 의미있었는지, 어디를 개선해야 할지 등 애자일의 과정 과정마다 좋은 아이디어를 낼 수 있는 원동력을 프로덕트에 대한 이해도로부터 얻을 수 있기 때문이다. 기획자와 디자이너는 물론 개발자와 운영자까지 유저로서 프로덕트를 이해한다면 각자의 파트에서 더욱 의미 있는 역할을 해낼 수 있을 것이라 믿는다. 

 

투명한 정보 공유

  매니저 업무를 시작하면서 관리해야 하는 정보의 양이 기존보다 두배 이상 증가했다. 실무자일 때보다 더 많은 회의에 참석했고, 더 많은 의사 결정에 참여함으로써 운영진과 타 부서의 정보도 챙겨야 했다. 매니저로서 얻는 정보를 어디까지 구성원에게 공유해야 할까?라는 물음표가 생겼고, 잦은 결정 변경으로 인한 피로감, 무뎌짐, 실패의식을 느꼈던 과거 실무자로서의 경험을 바탕으로 '확정된 것만 공유하자'라는 판단을 했었다. 

  하지만 대표님은 반대로 대부분의 정보(심지어 투자 현황까지)를 전 직원에 공유했고, 나의 우려와는 반대로, 정보를 받아들이는 주체였던 구성원들은 성숙하게 정보를 소화해내고 있었다. 빅픽처의 동료들은 나보다 훨씬 더 강하고 성숙한 사람들이었고, 모든 정보를 투명하게 공유하였을 때 실망하거나 걱정하기에 앞서 그들의 사유를 바탕으로 판단하고 있었다. 정보의 제한을 통해 피할 수 있었던 실망과 아쉬움을 감내해야하는 경우도 있었지만, 투명한 정보 공유로부터 오는 고통은 정보를 차단하고 필터링 하는 것으로부터 오는 부작용보다 건강하고 성장의 바탕이 되는 성장통이었다. 앞선 경험을 통해 나 역시 확정된 정보만 공유하는 것에서 모든 정보를 투명하게 공유하는 것으로 자세를 바꾸었다. 정보를 투명하게 공유함으로써 쌓이는 신뢰도는 우리를 더 단단하게 만들어 주었고 정보 공유를 더 편하게 할 수 있는 선순환구조가 자연스럽게 생겨나 매니저로서 정보를 관리해야 하는 어려움을 줄일 수 있었다.

마치면서

  [1편]은 하면 안 되는 것들에 대하여 적다 보니 편하게 쓸 수 있었나보다. 이번 편은 해야 하는 것들에 대해 적다 보니 소심함과 조심스러움이 더해져 문장들마다 쉼표가 늘어났다. 이제 막 3년 차에 접어드는 초보 매니저의 글로써 나와 비슷한 길에 올라선 분들께 조금이나마 도움이 되는 글이길 바란다. 다음 회고 때는 조금 더 자신감을 뿜뿜할 수 있기를....! 


김병규

새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.  

댓글