지난달 말 회사의 연구소장님과 일부 인원들과 함께 점심 간담회를 한 적이 있다. 연구소장님은 개발자들이 자신의 캐리어 패스를 적을 때 매니저 트랙을 선택하지 않는지 궁금해하셨다. 그렇다. 대부분 개발자들은 매니저가 되는 것을 싫어한다.
대답은 이러했다. 매니저를 보면 이슈와 보고를 대응하느라 너무 바쁘다. 하루 종일 회의다. 얼굴 보기도 힘들다. 어려운 이슈나 문제를 해결해주지 못한다. 자료만 만들고 윗분들에게 보고만 한다. 개발에서 손 놓은지도 오래다. 힘들기만 하고 얻는 게 없어 보인다. 개발자 트랙을 유지하고 싶은 이유는 개발하는 것은 어려운 기술적인 문제를 풀어가면서 실력이 늘어가는 것을 느끼는 것에서 희열과 개발자로서 자부심을 느낀다.
하지만 여차 저차 한 이유로 개발자에서 매니저로 승진한다면 그동안 욕했던 매니저의 모습을 내가 하고 있을 수 있다. 어떻게 하면 좋을지 잘 모르겠는 경우가 있을 거다.
<<개발 7년 차, 매니저 1일 차>> 는 개발자에서 매니저가 막 되어서 이런저런 고민들이 많은 사람들, 혹은 앞으로 매니저가 되고 싶은 사람들, 혹은 매니저가 되지 않더라도 내 매니저는 어떨까 생각해볼 사람들에게 유용하다. 내용은 궁금한 점을 찾아 읽기는 좋지만 큰 흐름이 있지는 않다. 작가는 장별로 읽는 법과 매니저의 경력에 따라 어떤 챕터를 먼저 읽으면 좋을지 가이드라인을 제시한다. 이 책의 저자는 카미유 푸르니에로 패션계의 넷플릭스로 불리는 의류 대여 회사인 Rent the Runway의 전 CTO다. 미국 회사라 우리와는 다른 회사 문화일 것이라 생각하지만 읽어보면 글로벌 시대고, 사람 사는 곳의 문제는 다 비슷하다는 공감을 얻을 수 있다.
좋은 테크 리드 또는 좋은 매니저를 만나기란 쉽지 않다. 이 책은 그 이상적인 모습이 무엇인가 생각할 기회를 주는 책이다. (이 책에서 말하는 테크 리드는 두 명에서 열 명 규모의 개발 팀을 책임지는 팀장으로 관리와 개발 업무를 병행한다.)
뛰어난 기술 매니저란?
작가가 말하는 좋은 리더는 의사소통에 능숙하고, 문서 작성도 깔끔하며, 발표도 잘한다. 다른 팀이나 다른 역할의 사람과 소통하기 즐기며, 업무 진행 상황을 정확히 파악하고 설명한다. 우선순위를 정하는데도 능숙하며, 업무를 추진하며 다음 할 일을 결정하는 것을 좋아하고 추진력이 강하다. 또한 사내 정치도 잘해서 자신의 팀원을 돋보이게 하고 키우는 역할을 잘하는 사람이다.
이 책을 읽으면서 처음 알게 된 것은 RTR(Record to Report) 기술에 따라 팀 멤버를 관리해야 한다는 것이다.
-정기적인 원온원 미팅 (주 1회)
-경력 성장, 목표 진행, 개선된 영역 및 명시적인 칭찬 등에 대한 정기적 피드백
-프로젝트 업무, 외부 교육 등 멘토링 등을 통해서 팀원의 성장을 돕는 교육과 지원 보고서 작업
프로젝트 관리를 위해서는
대부분 매니저들이 잘 알 것 같지만 저자가 말하는 방법을 나열해 본다. 저자가 말하는 프로젝트 관리란 "복잡한 최종 목표를 작은 일로 나누고, 이 일을 끝내기 위한 가장 효과적인 순서로 배치하고, 병행 처리할 일과 순차 처리할 일을 찾아내고, 프로젝트 진척 속도를 늦추거나 실패하도록 하는 원인을 찾아 제거하는 것"이다. 저자가 제시하는 가이드라인은 다음과 같다.
1) 작업을 잘게 나눈다.
2) 일을 어렵게 만드는 세부 사황과 문제가 될 수 있는 부분은 끝까지 신경 쓴다.
3) 프로젝트를 시작하고 진행하며 계획을 수정한다.
4) 계획 프로세스에서 얻은 통찰로 변경된 요구사항을 관리한다.
5) 프로젝트 완료 시점이 가까워지면 세부사항을 다시 검토한다.
후배들을 위해서는
좋은 매니저가 된다는 것은 기술적으로 가장 뛰어나야 한다는 의미는 아니었다. 사람들을 돕는 일이 매니저로서 성공하는 데 훨씬 중요하다. '현대의 소프트웨어 개발은 팀 스포츠'이다. 매니저는 '코치'이자 '지지자'가 되는 것이 가장 좋다고 저자는 말한다. 이 책 중간에 기고자의 글도 있는데, 임백준 저자의 말이 가장 기억에 남는다.
"좋은 매니저는 착한 사람도 능력 있는 사람도, 정치를 잘하는 사람도 아니다. 좋은 매니저는 후배를 성장시키는 사람이다. 후배들의 앞길을 있는 힘을 다해 열어주고, 이끌어주고, 밀어주는 사람이다. 그게 좋은 매니저다."
자신을 위해서는
기술 역량을 유지하자. 사실 지금 세계 최고 회사를 보더라도 CEO는 모두 다 엔지니어 출신이다. 개발자가 매니저가 되는 것이 꼭 개발 커리어를 멈추는 일만은 아니다. 매니저가 되었다고 개발자 무덤에 갔다 생각하지 말고 기술 역량을 유지하자. 저자는 그 이유를 이렇게 말한다.
"기술 관리는 단순히 사람을 관리하는 방법을 모은 것과는 다른 기술적인 분야다. 경력 개발 과정에서 코딩은 하지 않더라도 기술적 의사 결정을 해야 하는 역할이기 때문이다. (중략)
팀 매니저로서 아키텍트나 시니어 기술 담당자가 자신의 결정에 책임을 지도록 하고, 기술적인 문제가 없는지 확인하고, 팀과 비즈니스라는 맥락에서 균형을 맞추는 것이 기술 매니저의 업무다. 몇 년에 걸쳐 쌓인 숙련된 기술적 감각은 이런 과정에서 매우 중요하다."
정말 일반 매니저가 되는 것도 어려운데 기술 매니저는 그 어려운 것을 다 해내야 한다. 그 쉽지 않은 길을 가는 분들의 앞길이 꽃길만 가득하길.
*이 책은 한빛 미디어의 <나는 리뷰어다> 활동으로 출판사로부터 제공받았으나 내용은 주관적인 의견입니다.