경쟁을 부추켜서 조직의 성과를 얻으려는 관리자는 아무런 노력도 하지 않고 결과만 날로 먹으려는 것과 같다. 아무 고민없이 할 수 있는 제일 쉬운 방법이니까.
조직원들에게 동기부여를 줄지, 조직의 협동심을 아떻게하면 높일 수 있을 지 고민할 필요가 없이 결과만 취하면 되니까. 그런 관리자는 조직에 해를 끼치는 존재다.
할 수 있는 게 없는 건지,해도 안되는 건지. 여러가지 방법을 써도 안된다면 조직원과 함께 고민하면 안될까. 함께 속해 있는 ‘조직’의 성과를 위한 거니까
@유정식의 ‘착각하는 CEO’를 읽는 중 프랑스/베트남/쥐 박멸/쥐 사육 부분을 읽고
일단 책 제목부터 구박.
“People Analytics: How social technology will transform business and what it tells us about the future of work"인데 이게 왜 저런 한글 제목이 된건지. 책 내용을 보면 짐작은 가지만, 책 제목만 봐서는 구글이 빅데이터를 이용해서 어떤 서비스를 만들어냈는지 라고 해석할 수 있지 않을까? 실제로는 구글등의 회사에서 빅데이터를 이용해 직원들 관리에 어떻게 활용했는지에 대한 내용이다. 그리고 실제 구글 이야기는 많이 나오지도 않는다.
하지만 책 내용에는 저자가 강조하는 몇 가지 핵심 내용이 있다.
출처 : 관리의 기본 (Fundamental of management) #2 - 관리자/리더에게 필요한 역량
가장 중요한 것은 Communication 역량으로, 팀내 또는 팀간의 조율을 위해서는 반드시 필요한 능력이라고 생각한다. 두말할 필요가 없는 부분인데, 효과적인 커뮤니케이션 스킬을 가지기 위해서는 상호 존중이 바탕이 되어야 한다. 존중의 바탕이 없이는 명령이되고, 명령은 팀을 Push하는 모델을 만들지, 팀이 스스로 높은 성과를 낼 수 있도록 Pull (당기는 형태)의 리더쉽을 만들어내기는 어렵다.
관리자로써 전체적인 계획을 만들고 이를 실행하려면, 팀원들을 코칭할 필요가 있다.
그냥 누구나 생각하는 바람직한 방법과 목표 그리고 절차를 따라야 한다는 게 고작 결론인가? 그런 누구나 할 수 있는 이야기잖아. 저런 이야기를 돈을 내고 들어야 한다는 건가? 이해가 안된다.
현재 불편한, 잘못된, 쓸데없는 일을 하게 만드는 절차를 감당해야 하는 사람들에게 솔직한 의견을 구하는 것이 더 나은 방법 아닐까?
아무리 다른 곳의 일하는 체계나 조직을 분석해도 소용없다. 그 비교자료에는 없는 내용이 핵심이니까. 조직을 운영하는 사람들의 능력과 그 조직을 구성하는 사람들의 능력. 그리고 생각들.
(예를 들어) 분명 물리적으로 10개월이 필요한 일이 있다. 일정이 급하다고 6개월내 해 내라고 한다. 열심히 하지만 결국 6개월 기한은 넘어가고 겨우겨우 (담당자들이 개고생해서) 8개월 혹은 9개월내 일을 마친다.
그리곤 말한다. (6개월을 요구했던 이들은) 처음에 6개월을 여구했으니까 8개월내 해낸거라고. 처음부터 10개월을 이야기했으면 못했을 거라고.
하지만 경험상 저런 경우 8개월내 끝나기 보다 12개월이 걸리는 경우가 많다. 무리한 일정은 부실한 설계와 엉성한 구현을 만들어내고 버그로 인한 재작업을 유도한다. 이때 책임은 누가 져야 할까?
스스로 잘한다고 공공연하게 말하는 친구의 말은 믿을 수가 없다. 자기가 잘하는 단 하나만 생각해서 잘한다고 말하지만, 그게 SW 개발자가 가져야 할 모든 건 아닌데. 그것도 깨닫지 못하는 걸 보면 잘한다고 자만하는 건 스스로의 착각.
남들의 인정을 받는 지 의문.
혹은 남들이 자신과 함께 일하고 싶어 하는 지 한번이라도 생각해 봤으면.
또 저런 친구들의 착각은 남들이 자기랑 함께 일하기 싫어하는 이유를 자신이 너무 잘나서 라고 생각한다는…
대부분의 개발자는 현업에서 선배 개발자들이 작성한 코드를 유지보수하면서 코드 작성 방법을 배우게 됩니다. 회사에 따라 다르긴 하겠지만, 이렇게 접한 대부분의 코드는 겨우 겨우 동작만 하지, 코드의 가독성이나 유지보수를 거의 생각하지 않고 작성된 코드일 확률이 높습니다. 이런 코드를 읽고, 어떻게든 돌아가게 수정하는 훈련만 하다 보면 애시당초 코드를 잘 짠다는 게 무엇인지 알기가 어렵게 됩니다.
출처 : http://wp.me/p66O1q-3j
평소 내가 가진 생각과 비슷하다. 코드는 작성하는 게 1이면 읽는 게 9라고 한다. 그 만큼 기계가 아닌 사람이 읽는 것의 대상이 되는 경우가 많으므로 읽는 작업에 도움이 되도록 coding style의 정리가 반드시 필요하다고 생각한다.
우선 할 것은 모든 과제의 진행상황을 투명하게 볼 수 있는 시스템만들기 엑셀로 관리하고 있는 정보에 대해 최적의 대안을 찾아 엑셀 사용을 최소화 하기 파일 서버에 단순히 모으고 있는 자료를 DB화. 적어도 하나의 과제에 관련된 문서를 한눈에 볼 수 있게 하고, 검색이 가능하도록 변경 File based DB 시스템 대체 방안. 필요하다면 기존 요구사항만 기존 담당자들로부터 받고, 새로운 생각을 가진 사람들에게 대안을 제안하도록 Code Coverage 100% 같은 비효율적인 업무 없애기 Inventory 정보 투명화.
그러나 생각하기 위한 시간을 내는 것으로는 부족해 보인다. 자신의 믿음에 부합되는 정보만을 찾는 편향이 인간에게는 있다고 했다. 혼자 생각한다고 그런 편향에서 벗어날 수 있을 것 같지는 않다.
▶그렇다. 아파트 가격이 오를 것이라고 믿으면 그에 부합되는 증거만을 보려고 한다. 반대되는 증거는 보려 하지 않는다. 그렇기 때문에 우리는 우리 곁에 ‘최고 이의 제기자(chief challenger officer)‘를 둬야 한다. 내 의견에 이의를 제기하는 사람 말이다. 리더일수록 더욱 그래야 한다.
에릭 슈밋 구글 회장의 회의 진행 방식도 좋다.