<div id="readability-page-1" class="page"><div>
팀장 발령은 올해 2월쯤 받았으니, 이제 120일? 갓 넘은 신생아다. 그 때는 제품개발하는 데에 올인한 상태여서 팀장이 무슨 일을 해야하는지 전혀 생각하지 못했다. 하지만 그 타이밍에 내가 팀장이라 해야되는 첫 번째 업무가 바로 '인사평가면담'이었다. 작년 인사평가에 대한 평가자는 아니었지만, 면담은 현팀장이 해야한다는 룰이 있었는데, '왜 면담 안해주지?' 라고 멍때리고 있다가 '아 내가 하는 거였어?' 하고 부랴부랴 면담일정을 잡았던 기억이 있다.
그리고나서 나의 평가를 받았는데, 정확한 워딩은 잘 기억나지 않지만 <code>과제의 추친과 팀원의 케어는 함께 하기 어렵다</code> 라는 내용에 크게 머리를 맞은 듯한 느낌을 받았었다. 일 못한다는 얘기는 안 들으려고 항상 최선을 다하고 있지만, 지금처럼 일하면 팀원케어는 안중에도 없을게 뻔했다. 팀장이 해야할 최우선 업무는&nbsp;<code>주어진 과제를 잘 성공시키는 것</code> 라고만 생각했지, <code>팀원의 케어</code> 라는 한 꼭지가 더 있음을 드디어 깨달은 것이다. 팀원이었던 나는 주로 알아서 일을 찾는 편이라 팀장의 케어가 잔소리로 느껴지거나 케어가 없어도 된다고 생각했었기 때문에 팀장의 주요역할이라고 생각하지 못했던 탓도 크다.
제품관리자로 수년을 일해오면서 적지 않은 개발자들과 스펙과 일정을 관리하고 중요한 의사결정을 할 때도 많아서 팀장도 하는 일이 크게 다르지 않다고 생각했다. 오히려 PO로 일하며 수십개의 회의를 다녔는데, 팀장은 그보다 더 중요한 회의가 많아 일 자체는 더 적게 하는거 아닌가 생각한 적도 있다. 그러면서도 일을 잘 시키는 것은 팀장의 일이고, 팀장이 시키는 것을 잘해야 팀원들이 좋은 성과를 낼 수 있다고 생각했다. 그런 생각으로 썼던 페북의 2년전 글이 발굴되어 덕분에 이 포스팅을 쓰게 된 셈이다.


