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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이것도 se66.com의 내가 펏던 글을 재펌한 글.
기억하고 싶은 글이다.


한때 나도 업무욕심이 많았던 적이 있다. 업무욕심이 많은 것은 좋은 것이며 회사를 위해서도 바람직한 자세이다.
그래서 호시탐탐 남의업무를 어깨넘어로 배워 "언젠가 저 업무를 내가 해야지" 그런 생각을 했던적도 있었다.

회사에서 담당업무가 적다는 것은 일반적으로 구조조정시 또는 연말 인사고과에서 불리하게 평가될수 있는 단초를 제공할수 있는것이 사실이다. 그러나, 지금 담당하고 있는 일이 너무 익숙한 일이라면, 그리고 나의업무를 동료 또는 후배가 원한다면 될수있는데로 그 업무를 넘겨주는것도 괜찮다고 생각한다.

그리고, 새로운 생산적이고 회사를 위해 더 가치있는 일을 찾는 것이 바람직하다.

요즘은 회사에서 살아남기 위해 무턱대고 일만 많이 하는것 보다는 회사발전에 더 기여를 할수있는 생산적이고 또는 수익을 향상시킬수 있는 일들을 스스로 만들어 수행하는 것이 회사에 오래 근무할수 있는 길이라고 생각한다.

만일, 지금 근무하는 회사가 그러한 노력을  긍정적으로 평가하지 못한다면 당신의 회사는 분명 당신의 앞날을 보장해 주는 회사는 아니라고 생각한다.

나는 지금껏 살아오면서 인생의 스승이 두명있다.

한사람은 나의 큰형님이고, 또 한사람은 내가 두번째 근무를 했던 회사의 사수였다. 그 사수는 지금  외국인회사의 한국지사에서 아주 잘나가는 사람이다.

내가 두번째 회사로 옮겼을때 나의 직급은 이미 대리말년이었는데  회사에서는 사수를 정해주었다. 옮긴회사의 업무를 좀더 빨리 파악하라는 의미와  빠른 시간내에 옮긴회사에 적응하게 하기위한 배려가 아니었나 싶다.

그런데 이 사수란 사람은 좀 희한한 능력이 있는 사람이었다.

당시 그 사수는 이미 전산분야에서 10년가까이 업무경험이 있었고, 당시 국내에서 기업의 전산실중 크기로 치면 다섯손가락 안에 드는 잘 알려진 회사에서 DBA로 근무를 하다가 옮겨온 사람이었는데 솔직히 시스템운영이나 프로그램쪽은  그다지 능력이 뛰어나지 못해서 나와 같이 팀이되어 일을 할때 그런 실무적인 일들은 거의 내가 도맡아서 수행을 했던 기억이 있다.

그런데 그 선배는 프로젝트를 기획하고 수행하는 능력이라든가 업체들을 불러들여 새로운 일을 도모하는데 있어서는 매우 뛰어난 능력을 보유하고 있었다.

프로젝트를 수행하다보면 여러기업의 수많은 사람들이 모여 같은 하나의 결과물을 만들기위해 작업을 하는 것이기때문에 늘~ 잡소리가 나오게 되어있고, 참여기업간 또는 주최기업과 수행기업간 미묘한 문제들로 크고작은 다툼이 있게 되어있다.
그런데 그 선배는 프로젝트를 하면서 그러한 미묘한 문제를 매우 현명하고 조용하게 해결해 참여기업들의 불만을 최소화시키고 결과물을 극대화시키는 비상한 능력의 소유자 였다.

그 선배는 늘 내게,  다른 직원들이  나의 업무를 탐내어, 넘겨달라고 하면 무조건 넘겨 주라고 하였다. 그렇게하면 지금 내가 담당하고 있는 일을 모두 빼앗길 것처럼 보이지만 절대 그렇지 않으며, 결국은 시간소모적인 일들은 대부분 털어주고 부가가치가 높은 업무들을 주로 담당하게 된다는 것이었다.

