번역사지원 > 번역사등록
 
CIO는 왜 마이크로매니저가 될까?
관리자
작성일 : 16-05-19 15:58  조회 : 19,124회 

일반적으로 CIO는 IT에서 경력을 쌓으며 입지를 다져온 사람이다. 하지만 이러한 전문성 때문에 마이크로매니저가 되기도 한다.  

헬리콥터.jpg

 

헬리콥터 부모라는 말이 있다. 자녀들의 일상사 모두에 관여하면서 자유롭고 독립적인 공간을 주지 않는 부모들이다. 기업 세계에도 이와 유사한 '마이크로매니지먼트'라는 말이 있다.


일반적으로 CIO는 이러한 마이크로매니지먼트 문제를 겪지 않을 만큼 자신을 발전시키고 성장시킨다. 그러나 자신도 모르게 지나치게 깊이 파고드는 경향이 있다. 자신의 경력 출발에 원동력이 된 기술 등 애착을 갖는 문제들이 대표적이다.


필자도 예외는 아니다. 필자의 부하 디렉터 가운데 한 명이 SAP 기술에 대한 책임을 전담하고 있다. 필자가 경력을 시작해 20년 넘게 경험을 쌓은 분야다. 필자는 이 디렉터 때문에 '마이크로매니지먼트' 문제를 깨달았다. 그가 두 사람이 지식을 공유하는 것이 장점인 동시에 단점이라고 말을 했을 때다. 그는 SAP의 복잡성, SAP 시스템을 전세계에 구현, 배포, 운영할 때 직면하는 당면과제를 이해하는 CIO와 일한 경험이 없었다고 설명했다. 두 사람이 지식을 공유하면 대화와 의사결정이 더 쉬워진다. 그러나 필자 의견이 디렉터에게 스스로, 또는 (더 중요하게) 상사의 생각이나 방향 제시에 의문을 갖게 만드는 때가 있다. 이는 힘든 상황이다.


CIO들이 이렇게 깊이 몰두하게 되는 이유는 뭘까?


만족감을 느낀다!
CIO는 전략(어쩌면 정확한 의미가 모호한 디지털화 전략 등), 재무(예산 삭감 등), HR 등 복잡한 업무로 대부분 시간을 보낸다. 그러다 보니, 때때로 한 명의 개인으로 '단순한' 기술 업무로 돌아가 기여할 때 큰 만족감을 느낀다. 실제 최근 며칠 동안 공급망 문제 해결을 도와주기 위해 SAP에 '로그인'을 하고 있다. 그러나 리더는 개인으로 기여하는 사람이 아니며, 리더의 의견이 다른 사람들을 앞선다. 소속 팀은 그 '질'과 상관없이 리더의 충고를 따르게 된다.


결과에 대한 두려움과 걱정
 현실을 직면하자. IT는 장밋빛만 가득한 세상이 아니다. CIO가 내리는 모든 결정과 프로젝트에는 위험과 보상이 모두 존재한다. 리더인 CIO는 비용과 가용 자원, 고객의 인식 등 수 많은 일에 초점을 맞추고 있어야 한다. 위험을 평가하는 것이 여러 세부 사항들을 단계별로 '비판'하는 고통스러운 과정이 되기도 한다(실패 시 영향 분석 등). 때론 팀을 보호해야 하고, 스스로와 팀을 위해 단 하나도 놓치는 부분이 없도록 빈틈없이 해야 한다. 그렇다면 경험을 바탕으로 도움을 제공하는 것과 마이크로매니지먼트의 경계선은 어디가 되어야 할까?


과잉 보상
 기술과 프로세스에 대한 인식을 재조정하거나 재정립해야 하는 '악몽' 같은 프로젝트들이 있다. 이런 프로젝트에 직면할 때마다, 우리는 '불에 우유를 부으면 끓어 넘쳐 폭발할까?'라는 식으로 접근한다.


