매니지먼트

최근 2주에 걸쳐 앤디 그로브의 하이아웃풋매니지먼트를 읽었다. 1983년에 초판이 쓰여졌다고 믿을 수 없을만큼 2020년에 관리자로서 고민하고 있는 부분들에 대해서도 많은 힌트를 얻을 수 있다. 몇가지 소개하고 싶지만 거의 모든 챕터에서 유의미한 부분들을 발견했기 때문에 그냥 전체를 한번 읽어볼 것을 권하고 싶다.

이 책이 아니더라도 최근 관리, 경영에 대한 책을 많이 읽고 있다. 매니지먼트에 대해 고민할 것들이 점차 늘어나기 때문이다. 현재 우리 회사는 재작년 10월 스무명이 안 되는 태스크포스 인원으로 시작하여 현재는 200명이 넘는 인원이 풀타임으로 근무하고 있는 꽤 규모있는 조직으로 성장했다. 그에 따라 나의 역할도 크게 달라져 왔고, 달라져야 함을 매 순간 느끼고 있다. 20명일때부터 200명인 지금까지 내 역할(CTO, 회사의 프로덕트 및 엔지니어링 리드)은 달라지지 않았지만 서비스와 팀의 빠른 성장과 그에 따른 과정마다 해야 하는 일들과 그 일들을 해결하는 방식은 달라져왔어야 했다.

제품을 만드는 사람(Maker)으로써의 내 일을 단순히 말하자면 고객이 선택하고 사용할 제품을 배달(delivery)하는 일이다. 제품이 아예 없었던 작년 5월까지는 우리 제품이 가져야 할 핵심 기능을 정의하고 그것을 실제로 구현하는 것이 가장 중요한 일이었다. 팀이 여섯명에서 열명 남짓 되었을 때는 초기 제품을 위한 서버를 띄우고, 서비스 운영에 필요한 운영툴을 만들기 위해 코딩하는 날이 가장 많았다. 서비스를 런칭한 작년 5월 이후는 O2O 서비스인 우리 제품이 낯선 환경인 베트남에서 실제 운영 상황에 얼마나 잘 들어 맞는지 살피고 맞지 않는 부분을 고치는 일, 이후에는 경쟁사 서비스에는 있지만 우리 서비스에는 없는, 사업적으로나 고객 중심으로 중요한 기능들을 빌드하는 일(Function gap을 메우는 일)을 주도했다. 프로젝트를 리드하고, 문제가 발견되면 해결책을 고안하거나 직접 찾고 고치는 일도 많았다. 그러다가 올해로 넘어오면서 프로덕트 팀에 주요한 변화를 적용했다. 변화된 내용을 간단히 설명하면 한 덩어리의 목적 조직(그 안의 기능 파트들)에서 여러 덩어리의 목적 조직으로 나뉘게 된 것이다. 초기 제품의 명확하고 좁은 목표를 통해 스무명 가까운 사람들도 한 팀으로 긴밀하게 움직일 수 있었다면 사업과 조직 규모가 커지고 서비스의 구성과 팀의 외연도 확장 되면서 더 이상 좁은 목표로 팀원들의 집중을 끌어내기도, 발견 장소도 다양하고 상태도 다른 여러가지의 문제점들을 모두와 공유하기도 어려워졌기 때문이다.

그렇게 도입한 것이 squad 중심 업무 체계이다. Spotify가 2014년에 소개한 이 영상을 통해 많은 회사들이 도입한 것으로 알고 있다. (나는 한 백번은 본 것 같다) 우리는 현재 세 개의 squad로 이뤄진 하나의 tribe와 별도 두개의 squad가 각자의 목적을 가지고 운영되고 있다. (각 squad는 당연히 모든 직군이 함께 있는 cross functional 조직이다.)

