관리자로 가야 할까??

• 언제까지 천상 개발만 할 수 없다고 생각 한다. 

 언젠가는 관리 역할의 비중도 높아 질것이고 관리자가 되면 무엇을 해야하는지 생각 해보고, 필자도 관리자는 하기가 싫지만 왜 하기가 싫은건지? 좋은 관리자의 역할의 예를 구글의 제시한 관리자의 자격을 보면서 재해석 해 보았다.

• 소프트웨어 엔지니어는 어느 직업보다 스페셜리스트에 대한 대우가 높다. 대부분의 개발자 들은 다른 스킬보다 커뮤니케이션 능력 및 관리자에 역할을 꺼려한다.
  

• 개발자에서 관리자로 넘어가는 시점은 과장 직급 이상이나 빠르면 5년차 경력부터 관리와 개발 두개의 테크를 동시에 가져가게 되는 경우가 빈번하다.

• 이는 연차가 올라가면서 개발 보다는 문서 작성이나 임원에게 보고 등 프리젠테이션 업무가 늘어나고, 부하 직원들에게 오더를 내리고 실제 개발을 할시간이 점점 줄어들기 때문에 프로그래밍을 좋아하는 천상 개발자는 관리자 테크트리를 타는 것을 싫어 한다.

• 개발자가 '장' 이라는 타이틀을 달기 시작하면 타면 커리어가 꼬이기 시작한다.
  
• 지위가 올라가도 코드를 생산하지 않으면 부차적 존재라는 자괴심을 느낀다.
• 문서 작성, 프리젠테이션 등 경연진에게 보고해야 하는 업무가 증가 한다.
• 회의가 빈번하여 개발에서는 점점 멀어진다.

• 개발자가 관리자가 되기 싫은 이유는 진정 원하는 프로그래밍 개발 시간이 줄어 드는 것이 가장 크다고 본다.

• 좋은 관리자란?
  
• 좋은 관리자의 정의는 너무 어려운 질문인거 같다. 관리만 잘하면 된다는 기준점이 명확하지 않기 때문이다.
• 프로젝트가 성공적으로 끝났다고 해서 관리를 잘했다고 할 수는 없다.

• 좋은 관리자가 진정 해야 하는 일은 사람들에게 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다. "피플웨어, (톰 디마르코/티모시 리스터, 인사이트"

구글이 제시한 '관리자의 자격' 재해석

• 좋은 코치(coache)다.
  

• 좋은 코치는 스스로 뛰는 사람이 아니라, 선수가 원하는 포지션에서 마음껏 뛰게 해주는 사람이다.
• 기술 관리자(technical manger) 혹은 동료 개발자 중에는 자신의 기술적 역량과 판단을 팀원의 것보다 우위에 놓고 시시콜콜 하게 명령(강요)을 내리는 사람이 있다. 
• 이런 태도는 자신의 기술력에 의존하기 때문에 팀원을 스스로 생각하는 창의적인 개발자가 아니라 자신의 명령을 오차없이 수행하는 병사로 취급한다.
• 이런 관리자 아래에서 일하는 개발자가 건강한 동기부여를 가질 리 없다. 

• 팀에게 권한을 양도하며 마이크로매니지를 하지 않는다.
  
• 사소한 부분을 일일이 간섭하고 통제하는 마이크로매니지는 관리자의 그릇과 연결된 문제다. (이런 개발자는 관리자 테크를 타면 안된다.)
• 좋은 관리자는 팀원을 통제하는 것이 아니라 팀원에게 필요한 일의 전후맥락을 설명한 후, 믿고 맡긴다. 
• 사소한 통제에 집착하는 관리자는 문맥을 제시할 능력이 없기 때문에 그렇게 하는 것이며, 따라서 관리자로서의 역량이 부족한 것이다. 
• 관리자의 마이크로매니지는 개발자의 생산성을 저해하는 치명적인 독이다.

• 팀원의 성공에 관심을 포명하며 개인적 삶에도 관심을 기울인다.
  
• 팀원의 개인적 삶에 관심을 갖는 것은 관리자 자신의 취향과 스타일에 달려있는 문제다. 
• 하지만 팀원의 성공에 관심을 갖는 것은 좋은 관리자가 갖춰야 하는 필수 덕목이다. 
• 최근에 나는 회사에서 자신의 팀원과 '경쟁'하는 관리자를 발견하고 전후맥락을 살핀 다음 인사조치를 단행한 경험이 있다. 
• 자기가 가진 권력적 우위를 이용해서 팀원의 아이디어를 자신의 아이디어로 둔갑시키는 관리자를 발견한 것이다. 
• 이건 관리자가 가질 수 있는 모습 중에서 최악이다. 
• 좋은 관리자는 팀원을 이용해서 자기를 돋보이게 만드는 것이 아니라 진심으로 팀원의 성공을 위해서 봉사해야 한다.

• 생산적이며 결과를 중심으로 사고한다.
• 결과를 중심으로 사고하는 것도 반드시 필요하다.
• 개인적인 호불호, 지연이나 학연, 아부, 허황된 장담, 소문, 감정에 휘둘리는 관리자는 관리자로서의 자격이 없다. 
• 누가 좋은 품질의 코드를 생산하는가, 얼마나 빠르고 정확하게 일을 마치는가, 어려운 문제를 해결하기 위한 좋은 아이디어를 제안하는가, 다른 사람과 잘 협업하는가, 스스로 할 일을 찾아서 적극적으로 행동하는가, 의사소통을 잘 해서 자기가 하는 일을 투명하게 만드는가. 
• 이런 구체적인 결과만으로 판단을 해야한다. 
• 출퇴근 시간, 휴가, 재택근무, 병가 같은 근태 역시 결과 중심의 사고에 영향을 주지 않아야 옳다.

• 훌륭한 커뮤니케이션 능력을 가지고 있다.
• 관리자가 좋은 커뮤니케이션 능력을 가져야 한다는 것은 상식이다. 
• 다만 여기에서 말하는 커뮤니케이션은 말을 뉴스앵커처럼 또박또박 유려하게 하라는 뜻이 아니다. 
• 투명하고 솔직해야 한다는 뜻이다. 
• 공감(empathy)하고 공명(resonance)해야 한다는 뜻이다. 
• 아무리 역량이 뛰어나고 성실한 관리자라고 해도 타인의 이야기에 공감할 줄 모르면 팀원에게 고통을 준다. 
• 8개의 항목 중에서 이게 제일 중요하다. 
• 팀원의 입장과 처지를 자기 것처럼 이해하고, 고민하고, 아파하고, 억울해하고, 분노하고, 노력하고, 기뻐하는 것. 관리자가 가져야 하는 덕목 중에서 제일 중요한 것은 공감능력이다. 
• 이게 핵심이며 여기에 비하면 다른 능력은 모두 부차적이다.

• 팀원들이 경력을 키워나가도록 도움을 준다.
• 팀원들이 관심있는 분야에 업무를 할당하면 생산성은 극대화 될 것이다.

• 팀을 위한 명확한 비전을 가지고 있다.
  
• 팀에 자아를 만들어야 한다. 

• 팀에게 조언을 해주기에 충분한 기술적인 능력을 갖추고 있다.
  
• 명확한 비전과 기술적 능력은 관리자 자신의 역량 문제다. 
• 있으면 좋고, 없으면 아쉽지만 그렇다고 해서 관리자로서의 결정적인 결격사유는 아니다. 
• 비전은 더 위에 있는 디렉터나 CTO에게 빌릴 수 있고, 기술적 능력이 부족하면 팀원들에게 빌릴 수 있기 때문이다.