팀장이란 ?

팀장이란걸 난생 처음 해보고나서.... ?

 

 항상 내가 지시를 하고 관리하던 입장 보단 지시를 받고 관리를 받던 입장으로 오랫동안 업무를 진행 했던것 같다. 그러면서 여러가지 유형의 팀장들을 만났고 여러가지 케이스들을 경험 하였다. 

 상황이 어떻게 되다 보니까 급작스럽게 팀장이 되었고, 팀장으로써 내가 무엇을 해야 하는지에 대한 고민을 급하게 되었던것 같다. 가장먼저한것은 내가 경험했던 팀장들의 유형을 떠올려 보는것이였다. 

1) 관리형 팀장 

2) 기술형 팀장 

크게는 이 두형이 있던것 같다. 극단적으로 관리만 하던 팀장부터 내가 말하지 않은 부분까지 기술적으로 코칭을 해주던 팀장까지 어떻게보면 나에게는 좋은 경험 이였던것 같다. 두 팀장의 장단점은 아주 명확하다. 기술력의 수준에 따른 차이가 두가지유형을 나눈다. 

보통 기술력이 좋은 팀장은 팀원에게 기술적으로 조언을 해주거나 무엇가를 같이 해보자고 제안을 많이 하는 방면 관리형 팀장은 보고를 더 많이 받았던거 같다. 그리고 공통점인것은 둘다 결정이란것을 내려주는것이 많았다. 

개인적으로는 두 팀장 유형에 대해서 장단점이 명확하기 때문에 회사의 서비스 그리고 팀의 성격에 따라 두 팀장은 누가 좋다 나쁘다를 따지기에는 힘들다고 느꼈다.

수많은 서비스들을 만들어내야하고 일정이 치열한 팀이라면 관리형 팀장이 더 나은경우가 있었다. 단 전제 조건은 기술리딩을 할수 있는 인원이 팀에 존재 할 경우다 . 리딩할수 없는 인력이 없으면 팀원들은 기술적 갈증을 느끼게 되고 팀장이 능력없다, 팀장이 일을 하지 않고 보고만 받는다라는 인식을 가지게 되는 케이스들이 보였다. 실제로 나도 그렇게 느꼈던적이 있고 이건 관리형 팀장의 치명적인 단점인것 같다. 

반대로 기술형 팀장은 기술적 갈증에서는 자유롭다. 팀원들의 기술적 결정이라던게 더 좋은 기술적 대안을 제시 해줄수 있기 때문에 이런부분의 만족도는 전반적으로 높았다. 하지만 관리형 팀장과 극명하게 갈리는 부분은 대화시의 문제이다 

물론 관리형 팀장중에도 꼰대라는것이 존재 하겠지만 기술형 팀장일 경우 는 상황이 달라진다. 관리형 팀장을 설득하기위해선 물론 많은 에너지를 쏟아 부어서 대화를 하고 설득을 해야하겠지만 개발자 입장에서는 개발력이 상대적으로 부족한 사람 상대로 잘만 이야기를 풀수 있다면 협상의 여지가 있다. 하지만 기술형 팀장은 팀장이기전에 개발자이다. 그렇다보니 개발자 특유의 고집이 존재한다. 내가 할때는... 내가 해보니까... 내가 알기론 ... 등등 꼰대들의 전용 대사들을 아주 어렵지않게 들을수 있다. 심할 경우는 팀장이 타협을 전혀 고려 하지 않을 수도 있다. 이럴경우에는 팀원들 입장에서는 소통을 포기하게 되고 왜이런 방식으로 해야하지라는 업무적 불만족이 생길수 있다. 

 관리형팀장들이 소통이 쉽지만 상대적인 기술력부재로인한 답답함이 존재한다면 기술형 팀장들은 기술적 마찰이 생길수 있지만 때에 따라 업무에 직접적인 영향을 줄수 있는것 같다. 이 두가지가 적절히 믹스된 팀장을 만난다면 아마 가장 베스트 이지 않을까 ? 라는 생각을 하지만 나도 여태 그런 팀장을 거의 만나 보지 못한것 같다. 

 팀장의 유형을 나누고 나서 내가 할일은 난 어떤 팀장이 되어야 할지를 고민하는 일이였던것 같다. 그러기위해서 가장 먼저 생각한건 내가 지금 속한 회사가 어떤서비스를 하고 우리팀이 어떤 역할을 하는지를 먼저 알아야 했고 , 우리 팀원들의 구성원들을 파악이 먼저 필요했다. 다행이 이회사에 처음오자마자 팀장을 맡은게 아니라 회사의 서비스에 대해선 인지를 했고 팀의 역할도 충분히 인지하고 있었다. 바로 팀원들의 대한 파악을 시작했다. 