그 선배와 같이 근무했던 몇년간 나는 정말 많은 것을 배웠었다. 그 선배로부터 내가 배운 것들은 주로 내가 전혀 생각하지 못하고 있거나 전혀 경험이 없는 노하우 들이었는데 내가 지금까지 살아오면서 두고두고 나의 생각과 판단에 적지않은 영향을 주고 있다.

누구나 마찮가지 겠지만, 회사에서 여러사람이 근무를 하다보면, 같이 근무를 하는 동료중에는 나와 잘 맞지않는 사람이 한두명은 꼭 있다.
나도 역시 마찮가지 였으며, 그 중 한사람은 업무적으로 나와 직접적으로 관계가 많은 사람이었다. 그리고 한때는 그 사람이 빨리 회사에서 그만두거나 또는 타부서로 옮겨가기를 은근히 바랬던 적이 있다.

그런데, 나중에 내가 중간관리자가 되고 조금씩 더 중요한 위치에서 일을 하게 되면서 같은 직장에서 동료들간에 있을수있는 알력과 살아남기위한 경쟁에 대한 나의 생각이 잘못되었다고 생각하게 되었다.
(많이 이기주의적인 생각이긴 한데...)
왜냐하면 만일 그 동료가 어떤일로 갑자기 회사를 그만두게되면 그 동료가 수행하던 덜 중요한 일들을 어쩌면 내가 떠맡아야 할 수도 있을것 같았고, 그렇게되면 더 가치있고 생산적인 일을 할수있는 여력이 없을것 같아서 였다.(나보다 더 능력이 뛰어난 직원이었다면 생각이 다를수도 있었겠지만..하여간 그건 중요한 것이 아니고..)

IMF를 치뤄내면서 우리나라 기업들의 분위기도 많이 바뀌었다. 이제는 한쪽구석에서 있는듯 없는듯 그렇게 티가 나지않게 중간이나 가겠다는 식으로 근무를 하다가는 오랫동안 버티기가 힘들다. 어느회사든 나이가 들고 직급이 올라갈수록 회사의 매출증대에 점차 참여요구가 커지며, 당연히 그렇게 해야한다.

누구나 할수있고 시간 소모적인 일은 나이가 많고 연봉이나 많이 축내는 직원들이 마냥 꿰고앉아 있을수 없으며, 혹시 아직도 그런 회사가 있다면, 그리서 그러한 점들이 불만스럽다면 크게 걱정할 바가 못된다. 어느회사든 그런 상태로 버텨나갈수 있는 회사는 이제 없으며 그런 직원들은 머지않아 회사를 떠나야 할 것이다.

주변의 직원들이 나의 업무를 탐낸다면 주어라.

만일, 내가 넘겨주는 업무가 회사에 있어 중요한 일이고 내가 다른 직원에게 업무를 넘겨주더라도 별문제가 없다면 회사는 그만큼 인재가 많다는 얘기이기 때문에 분명 회사는 안정적인 수익구조를 갖고있고 그만큼 경쟁력이 있다는  의미가 된다. 또는 그렇지는 않더라도 최소한 나는 더 생산적이고 가치있는 업무를 개발할수 있는 여력이 생기는 것이니까 결코 나에게도 그렇고 회사에도 좋은 것이다.

가장 문제가 되는 오히려 직원들이 서로 일을 하지 않으려고 미루는 회사다.

가장 문제가 되는 회사의 분위기는 직원들이 업무에대한 욕심은 별로 없으면서 자기업무를 절대 남에게 오픈하지 않으려고 꽉 쥐고 있는 경우이다.

그런 직원들의 대부분은 그렇게 해야 회사에서 해고되지 않고 잘 버틸수 있다고 생각하기 때문인데 그것은 정말 어리석은 생각이다.

왜냐하면 그런 직원들이 많은 회사는 이미 경쟁력이 없거나 머지않아 기업경쟁력이 떨어져 오래 장수할수 있는 회사가 아닐것이기 때문이다.

Ref: http://www.ibmmania.com/zb40/zboard.php?id=ibmboard2&no=50219

