Github 매니저가 밝히는 팀 운영 노하우, From Ryan Tomayko, Director of Engineering at Github

팀을 리딩하다보면 여러가지 고민을 할 때가 많습니다.
스케줄은 제대로 맞추고 있는지, 너무 팀원들을 쪼는 건 아닌지라는 생각도 들고요.

그러다 팀원들에게 널럴한 스케쥴을 잡아 주다보면 어느새
아웃풋이 별로 없기도 하여서 윗사람들에게 푸슁을 받기도하고요.

팀장의 가장 큰 고민 중에 하나가  끊임없이 일을 지시하고 확인해야하는 건데요,
이러한 고민들을 피하면서 조직을 성공적으로 잘 리딩하고 있는 Example이 가까이 있었습니다.
웹개발자시라면 익숙한 Github에서 이미  그런 매니징을 잘 시행하고 있네요.
GitHub의 Engineering파트 디렉터인 Ryan Tomayco, 라이언 토메이코가
팀 매니징에 대해서 그리 길지 않을 글을 썼는데요 신선한 충격이네요.
구글 느낌도 나고요.

원문은 여기서 읽으시면 되고요, 간단하게 요약해 봅니다.
http://tomayko.com/writings/management-style

사람들로하여금 무엇을 하라고 지시하지 말라

나는 절대로 사람들에게 무엇을 하라고 지시하지 않는다. 무엇을 하라고 지시하는 것을
아주아주 싫어한다. 이유는 이렇다.

1. 감당할 수가 없다. 만약 내가 각자 팀원에게 무엇을 하라고 지시한다면 그일이 끝날 경우에
나는 다른 일을 또 지시해야한다. 그렇다면 10명, 20명이 넘어가면 어쩔 것인가?

2. 팀원들에게 무엇을 하라고 하는 것은 게으른 짓이다. 대신 나는 논쟁을 통해서 확신을 준다.
이게 바로 인간이 강압적인 권위의 틀이 없을 때 일하는 방식이다. 그리고 이 방법은 정말 잘 통한다.
만약 사람들로 하여금 논쟁과 설득을 통해서 확신을 심어주지 못하면 그일을 할 필요가 없다.

그렇다면 내가 사람들에게 무엇을 하라고 지시하지 않는다면 나는 하루종일 무엇을 하고 있을까?

나는 사람들에게 어떻게 계획하는지, 어떻게 만들고,  어떻게 제품을 내놓지 보여준다. 

사실 나는 각자가 스스로를 매니징 하는 작은 팀장을 만드는 일을 한다.
처음에는 지금 해야할 일들을 이해시키고 우선 순위를 가르친다. 두번째로는 자율성을 길러주는데,
그들 스스로 그들과 그들 팀이 하는 일들이 옳다는 확신을 가지도록 자신감을 키워 준다.


가능한한 본을 보여주는 방식으로 리드하라

나는 실제로 사람들에게 어떤 결정을 하는 방법을 보여주지 않는다.
또한 제품을 내놓는 직접적인 방식들을 보여주지는 않는다.
제품을 출시하는 방법 이라는 교육 커리큘럼은 없다. 대신 난 그냥 일한다.

나는 아이디어를 적고, 내부적으로 그것을 내놓는다. 디자이너에게 컨셉작업을
요청하기도 하고, 문서와 테스트를 하며 코딩한다. 몇몇 기능들을 위해서 백앤드작업도
진행하고 필요하다면 만든 코드들을 날려버린다. 사이트의 안정화가 가장 큰 주제이기 때문에
책임있게 적용한다. 새로운 기능을 사이트에 얹어 보고 사원들로 하여금 그것을 이용해보게 한다.
그리고 리뷰와 블로그 포스트를 쓰고, 기능을 최종적으로 출시한다. 버그를 잡고,
지원을 계속한다.

이런 방식은 보통의 소프트웨어 개발자가 2012년도에 제품을 만들고 출시한 방식과 동일하다.

단지, 이 방식이 흥미롭고 그리고 뭔가 특징적인 것이 있다면  나는 꾸준히 이 전체 프로세스에
대해서 극히 보여지도록 작업을 한다.  다시말하면 속닥이는 대화나, 개인 미팅이나, 페이스타임이나
메신져나 1:1로 만나서 작업한다거나 이런 다른 어떤 사적이고 보이지 않는 방식들은
모두 제외 시키고 지극히 고의적으로 공개적으로 그리고 팀원들이 보여지게 작업한다.