최초 팀을 맡았을땐 팀원은 달랑 2명이였다. 현재는 총 6명에 계약직 인원까지 합치면 11명정도 되는 규모(?)까지 커졌다. 최초 2명이였지만 팀원만 보면 전혀 다른팀과 별다를것 없는 난이도 의 구성이였다. 왜냐하면 한명은 개인적인 사유가 있어 좀 특별한 환경을 가진 여성 직원 이였고 다른 한명은 한국말을 유창하게 하지 못하는 외국인 남성이였다. 

내가 시도할수 있는건 면담이였다. 각자의 업무에 대해서 면담을 진행하기 위해서 난 각자에게 맡긴 업무를 정리했고 지금 당장해야하는일 그리고 앞으로 이렇게 이런식으로 이런것들을 해줬으면 좋겠다는 미래지향적인 내용 두가지를 준비했다. 그리고 전달을 먼저했고 가장 본론인 질문을 했다 " 지금 일하면서 힘든게 어떤게 있나요 " 아주 평범하고 아주 흔한 질문이지만 난 이 질문이 가장 중요하다고 생각한다. 

 "팀을 위한 서포터"  

 내 스스로 정의한 팀장의 역할은 이렇다.

 팀에 군림하는 팀장 ,민주적인것을 추구하는 팀장 , 모든걸 스스로 돌파해나가는 에이스형 팀장등 이것이 관리형이던 기술형이던 팀장들마다 추구하는 바에 따라 다양하게 존재했고 그 과정에서 난 어떤것들을 해나가야 하는지에 대한 아주 좋은 지표이자 데이터 였다. 

 팀장은 팀을 잘 운영하는게 기본 역할이라고 생각한다. 상황에 맞게 기술 부채가 많다면 기술 리더로써의 역할을 대신하는게 맞고 중구난방의 관리안되는 일들을 진행한다면 관리부터 집중적으로 해야할것 같다. 근데 아쉽게도 내가 만난 팀장들은 그 역할을 유동적으로 잘하는 사람들을 만나지 못했다. 관리가 더이상 필요하지 않음에도 관리만 하다가 팀원들에게 신임을 잃거나 너무 기술적으로만 접근해서 팀원들에게 이해하지 못한 기술들을 강요하거나 강제 하여 오히려 업무상 불편하는 유발하는 유형이 더 많았던것 같다. 물론 그런 분들중에도 나름 해결 방식을 찾아서 개선해보려고 하시던분들은 있지만 결과는 대부분 자신이 하던방식을 버리지 못해 실패하는경우가 많았고 거의 대부분은 극단적으로는 내가 팀장인데 왜 팀장말을 거역하나는 식이거나 자신의 방식을 바꾸려는 의지가 없던 경우가 더 많았다. 

 팀운영이란게 단순히 프로젝트만 잘 굴러가면 끝이 아니라 팀원들의 만족도, 그리고 성취감을 지속적으로 보장해주어야 하고 인력들이 오랫동안 회사에서 잘다닐수 있는 환경을 만들어 주는것도 운영이라고 생각한다. 

 실리콘밸리의 팀장들이란 책에서 공감하는 내용이 있는데 인력은 크게 락스타형, 슈퍼스타형으로 나누는것이 굉장히 인상적이였다. 한번쯤 읽어보면 좋을듯 하다.

http://www.yes24.com/Product/Goods/74259979