목적에 따른 문제의 정의와 해결은 squad 안에서 이뤄지지만 그 일들이 원활히 잘 되게끔, 한 컴포넌트를 여러 squad에서 수정하고 배포하는 것이 잘 돌아가게끔 하는 것이 챕터다. Backend, Frontend, Client, Product Design, PM 각 기능마다 챕터가 있고 각 챕터의 리드(팀장)들은 챕터의 구성원들의 채용, 성장, 또한 squad의 업무가 잘 수행되기 위해 필요한 부분이 있는지를 확인하고 돕는다. 데이터 엔지니어링, SRE 같이 기술 중심으로 운영되어야 하는 부분은 별도의 파트로 운영되고 있다.

그러다보니 이런 업무 체계에서 지금 나의 관심은 문제를 직접 찾고 해결하는 것 보다는 팀(squad), 혹은 팀을 구성하는 개인이 어떻게 문제를 잘 정의하고, 공유하고, 해결하게 만드는가에 포커스 되어있다. 그러다보니 관리를 해야 하는 대상이 우리 회사의 제품과 각 squad의 목표, 챕터 리드(팀장), 그리고 (간접적으로는)팀원들이 되었는데 대상에 따라 다른 방식과 범위의 매니징 스타일이 필요하다는 것을 체감하고 있다.

앤디 그로브는 업무 관련 성숙도(Task Relevant Maturity) 정도에 따른 효과적인 매니징 스타일을 아래와 같이 정의한다.

앤디 그로브는 개인의 TRM 에 따라 이렇게 다른 매니징 스타일을 적용해야 하지만 매니저 개인의 성향에 따라서도 적절한 대응이 어렵다고 얘기하고 나 역시 거기에 크게 공감했다. 개인으로서, 개발자로서나 프로젝트를 리딩하는 역할을 맡았던 시절(심지어 작년까지도)에는 나 뿐 아니라 모두가 TRM이 높은 상황을 전제로 두고 그래야 한다고 믿었다. 팀의 구성원 모두가 높은 TRM을 통해 그 범위는 다르더라도 스스로 문제를 정의하고 해결하기 위한 방법을 찾아내어 필요한 사람들과 공유하고 이끌어가는, 모두가 리더십을 갖는 모습을 가장 이상적이라고 생각하고 그래서 관리자는 최소한의 관여를 하는 것이 좋은 모습이라 여겼다. (지금도 팀의 구성원 개개인이 이런 방향으로 성장하는 것을 지향하고 있다.) 하지만 책에서도 얘기하듯 구조적이고 태스크 중심적인 매니징 스타일이나 방임처럼 보여질 수 있는(?) 최소한의 관여 중 어떤 것도 나쁜 것은 아니다. 단지 상황과 대상에 따라 다른 스타일이 필요할 뿐이라는 것을 이해하게 되었다.

지난 1분기부터는 챕터 리드분들과는 최소한 월 1회, 다른 팀원 분들과는 최소 분기 1회를 목표로 1 on 1 미팅을 시작했다. squad 중심 업무 체계를 도입한 것부터, 팀원 분들이 이런 변화에 목적이나 방향을 충분히 이해하거나 공감하지 못했음에도 별다른 피드백없이 일을 진행하고 계신다는 것을 눈치채고 회사의 비전이나 우리 일의 목표, 팀의 결정같은 것들에 대해 동기화하는 시간이 필요하다고 생각할 즈음 읽은 실리콘밸리의 팀장들이 1 on 1 미팅을 본격적으로 시작할 용기를 줬다. 구성원 면면이 다르고 여전히 1 on 1 미팅이 형식적인 자리이거나 그저 친밀감을 높이는 시간으로 여기는 사람들도 있겠지만 하면 할 수록 이 시간은 더 늘리면 늘렸지 결코 생략해서는 안 되는 시간이라 여겨진다. 프로덕트 조직에서 잘 실행해가며 회사의 다른 부서들도 할 수 있도록 넛지할 생각이다.

그나저나 나와는 누가 1 on 1 해주나. :(