이것도 se66.com의 내가 펏던 글을 재펌한 글.
기억하고 싶은 글이다.



다른회사들은 어땠는지 모르겠지만 어찌되었든 IT기업이 아닌 회사의 전산실에 오랬동안 근무한적이 있는 제가 당시 느꼈던 불만중의 하나가 바로 전산부서는 비용발생부서라는 오명입니다.

다시말해서, 전산부서는 비용만 발생하고 수익을 내지 못하는 부서라는 인식입니다.

이러한 어의없는 인식으로 인하여 전산부서가 최첨단 기술부서니 뭐니 하지만 실제로는 전혀 대우를 받지 못하는 지원부서로 회사에서는 분류가 되어 있으며, 이는 중간관리자를 거쳐 고위층으로 승진하는데 있어서도 상당한 부담이 되는 요소가 된다는 거죠.

그중에서도 시스템관리부서는 가장 비용이 많이 발생하고,  업무는 밤낮 구분없이 하면서도 업무양에 비하여 대우를 받지못하는 부서 였었습니다.

프로젝트를 하고나면 쫑파티를 하는데도 잘 불러주지도 않고, 프로젝트 성과에대한 포상을 하여도 늘 시스템부서는 뒷전이었습니다.

그 뿐입니까.

시스템은 가만~히 놔두면 다운되지 않는 것으로 인식을 하여,  시스템관리를 잘해서 다운되지 않으면 본전이고, 어쩌다가 시스템이 다운되면  업무태만정도로 생각하여 추궁을 당하거나 시말서를 쓰는 것이 보통이었습니다.

이런 문제는 왜 발생할까요.

왜 전산부서는 비용이 발생만 하고, 수익은 없는 부서로 인식되어 있는 것일까요.

이것은 어찌보면 연말결산시 전산관련부서장들의 목소리가 적어 경영진을 설득시키지 못한 이유도 있고, 마켓팅이나 영업부서들이 자기부서들의 실적을 많이 올리려고 비용은 대충 감추고 매출만 나타내려는 욕심이 그 이유중의 하나 입니다.

오히려 자리에 가만이 않아, 관리만 하는 총무인사 또는 재경부서등 관리부서를 보면  비용은 잡비정도이고 수익은 수익부서의 수익을 인원비율로  나누어가져 최소한 적자는 면하는데, 전산부서는 도입되는 모든 시스템들은 전산부서의 비용이고, 매출은 하나도 없는 이상한 계산법이 연말이면 도입됩니다.

웃긴얘기죠.

전산부서는 따지고 보면 엄청난 이윤을 가져다주는 부서입니다.

만일, 전산화가 않되었다는 가정하에서 소요되는 비용을 따져본다면 업무전산화로 인한 회사의 비용절감은 어마어마 한 것이죠. 그것이 사실은 모조리 전산부서의 수익으로 계산될수도 있는 것입니다.

더 정확하게 따지려면 전산부서의 시스템 및 프로그램들의 비용은 현업에서 그러한 시스템 및 프로그램을 사용하여 업무의 효율성을 높이는 부서들이 나누어 부담해야 하며, 잔산부서의 비용은 순수 시스템관리 시스템 또는 관리 소프트웨어 비용이며, 수익은 현업부서의 인력지원 인건비로 계산되어 오히려 지원을 받는 부서에서는 전산부서 인원만큼의 비용이 발생해야 하는 것입니다.

그렇게 되면 전산부서는 최소한 적자는 아니거나, 경우에 따라서는 어마어마한 수익을 올리는 부서로 탈바꿈 하는 것입니다.

그러나 아쉽게도 이러한 인식이 되어있지 않는 경우가 왕왕 있습니다.

이제는 이러한 부분을 분명히 社측에 인식시킬 필요가 있습니다.

전산부서는 비용발생부서가 아니라 수익창출부서이다.

Ref: http://www.ibmmania.com/zb40/zboard.php?id=ibmboard2&no=50181