관리자의 자격

좋은 관리자 vs 나쁜 관리자 (지디넷코리아=임백준 IT칼럼니스트)2002년 무렵 구글에는 관리자가 없었다. 당시의 구글은 개발자에 의한, 개발자를 위한, 개발자의 회사였다. 그들은 철저히 개발자 중심 문화를 가지고 있었기 때문에 관리자가 필요없다고 생각했을 것이다. 코드를 생산하는 개발자 중심 문화에서 관리자는 잘하면 필요악, 그렇지 않으면 개발자에게 기생하는 부차적 존재로 취급되었을 것이다. 개발자 중심의 문화는 구글만의 이야기가 아니다. 2002년에 국한되는 이야기도 아니다. 지금도 미국에서는 코딩 실력이 좋은 개발자가 관리자가 되기를 거부하거나 마음속으로 관리자의 업무를 불필요하게 생각하는 일이 드물지 않다. 지위가 올라가도 코드를 생산하지 않으면 부차적 존재라는 자괴심을 느낄 수밖에 없는 문화다. 그렇기 때문에 좋은 관리자들은 기술로부터 멀어지지 않기 위해서 부단한 노력을 기울인다. 최근 칼럼에서 언급한 개발자 무정부주의(developer anarchy)는 이런 개발자 중심 철학과 문화의 연장선에 놓여있다. 관리자의 필요성을 인정하지 않은 구글은 2008년에 한 걸음 더 나아가서 관리자 무용론을 실제로 증명하기 위한 연구를 진행했다. 그걸 증명까지 해야할까 싶지만, 아벨 아브람이 최근 인포큐에 기고한 글에 의하면 구글의 연구는 기대했던 것과 반대의 결론을 도출했다고 한다. 관리자가 쓸모없는 존재가 아니라 팀의 생산성을 담보하기 위한 중요한 요소라는 뜻밖의(!) 결과가 나온 것이다. [아벨 아브람 기고 원문 바로가기] 팀에 마이너스가 되는 엉터리 관리자가 많은 것은 사실이지만 팀의 생산성을 높이는데 결정적인 역할을 수행하는 좋은 관리자가 존재하는 것도 사실이다. 이것은 우리의 상식이나 경험에 비추어봐도 이해하기 어려운 일이 아니다. 그럼 팀에 도움이 되는 좋은 관리자는 어떤 사람인가? 구글의 연구팀은 좋은 관리자가 가져야 하는 8가지 덕목을 다음과 같이 정리했다. 1. 좋은 코치(coaches)다. 2. 팀에게 권한을 양도하며 마이크로매니지를 하지 않는다. 3. 팀원의 성공에 관심을 표명하며 개인적 삶에도 관심을 기울인다. 4. 생산적이며 결과를 중심으로 사고한다. 5. 훌륭한 커뮤니케이션 능력을 가지고 있다. 6. 팀원들이 경력을 키워나가도록 도움을 준다. 7. 팀을 위한 명확한 비전을 가지고 있다. 8. 팀에게 조언을 해주기에 충분한 기술적인 능력을 갖추고 있다. 좋은 코치는 스스로 뛰는 사람이 아니라, 선수가 원하는 포지션에서 마음껏 뛰게 해주는 사람이다. 기술 관리자(technical manager) 중에는 자신의 기술적 역량과 판단을 팀원의 것보다 우위에 놓고 시시콜콜하게 명령을 내리는 사람이 있다. 이런 태도는 다음 항목인 마이크로매니지와 연결된다. 팀원이 아니라 자신의 기술력에 의존하기 때문에 팀원을 스스로 생각하는 창의적인 개발자가 아니라 자신의 명령을 오차없이 수행하는 병사로 취급한다. 이런 관리자 아래에서 일하는 개발자가 건강한 동기부여를 가질 리 없다. ■ 진정한 개발자 세계에서 관리자는 '상관'이 아니다 사소한 부분을 일일이 간섭하고 통제하는 마이크로매니지는 관리자의 그릇과 연결된 문제다. 넷플릭스는 이걸 “통제(control)가 아니라 문맥(context)"이라고 표현했다. 좋은 관리자는 팀원을 통제하는 것이 아니라 팀원에게 필요한 일의 전후맥락을 설명한 후, 믿고 맡긴다. 사소한 통제에 집착하는 관리자는 문맥을 제시할 능력이 없기 때문에 그렇게 하는 것이며, 따라서 관리자로서의 역량이 부족한 것이다. 관리자의 마이크로매니지는 개발자의 생산성을 저해하는 치명적인 독이다. 팀원의 개인적 삶에 관심을 갖는 것은 관리자 자신의 취향과 스타일에 달려있는 문제다. 하지만 팀원의 성공에 관심을 갖는 것은 좋은 관리자가 갖춰야 하는 필수 덕목이다. 최근에 나는 회사에서 자신의 팀원과 '경쟁'하는 관리자를 발견하고 전후맥락을 살핀 다음 인사조치를 단행한 경험이 있다. 자기가 가진 권력적 우위를 이용해서 팀원의 아이디어를 자신의 아이디어로 둔갑시키는 관리자를 발견한 것이다. 이건 관리자가 가질 수 있는 모습 중에서 최악이다. 좋은 관리자는 팀원을 이용해서 자기를 돋보이게 만드는 것이 아니라 진심으로 팀원의 성공을 위해서 봉사해야 한다. 결과를 중심으로 사고하는 것도 반드시 필요하다. 개인적인 호불호, 지연이나 학연, 아부, 허황된 장담, 소문, 감정에 휘둘리는 관리자는 관리자로서의 자격이 없다. 누가 좋은 품질의 코드를 생산하는가, 얼마나 빠르고 정확하게 일을 마치는가, 어려운 문제를 해결하기 위한 좋은 아이디어를 제안하는가, 다른 사람과 잘 협업하는가, 스스로 할 일을 찾아서 적극적으로 행동하는가, 의사소통을 잘 해서 자기가 하는 일을 투명하게 만드는가. 이런 구체적인 결과만으로 판단을 해야한다. 출퇴근 시간, 휴가, 재택근무, 병가 같은 근태 역시 결과 중심의 사고에 영향을 주지 않아야 옳다. 관리자가 좋은 커뮤니케이션 능력을 가져야 한다는 것은 상식이다. 다만 여기에서 말하는 커뮤니케이션은 말을 뉴스앵커처럼 또박또박 유려하게 하라는 뜻이 아니다. 투명하고 솔직해야 한다는 뜻이다. 공감(empathy)하고 공명(resonance)해야 한다는 뜻이다. 아무리 역량이 뛰어나고 성실한 관리자라고 해도 타인의 이야기에 공감할 줄 모르면 팀원에게 고통을 준다. 공감. 8개의 항목 중에서 이게 제일 중요하다. 팀원의 입장과 처지를 자기 것처럼 이해하고, 고민하고, 아파하고, 억울해하고, 분노하고, 노력하고, 기뻐하는 것. 관리자가 가져야 하는 덕목 중에서 제일 중요한 것은 공감능력이다. 이게 핵심이며 여기에 비하면 다른 능력은 모두 부차적이다. 명확한 비전과 기술적 능력은 관리자 자신의 역량 문제다. 있으면 좋고, 없으면 아쉽지만 그렇다고 해서 관리자로서의 결정적인 결격사유는 아니다. 비전은 더 위에 있는 디렉터나 CTO에게 빌릴 수 있고, 기술적 능력이 부족하면 팀원들에게 빌릴 수 있기 때문이다(비전을 남에게 빌릴 수 없는 CTO나 임원급 간부는 면도날처럼 날카로운 비전을 스스로 가지고 있어야 한다. 이 주제는 나중에 다루겠다). 이상 구글 연구진의 발표내용을 중심으로 관리자의 자격을 살펴보았다. 불만을 품은 직원은 회사를 떠나는 것이 아니라 관리자를 떠난다는 말이 있다. 관리자의 역할이 그만큼 중요하다는 뜻이다. 진정한 개발자 세계에서 관리자는 '상관'이 아니다. 수행하는 일의 기능(function)이 서로 다를 뿐이다. 관리자는 개발자가 개발에 집중할 수 있도록 옆에서 봉사하는 사람이지 개발자를 상대로 명령하거나 독단적으로 판단하는 권력을 가진 사람이 아니다. 좋은 관리자는 이런 사실을 이미 잘 알고 있다. 행여 관리자라는 타이틀을 봉사가 아니라 권력으로 착각하는 사람이 있으면 이 글을 읽고 생각을 바꾸기 바란다. 관리자의 자격은 그 착각이 없는 사람으로 국한되기 때문이다.