<h4>팀장은 일을 잘시켜야 하는가?</h4>
<pre>일을 잘 시켜야 한다고 생각한다.</pre>
일단 이 문장에서는 2가지 키워드를 뽑아볼 수 있다. 일, 시키다. 팀장은 팀원에게 일을 시켜야 하는가. 팀원들은 팀장이 시키는 일만 해야하는가. 팀원들은 시키기 전에 일할 수 없는가.
팀장은 팀원들이 하는 일을 전부 알 수 없다. 개발자 팀장이 개발자 팀원을 관리한다고 하더라도, 팀원들의 코드레벨까지 팀장이 알 수 없다. 그렇기 때문에 무언가를 '시키다'는 행위는 제대로 동작할 수 없는 행위다. 반대로 팀원은 아니면 아니다, 되면 된다, 아니면 더 좋은 솔루션이 있다면 언제든지 먼저 제안할 수 있어야 한다. 팀매니저가 모든 것을 알고있지 않다는 것을 전제하고, 알게해주는 것이 팀원들의 역할이라고 할 수 있다.
팀원들은 시키기 전에 일할 수 없는가. 이 질문은 사람마다 다른 답을 할 것 같다. 당연히 먼저 할 수 있지만, 어떻게 하느냐는 함께 얘기해봐야 한다. 잠깐이면 처리하고 나올 수 있는 일인가, 아니면 앞으로의 퍼포먼스를 높이기 위해 내 일정을 무리해서라도 먼저 해두느냐, 아님 프로젝트 방향에 맞지도 않는데 추진해버리느냐 각각이 전부 다른 결과로 이어진다.
자기는 별 것이 아니라고 생각했던 작업이 다른 유관팀에 영향을 줄 수도 있고, 비즈니스 요구사항에 영향을 줄 수도 있기 때문에 발견한 백로그는 반드시 공론화 해야 한다고 생각한다. 이 일을 해야하는 이유와 배경에 대해서 팀장 혹은 다른 팀원들과 공유하고 전체 일정에 무리가 되지 않는 선에서 우선순위를 조정하하고, 합의에 의해 시작할 수 있는 타이밍을 잡으면 된다.
'실무에서 손 뗀 팀장이 팀원들과 일하는 법' 같은 깨달음을 얻게 된다면, 반드시 글을 써보리라.
<h4>팀장은 고민하지 않는가?</h4>
<pre>대부분의 사용자들(=고용자)들은 (피고용자를) 어떻게 사용해야되는지 고민하지 않는다.</pre>
과거의 나 반성해라. 세상에 어떻게 고민하지 않을 수가 있나. 팀원을 구성하고, JD를 올리고, 면접을 진행하고, 최종 채용에 이르기까지 팀원들을 어떻게 꾸려서 어떻게 사용해야 하는지 고민하는 것만 하루종일 한다고 해도 농담이 아니더라. 팀 빌딩은 특히 팀장의 의지대로 되는 것이 아니다. 조직개편에 따라 수시로 섞일 수도 있고, 딱 fit이 맞는 팀원을 채용할 수도 없는데다, fit이 맞다고 생각했지만 실제로 안맞는 경우 등 엄청나게 많은 예측불허의 상황들이 파노라마로 펼쳐진다.
팀을 운영하면서 느끼는 것은 조직관리는 용병술이라는 것이다. 어떤 프로젝트에 어떤 사람들을 넣는 것이 전체적인 팀 성과에 좋은 것인지 고민하면서도 이게 개개인의 성장이나 성과에도 고루 나눠질 수 있는가를 고민하게 된다. 그럼 성과를 정확히 N분 하면 되는가? 현재 역량레벨에 맞는 일만 계속하는 것이 좋은가? 조금 어려운 일들을 주어 더 높은 성과와 역량을 달성할 수 있게 해주어야 하는가? 한 사람에게 좋은 프로젝트가 계속 할당되는 것이 좋은가? 새로운 사람에게 큰 프로젝트를 부여해도 우리 팀의 성과는 안정적인가?
팀원을 둘러싼 고민들이 이렇게나 많았는지 처음 알았다. PO/PM 을 할 때에는 '프로젝트의 성공' 만 보고 달렸기 때문에 과업이 완수될 수만 있다면, 개개인의 역량이나 성과는 크게 신경쓸 필요가 없다. 프로젝트에 참여할 팀원을 고를 권한이 있는 것도 아니고, 각 팀에서 담당자가 모인 것이라 선택권도 거부권도 없었던 시절. 하지만 지금은 이야기가 많이 다르다. 기술적으로 난이도가 있는 과제의 경우가 아니라면, 비즈니스 과제는 리소스할당의 권한이 어느정도 있기 때문에 그에 대한 고민은 계속 해야한다고 생각한다.
다만, 나의 경우 개발자가 아니기 때문에 개발파트의 TL님을 두고, 기술적인 커뮤니케이션을 일임했다. 아무리 개발에 대해 이해한다 해도 알 수 없는 부분들이 너무 많기때문에, 개발에서 고민해야 하는 과제에 대해서는 '이것 해주세요' 라고 assign 하기보다 '이런 배경으로, 이런 것들을 해야 해요'라는 story 를 전달하고 있다. (뭐. 간혹 이거 해주세요 할 때도 있..지만 되도록 안하려고 노력 중이다.)
<h4>팀원 탓이 아니라 팀장 탓인가?</h4>
<pre>발전이 되는 기분이 아닌 소모되는 기분은 계속 그 조직원으로서 일해야 되는 이유를 찾지 못하게 한다. 그렇게 사람들은 회사를 떠나는데, 이유는 다른 곳에서만 찾으려고 하지. 사용자가 도구를 잘못쓰면 도구탓이 아니라 사용자탓인 것을.</pre>
사용자가 도구를 잘못쓰면 사용자탓이라는 생각에서는 아직까진 유효하다. 하지만 자기가 어떤 도구인지는 본인이 알려야 한다는 걸로 생각의 시작점이 바뀌었다. 팀장이 팀원에 대해 잘 알고있다고 생각하지만, 아니다. 전혀 모른다.
이번 상반기에 우리 팀이 신규입사자를 대거 채용하면서 5명이나 되는 입사를 성공시켰는데, 그 중 4명이 내 전 직장 또는 지인이라 최소 1년씩은 함께 일해보거나 지켜봤던 사람들이다. 나는 무언가를 관찰하는 것을 좋아하고 어떤 성향을 가진 사람인지 파악해두는 것을 잘한다고 생각한다. 커뮤니티를 오래하면서 생긴 감각이다. 그래서 이 분들에 대해서도 잘 알고있다고 생각하고 팀원으로 <del>끌어ㄷ...</del> 추천했지만, 팀장-팀원으로 마주하는 것은 다르고, 회사도 비즈니스도 달라졌기 때문에 내가 알고있던 관계와 판단했던 편견들을 모두 내려놨다.
아예 입사 첫주부터 매주 하루는 시간을 온전히 비워, 1 on 1 미팅을 계속하는 중이다. 수습이 종료되는 12주차까지는 계속 진행할 예정이라 아직 질문지가 전부 정리된 것은 아니지만 좀 더 다듬으면 신규입사자든 조직개편으로 편입한 동료든 온보딩 면담 프로그램으로 돌릴 수 있을 것 같다.
이 과정은 처음은 굉장히 낯설지만 조금씩 생각을 열고 이야기를 꺼내기 시작하면서, 면담시간이 점점 늘어나고 있다. 일주일에 고작 하루, 3-4시간씩 연속으로 이야기하는 건 쉬운 일은 아니지만 라포(신뢰, rapport)가 쌓이는 과정이라서 나도 아주 조금씩 그들을 이해하고, 그들도 나에대해 조금씩 이해하기 시작했다. 면담이 끝나고 아주 조금 거리가 가까워 진 것을 느낄 때 굉장한 보람을 느끼고 있다.