사람은 사람마다 다르고 원하는게 다르다. 그리고 그건 실제로 회사에서 무엇인가를 새롭게 해내고 싶은 사람과 회사를 안정적으로 다니고 싶은 변화가 두려운사람으로 나눌수 있다고 한다. 그렇다면 각 유형별로 팀장으로써 만족도를 높여 줘야하지 않을까 ? 서로 다른 방식으로 말이다 근데 보통은 그쳐 팀운영은 앞으로 이렇게 할것이다라고 하면서 모든 팀원에게 동일한 잣대를 들이밀게 된다. 난 개인의 개성이 좀더 강해진 요즘 시대에는 팀장으로써 예전처럼 "우리" 라는 마인드보다는 "당신" 이라는 마인드를 좀더 중요하게 생각해야하지 않을까 싶다. 

 팀운영은 프로젝트 + 인력 두가지를 잘 운영해야만 한다고 생각했고 난 팀원들의 개개인에 대해서 면담을 하고 각 개개인에게 맞는게 무엇일까에 대한 고민도 하며 , 관리적측면이나 기술적 측면에서 지원을 아끼지 않으려고 노력했다. 물론 그 성과에 대해선 팀원들이 각자 어떻게 느낄지는 모르겠다. 

 팀원들에 대한  고민이 끝나고 내가 그다음 생각한건 운영이다. 지금 내가 맡은 팀은 이전 팀장이 철저하게 방치한 팀이였다. 운영 툴부터 운영서비스 는 당연히 아무것도 고려된게 없고 하다못해 코드 빌드 / 배포조차 되있지 않았다. 나중에 정말 욕이 나왔지만 코드대부분이 튜토리얼 수준으로 개발되어져서 서비스를 하고 있었다. 당연히 이런 서비스가 장애가 없을리 없었고 장애가 터졌을때 안보이게만 가려놓은 수준으로 운영되고 있었다. 

 내가 해야할게 명확하게 보였다. 일단 잠재적 버그들을 해결 해야 했고 기존 개발 인력의 수준도 높여 줘야만 했다. 휴먼장애를 방지하기 위한 솔루션들 도입을 검토 해야했고 장애대응 방안과 눈가리고 아웅 해놓은 서비스들을 다 재정비 해야할거 같았다. 그리고 부족한 인력들을 충원 해야 했다. 

 6개월동안 최대한 심각한 잠재적 버그들은 시간을 투자하여 코드리뷰를 통해 해결 했나가기 시작했고 운영툴들은 전반적으로 어떤것들을 사용할지 리스트업을 하고 가장 먼저 필요한것들을 적용하기 시작했다. 장애 발생시 가이드 부터 장애 대응도 자동화 할수 있는부분들을 자동화 하였다. 그리고 가장 신경 썼던건 장애 발생시 특정 담당자에게 몰려서 업무를 못하는 상황과 비효율적으로 노가다(?)식으로 처리하던 업무 방식을 모두 뜯어 고쳤다. 특정 담당자에게 직접 가던 연락들을 메일로 나에게 오게 만들었고 담당자는 일절 신경 안쓰이게 하도록 타팀과 수많은 협의를 진행했다. 그리고 담당자의 실력 문제로 일일히 노가다로 하던 업무들을 정리하여 솔루션으로 자동화 할것들을 정리하고 업무 방식에 대한 가이드들을 꾸준히 교육 시켰다. 이 팀에는 지금 기술형 리더보다는 관리형 리더가 필요 했다고 판단 했고 난 그 방침을 지키려고 꾸준히 노력했다. 

현재는 전부다 해결했다고 할순 없지만 , 팀원들로 부터 이전보다는 일하기 나아졌다는 이야기를 듣고 있다. 나름 뿌듯은 하지만 완벽하지 않기 때문에 아직 해야할일들이 많기 때문에 만족할 단계는 아닌거 같다.  난 이런 업무들이 내가 할수 있는 관리자로써의 업무라고 생각한다. 기술자로써는 코드리뷰와 쓸만한 솔루션들을 제안하고 관리자 로썬 불필요한 업무와 업무에 방해되는것들을 제거해주는것 내가 할수 있는 최선이 아닌가 생각했다. 

 지금은 관리적 측면이 더이상 필요 하진 않다. 물론 다한건 아니지만 남은 부분들은 다른 누군가가 와도 다 개선할수 있다고 생각한다. 현재는 기술적으로 해결해야할 부분들이 많다. 그래서 팀장을 할수 있는 사람을 고용했고 난 조만간 팀장을 내려놓고 일반 사원으로 내려갈 생각이다. 물론 팀장으로써 기술적 리더 역할을 할수 있지만 현재는 관리자일과 병행하면서 하기엔 시간과 인력의 부족이 있어 불가능한 상황이다. 그렇다고 내가 기술적으로 높은 수준은 아니기 때문에 나역시 공부를 하면서 하나하나 해결해 나가야하는 상황이다보니 더더욱 팀장으로써의 역할을 모두 해낼수 없단 생각에 팀장을 내려놓는게 맞다는 생각이 들었다. 

 옛날의 팀장이라면 팀을 이끌어가는 리더라고 많이들 이야기 했지만 난 좀 의견이 다르다. 이젠 팀원들이 주도적으로 팀을 이끌어 나가야하고 각자의 업무의 효율을 위한 노력을 해야하는 시대라고 생각한다. 뛰어난 팀장이 하나 있다고 팀이 절대 제대로 돌아 갈수 없다. 그렇다고 팀장이 능력이 너무 없어도 팀은 돌아가지 않는다. 그렇기 때문에 팀장은 계속 자기스스로를 발전시킬 의무가 생겼고 팀원 하나하나의 개인성을 보장해줘야 한다고 생각한다. 노력하지 않는 팀장에게는 절대 좋은 팀원들이 남지 않는것 같다. 

 더이상 팀장은 팀원들 위에 군림하는것이 아니라 팀원들 뒤에서 묵묵히 밀어주거나 나란히 걸어갈수 있는 사람이라고 생각한다. 

 

팀장이란 ? Part.2 에서 계속....

https://ellune.tistory.com/74

 

팀장이란 ? (part.2 )