[지디넷코리아]훌륭한 관리를 한번도 받아보지 못한 사람이 훌륭한 관리자가 될 수 있을까? 글쎄, 아마도 훌륭한 관리자가 되기는 어려울 것이다. 마치 어린 시절에 사랑을 받고 자라지 못한 사람이 성인이 되어서 제대로 사랑을 하기 힘든 것처럼.

그것은 심리학을 통해 검증된 통계적 사실이다. 왜 그럴까? 아는 것이 그것 밖에는 없기 때문이다. 맞아본 사람이 때릴 줄 안다. 학대를 받아본 사람이 학대할 줄 안다. 간혹 예외가 있을 뿐이다.

안타까운 사실은, 조직 생활에서도 이와 같은 원리가 그대로 적용된다는 사실이다. 관리 업무는 눈에 잘 보이지 않는다. 좋은 관리, 나쁜 관리는 그 행위 자체보다는 결과로서 판단된다. 또한 관리 활동의 대부분은 소프트 스킬에 속하므로, 학습에 의해 습득 가능한 하드 스킬과는 달리 역량을 키우는 것이 쉽지 않다.

그런데 현실을 보면, 조직(회사)은 아무 준비도 없이 기술자를 관리자로 만들어 버린다. 좋은 관리를 받아본 적이 없고, 그렇다고 해서 딱히 관리 교육을 받은 적도 없는데(물론 교육을 받더라도 효과가 별로 없지만), 어느 날 갑자기 조직은 팀 또는 프로젝트 관리를 기술자에게 맡겨 버린다.

■기술자와 기술관리자는 다르다

기술자와 기술관리자는 다르다. 기술관리자는 기술이 아니라 사람을 다룬다. 그래서 기술자 시절에 PC를 붙잡고 씨름하던 것과는 완전히 다른 관점과 방식과 필요하다. 하지만 좋은 관리를 받아 본 적이 없고 더군다나 준비도 안된 상태에서 좋은 관리자가 되는 것은 거의 불가능하다. 어쩔 줄 몰라 하다가, 자기가 정말 닮고 싶지 않았던 그런 관리자와 유사한 행동을 반복하게 된다.

한때 기술자였으나 실패한 관리자의 사례를 하나 살펴보자. 실제 사례를 바탕으로 재구성해 보았다.

개발자 K는 뛰어난 개발자였다. 그는 개발 능력이 뛰어났기에 조직에서 인정을 받고 있었다. 대개의 조직은 일정 경력을 갖춘 우수한 개발자에게 관리자를 맡기고 싶어한다. 그 뛰어난 능력을 단지 개발에만 쏟지 말고 여러 개발자들을 관리하는데 써달라는 것이다.

결국 개발자 K는 조직의 갑작스런 필요에 의해 관리자 역할을 맡게 되었다. 하지만 그는 관리를 잘 하지 못했다. 아니, 잘하지 못한 정도가 아니라 처참할 정도로 못했다. 그가 맡은 프로젝트의 팀원들이 급기야는 (K의 관리를 더 이상 받을 수 없다고) 상층부에 집단으로 항의를 함으로써 그는 결국 해고되고 말았다. 개발자에서 관리자가 된 K는 도대체 어떤 관리를 행한 것일까?

그는 부적절한 인력 배치를 했을 뿐만 아니라, 팀원들에게 업무를 맡긴 후 결과가 나올 때까지 기다려주는 인내심이 없었다. 매일매일 점검(을 빙자한 간섭)을 했으며, 자신이 잘 알고 있는 미시적인 내용(하지만 별로 중요하지 않은 것)에 대해 팀원과 불필요한 논쟁을 하기도 했다.

업무 지시를 명확하게 하지 않았으면서도 업무 성과가 마음에 안 든다며 팀원들을 질책하기도 했고, 기술이 부족한 팀원에게 일을 맡기면서도 해당 기술을 습득할 수 있는 여건을 마련해 주지 않았다. 팀장으로서 팀원들의 고과를 매겨야 하는 상황에서는, 제대로 상담조차 하지 않은 상태에서 고과를 확정시켜 팀원들의 분노를 유발하기도 했다.

그가 맡은 프로젝트는 말도 안 되는 데드라인에 맞추어야 하는 일명 죽음의행진(Death March) 프로젝트였는데, 팀원들에게 야근이나 휴일 근무를 은근히 종용하곤 했다. 또한 자잘한 코딩 기법이나 검증되지 않은 새로운 방법론에 몰두한 나머지, 자신이 보기에 미진하게 생각되는(하지만 사실은 대세에 전혀 영향을 미치지 않는) 사소한 일들을 혼자서 모두 처리하려고 했다.