<h4>바꾸거나, 바꾸거나</h4>
우아한형제들에서는 (정확히는 범준대표님께서)&nbsp;자주 바꾸거나, 바꾸거나. 라는 말을 언급하곤 한다. <a href="http://wiki.c2.com/?ChangeYourOrganization">마틴파울러의 말</a>이다. 직장을 바꾸거나, 직장을 바꾸거나 라는 의미인데, 전자는 직장을 변화시키는 것, 후자는 직장을 옮기는 것을 의미한다. 나는 생각해보면 업무 프로세스 정도는 내가 바꿀 수 있었기 때문에 허들없이 바꿔왔지만, 팀장이나 리더에 대한 불만으로는 회사를 옮기는 선택을 해왔던 것 같다.
나는 왜 과거에 <code>나는 이런사람입니다</code> 라는 것을 알리지 않았던 걸까? 이런 걸 더 하고싶고, 그러니 이런걸 더 지원해줬으면 좋겠고 이런 시시콜콜하면서도 중요한 일들을 계속 이야기하지 못했던 걸까. 아마 정치질로 보여질 수도 있다는 생각에 입을 다물고 있었을지도 모르겠다. 직위체계가 엄격한 회사가 아니었기 때문에 윗 분들과도 격없이 이야기할 수 있었는데, 그래도&nbsp; 솔직하게 말하지 못하고 <code>님은 절 몰라요 퇴사할래요.</code> 라는 면담의 기억만 그들에게 남겨두고 나온 걸까.
팀원이 무언가를 바꿀 수 있는 기회나 여지는 굉장히 많지만, 그걸 해보기 전에는 모르는 것 같다. 바꿔보려는 시도나, 수단과 방법에 대해선 상황별로 다를 수 있겠지만, 분명히 회사라는 조직에서 가장 권한이 많은건 역시 팀원이라는 말이 농담이 아닌 것 같다. 팀원들이 마음 놓고 일을 할 수 있다면, 팀장 이상의 모든 조직장들은 노력해줄 것이 분명하다. 만약 팀장이 빌런이라면 그 위에 실장, 실장도 빌런이라면 그 위에.. 그 위에.. 어쨌든 위에 나를 도와줄 사람이 있다. 불합리 함을 바꾸는데에는 솔직함만한 것이 없다. 문제의 에스컬레이션(확대, Escalation)은 꼭 팀장을 통해서만 해야되는 것은 아니니까. (하지만, 대표가 빌런이라면 도망치자!)
<h4>팀장도 첫 팀원이 중요하다.</h4>
무엇보다 처음부터 완벽한 팀장은 없다. 팀장이 된다면 이렇게 해야지 저렇게 해야지 백날 상상해봐도 실전은 전혀 다르다. 아무리 실무를 잘하더라도 팀장에게 필요한 역량이 다른 것처럼, 팀장도 공부가 필요하고 노력이 필요하다. 하지만 팀원 입장에서는 그걸 알 턱이 없다. 더군다나 '팀장이라면 당연히 이래야지!' 하는 기준도 엄격하다. 이건 아이를 낳자마자 부모답게 행동하라고 강요하는 것이나 다름없다. 모성애, 부성애가 자동으로 생기는게 아닌 것처럼, 팀장도 팀을 이해하고, 사랑하고, 아끼는데까지 생각보다 긴 시간이 필요하다는 것을 이해해야할 것 같다.
초보부모와 초보팀장에 차이가 있다면, 초보부모는 사회적으로 요구하는 수준이라는게 어느정도 합의가 되어 있지만, 팀장은 롤모델도 없고, 팀원들이 바라는 팀장의 상이 모두 제각각 이라는 문제가 있지 않을까. 매니저와 리더는 다른데, 어떤 팀원은 매니저를 원하고, 어떤 팀원은 리더를 원하기도 한다. 일을 잘시켜주는 매니저를 바라기도 하고, 알아서 일하게끔 비껴주는 매니저를 바라기도 한다. 동기부여를 해주는 리더를 바라기도 하고, 성과로 드리븐해주는 리더를 바라기도 한다.
그래서 팀운영을 위한 팀장교육은 꼭 필요하다고 생각한다. 특히 같이 고민하는 동료 팀장이 있으면 정말 좋은 것 같다. 얼마전 사내에서 신입리더 교육을 받았는데, 비슷한 고민들을 서로가 하고있는 걸 보면서 정말 큰 위로를 받았었다. 만약 팀 관리에 어려운 일이 있을 때 도움을 청할 곳이 없다면 얼마나 막막할까. 나도 생전 처음 겪는 어려움에 며칠밤을 새기도 했다.
그런 의미라면, 첫 팀장으로 맡은 첫 팀원들이 얼마나 중요한 역할을 하는지 모른다. 좋은 팀원들에서 좋은 팀장이 나고, 나쁜 팀원들 사이에서 나쁜 팀장이 난다. 손뼉도 마주쳐야 소리가 난다. 좋은 팀을 만드는 일은 팀장이 홀로 할 수 없다. 마음이 열린 팀원과 마음이 열린 팀장이 최고의 팀웍을 만들어낼 수 있다. '우리팀은 또라이가 없어서 좋아요' 가 아니라 '무엇이든지 해낼 수 있는 우리 팀이 좋아요' 라는 소리를 듣고 싶고, 더 나아가 '저 팀과 일하고싶다'는 이야기를 들어보고 싶다.
팀도 Product이라고 생각한다면, 팀장은 PO인 셈이고, 이 Product에서 너무나 멋진 도전과 미션들이 이어질 것이기 때문에 팀매니저로 커리어를 이어가는 것도 꽤 매력적인 일인 것 같다. 특히나 기획자로서의 전문성을 계속 쌓아나가면서도, 조직관리 커리어를 새롭게 도전해볼 기회가 온 것 같아 너무 설렌다.
좋은 팀원들로 첫 팀장의 커리어를 시작한 것은 축복이니, 이 기회를 날리지 말아야지 다짐해본다.