동료들로부터 받는 압박감
 동료 경영진은 CIO가 수백 프로젝트와 전략의 모든 면을 꿰고 있기를 기대한다. 왜 이런 기대를 하는지 모르겠다. CFO는 한국의 자산 회계 관리의 모든 복잡한 세부 사항을 알고 있어야 하나? 공급망 담당 VP는 동유럽 공장의 제품 운송에 사용하는 LTL트럭의 제조사와 모델을 알고 있어야 하나? 우리는 이런 것들을 속속들이 알아야 한다는 기대를 받는다. 이 때문에 마이크로매니지먼트에 빠져든다.


CIO가 마이크로매니지먼트의 '열열한 지지자'이 되는 이유에 대한 변명은 무수히 많다(필자의 변명도 포함해). 그런데 우리는 이런 행동이 초래할 결과를 생각해야 한다. 짧아야 할 프로젝트 검토가 길어지고 지나치게 상세해지면 팀의 생산성에 큰 피해를 준다. 몇 시간 동안의 회의, 최악에는 며칠 동안 파워포인트 슬라이드를 가지고 씨름하는 문제가 생기기 때문이다. 중요하지 않은 세부 사항을 놓고 매일 대화를 갖는 것은 더 큰 방해가 된다. 당장 내어놓을 답이 없을 때를 중심으로, 팀원들에게 아주 많은 스트레스를 준다. 또 책임자의 리더십을 해치고, (상사에게 아이디어를 알려줘야 하므로) 혁신이나 문제 해결 역량을 저해한다. 리더는 프로젝트 추진을 자제하고 책임을 줄이면서 '안전장치' 역할을 해야 한다. 이후 (성장을 찾는 사람은) 떠나고, 그렇지 않을 경우 남게 된다.


다른 많은 일들처럼, 가장 먼저 할 일은 자기 자신에게 문제가 있다는 사실을 인정하고 이를 극복할 방법을 찾는 것이다. 필자는 처음 리더가 된 이후 '헬리콥터' 같은 행동을 피할 방법을 찾아 시도했다.


• 팀에 기대하는 사항을 정확히 해야 한다. 목표와 시기, 방법을 규정해야 한다.


• 필자가 깨달은 교훈이 있다. 필자는 팀에 내 조언을 말해준다. 그러나 조언에 불과하다고 설명한다. 특정한 방식을 원하면, 이를 분명하게 설명한다.


• 동료들이 세부적인 내용을 질문할 경우, "나는 잘 모르니, 내 팀의 XYZ에게 물어보라"고 말한다. 자신이 모든 것을 알지 못한다는 점을 깨닫고 인정하는 것이 중요하다.


• 필자는 내 리더에게 정기적으로 피드백을 구하고, 이들에게 내가 방해되지 않는지 솔직히 말해 달라고 부탁한다.


• 필자는 '입을 닫을 수 없는' 사안에 대한 기술적인 검토, 상세한 워크숍 및 프로세스 매핑을 기피한다. 그리고 팀이 합의한 결과를 기다린다.


CIO의 첫 번째 역할은 리더가 되는 것이다. 따르는 사람이 있어야 리더가 될 수 있다. 사람들을 따르도록 만드는 방법 중 하나는 리더가 '이방인'이 아님을 입증하는 것이다. 옷소매를 걷어붙이고 기술적인 사항에 관여하면서 도움을 주는 것은 (특히 아주 중요한 상황에서)사람들에게 자신의 '출신'과 동질감을 알려줄 방법이다. 그러나 올바른 상황과 시기에 그렇게 해야 한다.


우리는 행동을 바꿔야 한다. 팀이 성공할 수 있도록 관리하고, '코칭'하면서 성장해야 한다. 상세한 사안에 대한 우리의 필요성을 조정하는 것이 중요하다. (기술적 인풋을 강요하는)'푸시 공급망' 모델에서 필요할 때 팀이 지원을 요청하는 풀/칸반(Kanban) 모델로 바꿔야 한다.


*Francois Estellon은 미국 펜실배니아에 거주하는 기술 리더로, 종종 IoT, 변화 주도, 기업 통합, ERP 등에 관해 기고문을 쓰고 강연하고 있다. ciokr@idg.co.kr

 

[출처][2016년 5월 18일 CIO KOREA.COM 게시글을 인용]

 Read more:  http://www.ciokorea.com/news/29695?page=0,1#csidx6407e12d381d0a7a777d90cb5bd9d26
Copyright © LinkBack