단지 꾸준히 사람들로 하여금 오픈하도록 강조한다. 특별히 내가 매니징하고 있고 관심있게 지켜봐야할
사항에 대해서 그렇다. 왜냐하면 제품 사이클의 모든 단계단계에서 모든 사람들의 참여가 담겨져 있기 때문이다.
각자에 대해서는 스스로 매니징하게 하고, 다른 모든 사람들이 그것을 볼 수 있게 한다.
또한 다른 사람들이 무언가 실수가 있다면 뛰어들어 조정한다. 최종적으로 모든 팀원들은 어떠한 때 실수하고
또 어떤 때 무언가 대단한 것들이 나오는지 배우게 된다.

만약 “매니지먼트 스타일”이 어떤 손에 잡히는 무엇이라면,
나는 이런 오픈 방식 이야말로 그 기초석으로 잡을 것이다.


사람들로 하여금 헌신하게 하라

어떤 팀원이 Github 프로세스에 익숙하지 않다면 나는 의도적으로 그들을 이슈나, 코멘트 등에서
@mention한다. 그리하여 그들로 하여금 다른 프로젝트나 토론에 참여시킨다.
그들이 처음으로 아이디어나 어떤 의견이 있을 때에, 그것을 전환점으로 삼아서
오픈 소스 놀이책의 가장 오래된 트릭을 사용한다.

“패치는 어디있어?”

다시말해 머리속에 있는 것을 코딩하고 만들고, 그것들이 어떻게 그렇데 된 것인지
내게 말해주고, 나와 동료들에게 팔아 보라고 말한다.

나는 그들이 올린 코드를 pull하여서 리뷰한다. 그리고 그들이 어떻게 프로세스와 고객과
우리의 제품들을 인지하고 있는지 상상해 본다. 내가 생각하기에 그들이 틀리다면 고쳐주고,
제대로 가고 있다면 제대로 가고 있다고 이야기 해준다.


모든 사람들을 매니져로 만들어라

가끔씩 Github이 매니져가 없다는 소문을 듣는다. 내가 생각하기에 조금 더 나은 표현은
Github에서는 모든 사람이 매니져다 라는 것이다. 각 개인에게 100% 의무를 지워주는 것 대신에,
기본적인 매니징의 룰은 첫째로 모든 직원들과 둘째로는 그 개개인의 직원들이 담당하고 있는 업무들을
다른 프로젝트들과 마찬가지로 서로 공개하고 공유하고 알 수 있는 자체 개발된 툴들을 전파하는
것이다.

이러한 매니징의 접근 법은 실제적인 이익이 있다. 관리 감독이 없이 효율적이고,
최고의 성과를 낼 수 있도록 해주는 100% 직원을 생각해보라.

일이 되기 위한 유일하고 진정한 필요 조건은 단지 냉철하고 진지해지는 것이다.

100%의 직원이 모두 제품의 Cycle을 완전히 이해하고 있는 조직을 상상해보라.
각각의 지점에서 결정적인 의사 결정들을 내릴 수 있는 조직 말이다.

100%의 직원이 모두 Decision Maker가 되는 조직을 상상해보라.

이것이 현재 우리 조직이 나아가고 있는 방향이자 목표다.

휴가를 취하라

오늘 나는 열흘간의 가족들과 휴가를 마치고 일터로 복귀했다. 이것이 3년전에 내가 Github에 합류하고
난 다음 가지는 최초의 장기 휴가이다.

내가 프로젝트들이 제대로 진행되고 있는지 체크하기 위해서 휴가 동안 몇개의 미팅을 열었을까 생각해보라.
사실 미팅은 하나도 없었다.

내가 휴가를 떠나기 전에 공백기간을 잘 처리해달라는 메일을 보냈는데 한장의 답신을 받았다.

Github은 그 주동안 최근 들어 최고의 생산성을 보여줬다. 나는 편안하게 해변에서 휴식을 취했다.

내가 발견한 단 한가지 단점은 내가 지극히도 필요 없다는 것이다. 휴가나 더 즐겨야 할까보다.