ps. 글이 마무리가 안된다. 아직 생각이 많아서 그렇다. 그래도 실제로 현업에 있는 팀장의 글은 찾아보기 어려웠던 것 같아서,정제되지 않은 생각이라도 계속 남겨보려고 한다. 특히, 조금 더 정제될 미래의 나에게 남기는 글이기도 하고.
Photo by&nbsp;<a href="https://unsplash.com/@jaysung?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Jehyun Sung</a>&nbsp;on&nbsp;<a href="https://unsplash.com/s/photos/team-leader?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a>
</div></div>

by minieetea

팀장 발령은 올해 2월쯤 받았으니, 이제 120일? 갓 넘은 신생아다. 그 때는 제품개발하는 데에 올인한 상태여서 팀장이 무슨 일을 해야하는지 전혀 생각하지 못했다. 하지만 그 타이밍에 내가 팀장이라 해야되는 첫 번째 업무가 바로 '인사평가면담'이었다. 작년 인사평가에 대한 평가자는 아니었지만, 면담은 현팀장이 해야한다는 룰이 있었는데, '왜 면담 안해주지?' 라고 멍때리고 있다가 '아 내가 하는 거였어?' 하고 부랴부랴 면담일정을 잡았던 기억이 있다.
그리고나서 나의 평가를 받았는데, 정확한 워딩은 잘 기억나지 않지만 과제의 추친과 팀원의 케어는 함께 하기 어렵다 라는 내용에 크게 머리를 맞은 듯한 느낌을 받았었다. 일 못한다는 얘기는 안 들으려고 항상 최선을 다하고 있지만, 지금처럼 일하면 팀원케어는 안중에도 없을게 뻔했다. 팀장이 해야할 최우선 업무는 주어진 과제를 잘 성공시키는 것 라고만 생각했지, 팀원의 케어 라는 한 꼭지가 더 있음을 드디어 깨달은 것이다. 팀원이었던 나는 주로 알아서 일을 찾는 편이라 팀장의 케어가 잔소리로 느껴지거나 케어가 없어도 된다고 생각했었기 때문에 팀장의 주요역할이라고 생각하지 못했던 탓도 크다.
제품관리자로 수년을 일해오면서 적지 않은 개발자들과 스펙과 일정을 관리하고 중요한 의사결정을 할 때도 많아서 팀장도 하는 일이 크게 다르지 않다고 생각했다. 오히려 PO로 일하며 수십개의 회의를 다녔는데, 팀장은 그보다 더 중요한 회의가 많아 일 자체는 더 적게 하는거 아닌가 생각한 적도 있다. 그러면서도 일을 잘 시키는 것은 팀장의 일이고, 팀장이 시키는 것을 잘해야 팀원들이 좋은 성과를 낼 수 있다고 생각했다. 그런 생각으로 썼던 페북의 2년전 글이 발굴되어 덕분에 이 포스팅을 쓰게 된 셈이다.
 