그리고 그는 회사 돈이 아닌 개인 돈으로 밥 한번 산 적이 없었다. 인간적인 매력조차 보이지 못한 것이다. 하지만 그가 개발자였을 때는 그렇지 않았다. 관리의 스트레스가 그를 더욱 메마른 인간으로 만든 것이다.

그러한 결과로 팀원들은 그를 단지 직위를 가진 사람으로 인정할 뿐, 리더나 코치로 인정하지 않았다. 결국 그는 팀 전체를 궤멸 상태에 빠지게 만들었다. 동기부여가 없는 지속적인 초과근무를 통해서 팀 전체가 모든 에너지를 소모하고, 결국 일에 대한 의욕을 완전히 상실하게 되었으며, 따라서 프로젝트 목표를 달성할 가능성이 희박해졌다. 마침내, 참다 못한 팀원들이 궐기했고 K는 해고되고 만 것이다.

실제로 현업에서는, 그런 식으로 알게 모르게 해고되는 관리자들이 참 많다. 무엇이 잘못된 것일까?

일단 표면적으로는 올바른 관리를 행하지 못한 K에게 책임이 있다고 할 것이다. 하지만 본질적으로는 K를 관리자로 선임한 조직에게도 상당한 책임이 있다고 볼 수 있다.

유능한 개발자였던 K에게 그가 잘 수행할 수 없는 관리자 역할을 맡기고, 결국 그를 해고한 것은 바로 조직이다. 결국 조직도 K도 모두 큰 손실을 보았다. 만일 K가 개발자로 계속 남았더라면 어땠을까? 그는 계속, 조직에 필요한 유능한 개발자로서 일할 수 있었을 것이다.

기술자와 기술관리자 역할은 조직의 갑작스런 필요에 의해 무리하게 맡겨져서는 안되며, 개인의 성향과 자질에 맞추어 맡겨져야 한다. 또한 준비과정과 교육을 통해 단계적 시나리오에 따라 맡겨져야 한다. 기술자와 기술관리자를 구분하는 간단한 몇 가지 질문을 살펴보자.

- 기술자: 더 많은 기술적 작업과 도전을 다루기를 원하는가? 사람 문제보다 기술 문제를 해결하는데 더 많은 관심이 있고 실제로 마음이 편한가?

- 기술관리자: 사람들에게 코칭과 조언을 해주기를 좋아하는가? 업무를 지시하고 피드백을 주는 법을 배우고, 필요하다면 하기 힘든 대화도 기꺼이 나누겠는가?

한국의 많은 조직들은, 유능한 기술자에게 갑작스레 관리를 맡기는 경향이 있다. 물론 유능한 기술자였다가 나중에 더 유능한 관리자가 된 사람들도 있다. 중요한 점은, 각각의 사람에 맞는 적합한 역할을 부여하고 그의 역량을 최대한 이끌어 냄으로써 조직의 생산성 향상 및 개인의 발전을 가져오는 것이다.

특정 개인이 기술관리자 역할에 적합한지 아닌지, 조직 또는 개인 스스로 판단하기 어려운 경우가 종종 있다. 그럴 경우에는 관리자 업무의 적성 판단을 위한 허니문 기간을 갖는 것이 좋다. 초급관리자로서 적은 수의 팀원 관리를 맡고, 일정 기간 동안 기술 업무와 관리 업무를 병행하면서 해당 개인 스스로 자신의 적성을 파악하고, 조직은 관리 성과를 냉정하게 파악하는 것이다. 그 후 해당 개인의 커리어 패스를 결정하면 된다.

관리자를 잘 선임하는 것은 몹시 중요한 일이다. 많은 사람들이 관리의 이름을 빙자한 모욕의 느낌을 경험하곤 한다. 관리에 실패하면 엄청난 비용을 지불한다. 팀원들의 신뢰를 잃고, 결국 생산성의 추락을 경험하게 되고, 프로젝트 목표 달성은 불가능해 진다.

1년이라는 프로젝트 기간 동안 프로젝트매니저가 3번이나 해고된 프로젝트를 본 적이 있다. 그런 상황에서 사실 진짜로 해고되어야 할 사람은 프로젝트매니저를 선임한 경영진이 아닐까?

매니지먼트의 핵심은 재능을 배치하는 기술이다. 조직의 경영진은 기술자와 기술관리자의 차이를 명확히 인식하고, 적합한 적성과 자질을 가진 사람이 관리자로 선임될 수 있도록 최선을 다해야 한다. 적절한 관리자를 선임하는 것이야말로, 그 이후에 발생하는 어떤 문제 해결보다도 가장 효과적이고 본질적인 문제 해결책인 것이다. @