팀장은 일을 잘시켜야 하는가?
일을 잘 시켜야 한다고 생각한다.
일단 이 문장에서는 2가지 키워드를 뽑아볼 수 있다. 일, 시키다. 팀장은 팀원에게 일을 시켜야 하는가. 팀원들은 팀장이 시키는 일만 해야하는가. 팀원들은 시키기 전에 일할 수 없는가.
팀장은 팀원들이 하는 일을 전부 알 수 없다. 개발자 팀장이 개발자 팀원을 관리한다고 하더라도, 팀원들의 코드레벨까지 팀장이 알 수 없다. 그렇기 때문에 무언가를 '시키다'는 행위는 제대로 동작할 수 없는 행위다. 반대로 팀원은 아니면 아니다, 되면 된다, 아니면 더 좋은 솔루션이 있다면 언제든지 먼저 제안할 수 있어야 한다. 팀매니저가 모든 것을 알고있지 않다는 것을 전제하고, 알게해주는 것이 팀원들의 역할이라고 할 수 있다.
팀원들은 시키기 전에 일할 수 없는가. 이 질문은 사람마다 다른 답을 할 것 같다. 당연히 먼저 할 수 있지만, 어떻게 하느냐는 함께 얘기해봐야 한다. 잠깐이면 처리하고 나올 수 있는 일인가, 아니면 앞으로의 퍼포먼스를 높이기 위해 내 일정을 무리해서라도 먼저 해두느냐, 아님 프로젝트 방향에 맞지도 않는데 추진해버리느냐 각각이 전부 다른 결과로 이어진다.
자기는 별 것이 아니라고 생각했던 작업이 다른 유관팀에 영향을 줄 수도 있고, 비즈니스 요구사항에 영향을 줄 수도 있기 때문에 발견한 백로그는 반드시 공론화 해야 한다고 생각한다. 이 일을 해야하는 이유와 배경에 대해서 팀장 혹은 다른 팀원들과 공유하고 전체 일정에 무리가 되지 않는 선에서 우선순위를 조정하하고, 합의에 의해 시작할 수 있는 타이밍을 잡으면 된다.
'실무에서 손 뗀 팀장이 팀원들과 일하는 법' 같은 깨달음을 얻게 된다면, 반드시 글을 써보리라.
팀장은 고민하지 않는가?
대부분의 사용자들(=고용자)들은 (피고용자를) 어떻게 사용해야되는지 고민하지 않는다.
과거의 나 반성해라. 세상에 어떻게 고민하지 않을 수가 있나. 팀원을 구성하고, JD를 올리고, 면접을 진행하고, 최종 채용에 이르기까지 팀원들을 어떻게 꾸려서 어떻게 사용해야 하는지 고민하는 것만 하루종일 한다고 해도 농담이 아니더라. 팀 빌딩은 특히 팀장의 의지대로 되는 것이 아니다. 조직개편에 따라 수시로 섞일 수도 있고, 딱 fit이 맞는 팀원을 채용할 수도 없는데다, fit이 맞다고 생각했지만 실제로 안맞는 경우 등 엄청나게 많은 예측불허의 상황들이 파노라마로 펼쳐진다.
팀을 운영하면서 느끼는 것은 조직관리는 용병술이라는 것이다. 어떤 프로젝트에 어떤 사람들을 넣는 것이 전체적인 팀 성과에 좋은 것인지 고민하면서도 이게 개개인의 성장이나 성과에도 고루 나눠질 수 있는가를 고민하게 된다. 그럼 성과를 정확히 N분 하면 되는가? 현재 역량레벨에 맞는 일만 계속하는 것이 좋은가? 조금 어려운 일들을 주어 더 높은 성과와 역량을 달성할 수 있게 해주어야 하는가? 한 사람에게 좋은 프로젝트가 계속 할당되는 것이 좋은가? 새로운 사람에게 큰 프로젝트를 부여해도 우리 팀의 성과는 안정적인가?
팀원을 둘러싼 고민들이 이렇게나 많았는지 처음 알았다. PO/PM 을 할 때에는 '프로젝트의 성공' 만 보고 달렸기 때문에 과업이 완수될 수만 있다면, 개개인의 역량이나 성과는 크게 신경쓸 필요가 없다. 프로젝트에 참여할 팀원을 고를 권한이 있는 것도 아니고, 각 팀에서 담당자가 모인 것이라 선택권도 거부권도 없었던 시절. 하지만 지금은 이야기가 많이 다르다. 기술적으로 난이도가 있는 과제의 경우가 아니라면, 비즈니스 과제는 리소스할당의 권한이 어느정도 있기 때문에 그에 대한 고민은 계속 해야한다고 생각한다.
다만, 나의 경우 개발자가 아니기 때문에 개발파트의 TL님을 두고, 기술적인 커뮤니케이션을 일임했다. 아무리 개발에 대해 이해한다 해도 알 수 없는 부분들이 너무 많기때문에, 개발에서 고민해야 하는 과제에 대해서는 '이것 해주세요' 라고 assign 하기보다 '이런 배경으로, 이런 것들을 해야 해요'라는 story 를 전달하고 있다. (뭐. 간혹 이거 해주세요 할 때도 있..지만 되도록 안하려고 노력 중이다.)
팀원 탓이 아니라 팀장 탓인가?
발전이 되는 기분이 아닌 소모되는 기분은 계속 그 조직원으로서 일해야 되는 이유를 찾지 못하게 한다. 그렇게 사람들은 회사를 떠나는데, 이유는 다른 곳에서만 찾으려고 하지. 사용자가 도구를 잘못쓰면 도구탓이 아니라 사용자탓인 것을.
사용자가 도구를 잘못쓰면 사용자탓이라는 생각에서는 아직까진 유효하다. 하지만 자기가 어떤 도구인지는 본인이 알려야 한다는 걸로 생각의 시작점이 바뀌었다. 팀장이 팀원에 대해 잘 알고있다고 생각하지만, 아니다. 전혀 모른다.
이번 상반기에 우리 팀이 신규입사자를 대거 채용하면서 5명이나 되는 입사를 성공시켰는데, 그 중 4명이 내 전 직장 또는 지인이라 최소 1년씩은 함께 일해보거나 지켜봤던 사람들이다. 나는 무언가를 관찰하는 것을 좋아하고 어떤 성향을 가진 사람인지 파악해두는 것을 잘한다고 생각한다. 커뮤니티를 오래하면서 생긴 감각이다. 그래서 이 분들에 대해서도 잘 알고있다고 생각하고 팀원으로 끌어ㄷ... 추천했지만, 팀장-팀원으로 마주하는 것은 다르고, 회사도 비즈니스도 달라졌기 때문에 내가 알고있던 관계와 판단했던 편견들을 모두 내려놨다.
아예 입사 첫주부터 매주 하루는 시간을 온전히 비워, 1 on 1 미팅을 계속하는 중이다. 수습이 종료되는 12주차까지는 계속 진행할 예정이라 아직 질문지가 전부 정리된 것은 아니지만 좀 더 다듬으면 신규입사자든 조직개편으로 편입한 동료든 온보딩 면담 프로그램으로 돌릴 수 있을 것 같다.
이 과정은 처음은 굉장히 낯설지만 조금씩 생각을 열고 이야기를 꺼내기 시작하면서, 면담시간이 점점 늘어나고 있다. 일주일에 고작 하루, 3-4시간씩 연속으로 이야기하는 건 쉬운 일은 아니지만 라포(신뢰, rapport)가 쌓이는 과정이라서 나도 아주 조금씩 그들을 이해하고, 그들도 나에대해 조금씩 이해하기 시작했다. 면담이 끝나고 아주 조금 거리가 가까워 진 것을 느낄 때 굉장한 보람을 느끼고 있다.
 
바꾸거나, 바꾸거나
우아한형제들에서는 (정확히는 범준대표님께서) 자주 바꾸거나, 바꾸거나. 라는 말을 언급하곤 한다. 마틴파울러의 말이다. 직장을 바꾸거나, 직장을 바꾸거나 라는 의미인데, 전자는 직장을 변화시키는 것, 후자는 직장을 옮기는 것을 의미한다. 나는 생각해보면 업무 프로세스 정도는 내가 바꿀 수 있었기 때문에 허들없이 바꿔왔지만, 팀장이나 리더에 대한 불만으로는 회사를 옮기는 선택을 해왔던 것 같다.
나는 왜 과거에 나는 이런사람입니다 라는 것을 알리지 않았던 걸까? 이런 걸 더 하고싶고, 그러니 이런걸 더 지원해줬으면 좋겠고 이런 시시콜콜하면서도 중요한 일들을 계속 이야기하지 못했던 걸까. 아마 정치질로 보여질 수도 있다는 생각에 입을 다물고 있었을지도 모르겠다. 직위체계가 엄격한 회사가 아니었기 때문에 윗 분들과도 격없이 이야기할 수 있었는데, 그래도  솔직하게 말하지 못하고 님은 절 몰라요 퇴사할래요. 라는 면담의 기억만 그들에게 남겨두고 나온 걸까.
팀원이 무언가를 바꿀 수 있는 기회나 여지는 굉장히 많지만, 그걸 해보기 전에는 모르는 것 같다. 바꿔보려는 시도나, 수단과 방법에 대해선 상황별로 다를 수 있겠지만, 분명히 회사라는 조직에서 가장 권한이 많은건 역시 팀원이라는 말이 농담이 아닌 것 같다. 팀원들이 마음 놓고 일을 할 수 있다면, 팀장 이상의 모든 조직장들은 노력해줄 것이 분명하다. 만약 팀장이 빌런이라면 그 위에 실장, 실장도 빌런이라면 그 위에.. 그 위에.. 어쨌든 위에 나를 도와줄 사람이 있다. 불합리 함을 바꾸는데에는 솔직함만한 것이 없다. 문제의 에스컬레이션(확대, Escalation)은 꼭 팀장을 통해서만 해야되는 것은 아니니까. (하지만, 대표가 빌런이라면 도망치자!)
팀장도 첫 팀원이 중요하다.
무엇보다 처음부터 완벽한 팀장은 없다. 팀장이 된다면 이렇게 해야지 저렇게 해야지 백날 상상해봐도 실전은 전혀 다르다. 아무리 실무를 잘하더라도 팀장에게 필요한 역량이 다른 것처럼, 팀장도 공부가 필요하고 노력이 필요하다. 하지만 팀원 입장에서는 그걸 알 턱이 없다. 더군다나 '팀장이라면 당연히 이래야지!' 하는 기준도 엄격하다. 이건 아이를 낳자마자 부모답게 행동하라고 강요하는 것이나 다름없다. 모성애, 부성애가 자동으로 생기는게 아닌 것처럼, 팀장도 팀을 이해하고, 사랑하고, 아끼는데까지 생각보다 긴 시간이 필요하다는 것을 이해해야할 것 같다.
초보부모와 초보팀장에 차이가 있다면, 초보부모는 사회적으로 요구하는 수준이라는게 어느정도 합의가 되어 있지만, 팀장은 롤모델도 없고, 팀원들이 바라는 팀장의 상이 모두 제각각 이라는 문제가 있지 않을까. 매니저와 리더는 다른데, 어떤 팀원은 매니저를 원하고, 어떤 팀원은 리더를 원하기도 한다. 일을 잘시켜주는 매니저를 바라기도 하고, 알아서 일하게끔 비껴주는 매니저를 바라기도 한다. 동기부여를 해주는 리더를 바라기도 하고, 성과로 드리븐해주는 리더를 바라기도 한다.
그래서 팀운영을 위한 팀장교육은 꼭 필요하다고 생각한다. 특히 같이 고민하는 동료 팀장이 있으면 정말 좋은 것 같다. 얼마전 사내에서 신입리더 교육을 받았는데, 비슷한 고민들을 서로가 하고있는 걸 보면서 정말 큰 위로를 받았었다. 만약 팀 관리에 어려운 일이 있을 때 도움을 청할 곳이 없다면 얼마나 막막할까. 나도 생전 처음 겪는 어려움에 며칠밤을 새기도 했다.
그런 의미라면, 첫 팀장으로 맡은 첫 팀원들이 얼마나 중요한 역할을 하는지 모른다. 좋은 팀원들에서 좋은 팀장이 나고, 나쁜 팀원들 사이에서 나쁜 팀장이 난다. 손뼉도 마주쳐야 소리가 난다. 좋은 팀을 만드는 일은 팀장이 홀로 할 수 없다. 마음이 열린 팀원과 마음이 열린 팀장이 최고의 팀웍을 만들어낼 수 있다. '우리팀은 또라이가 없어서 좋아요' 가 아니라 '무엇이든지 해낼 수 있는 우리 팀이 좋아요' 라는 소리를 듣고 싶고, 더 나아가 '저 팀과 일하고싶다'는 이야기를 들어보고 싶다.
팀도 Product이라고 생각한다면, 팀장은 PO인 셈이고, 이 Product에서 너무나 멋진 도전과 미션들이 이어질 것이기 때문에 팀매니저로 커리어를 이어가는 것도 꽤 매력적인 일인 것 같다. 특히나 기획자로서의 전문성을 계속 쌓아나가면서도, 조직관리 커리어를 새롭게 도전해볼 기회가 온 것 같아 너무 설렌다.
좋은 팀원들로 첫 팀장의 커리어를 시작한 것은 축복이니, 이 기회를 날리지 말아야지 다짐해본다.
 
ps. 글이 마무리가 안된다. 아직 생각이 많아서 그렇다. 그래도 실제로 현업에 있는 팀장의 글은 찾아보기 어려웠던 것 같아서,정제되지 않은 생각이라도 계속 남겨보려고 한다. 특히, 조금 더 정제될 미래의 나에게 남기는 글이기도 하고.
Photo by Jehyun Sung on Unsplash

과연 팀장 탓 일까?

댓글