아는 지인 개발자분이 최근에 이직하면서 프로젝트 매니저(PM)로 전직을 하시게 되었다. 개발은 꼭 필요할 때만 하고 리소스 관리, 기획 변경 히스토리 체크, 일정 관리 등 여러가지 업무 프로젝트 매니징과 관련된 포지션을 맞게 되었는데 다행이 성향과 맞아서 재밌게 하고 계신다고 하셨다. 그 분과 각자 회사에 관해 이야기를 나누었고 특히 매니징이라는 업무, 역할에 대해 심도있는 대화를 나누게 되었다. 나의 경우도 최근에 동료 프론트 엔드 개발자가 합류하면서 업무 분배, 일정 산정, 코드 리뷰 등 개발의 일부분일 수 도 있지만 매니징과 관련된 업무를 하게 되면서 어떻게 하면 매니징을 잘 할 수 있을까 하는 고민도 하게 되었는데 마침 관련된 좋은 책을 구하게 되어서 읽게 되었고 관련하여 간략한 후기를 남겨볼까 한다.
책의 전체적인 구조는 다음과 같다.
- 1장은 메니저를 따르는 방법과 매니저에게 기대할 수 있는 것이 무엇인지 설명한다.
- 2장, 3장은 매니저가 되기는 단계에서 중요한 단계인 멘토링과 테크리드를 설명한다.
- 4장 ~ 7장은 직원을 관리하는 방법, 팀을 관리하는 방법, 여러 팀을 관리하는 방법, 매니저를 관리하는 방법을 소개한다.
- 8장은 시니어 리더십의 모든 것을 다룬다.
- 9장은 팀 문화를 수립하고, 수정하고, 향상시키기를 원하는 사람, 문화와 프로세스를 향상시켜야 하는 회사나 탐에 새로 합류한 사람에게 도움이 될 만한 내용이다.
나는 현재 포지션이 개발팀의 팀원이기 때문에 좋은 메니저를 따르는 방법이 적혀있는 1장과 작은 규모의 프론트엔드 팀을 리드하는 입장이기 때문에 2장과 3장을 정독해서 읽었고 나머지 장은 빠르게 훑어 보듯이 읽었다. 좋은 팀원이 되는법 동시에 좋은 멘토가 될 수 있기를 바라면서 책을 읽었다.
원하는 것을 생각하는 데 시간을 써라
경력의 여러 단계를 거치다 보면, 세상이 얼마나 불확실한지 깨닫게 되는 것 같다. 나는 설계회사를 다니다 프로그래밍을 공부해서 강사를 하게 되었고 이후엔 프론트엔드 개발자로 전향하게 되었다. 새로운 일을 시작할때 의지는 충만해지고 설렘으로 가득하다. 시작이기 조금만 노력해도 실력은 크게 성장하고 주변의 기대는 작기 때문에 조금만 잘해도 칭찬 받을 수 있다. 하지만 시간이 점차 지나면서 성장은 더뎌지며 주변의 기대는 커지고 그에 부응하기 위해 노력하지만 쉽지 않다. 내가 지금 잘 해나가고 있는지 의심되며 주변과 비교하게 된다.
이 모든 불확실함, 불안감을 극복하기 위해 의지할 수 있는 사람은 자기 자신이다. 매니저는 이걸 대신 해 줄 수 없지만 매니저를 이용하면 내 위치에서 무슨 일 까지 가능한지 알 수 있다.
이를 통해 내가 무엇을 원하고, 해보고 싶은 지를 찾고 공부하면 불안감은 조금씩 사그러들게 된다.
매니저에게 휴식을 주자
매니저를 쉬게 만드는 것도 팀원의 업무다. 매니저 역시 사람이고 불완전하고 스트레스를 받는다.
공감했던 부분이다. 우리는 매니저는 완벽할 수 없다는 것을 알면서도 매니저에게 의지하게 되고 매니저가 리더쉽을 발휘할 때도 매니저니까 당연한 것이라고 생각한다. 이는 공평하지 못하다. 나는 과연 메니져에게 좋은 팀원인가 돌아보았을 때 당당하게 "그렇다!" 라고 말할 수 있는 사람보다 그렇지 못한 사람이 더 많을 것이다.
온갖 이유를 들어 매니저를 원망하기 시작하면 결국 다른 팀으로 자리를 옮기거나 다른 직업을 찾아야 한다. 여태껏 같이 일한 모든 매니저를 원망해왔다면, 그 원인이 매니저에게 있는지 아니면 내게 있는지를 생각해보자.
경청하기
경청은 사람 관리의 시작이자 기본이다. 경청은 좋은 매니저의 핵심 기술 중 하나인 공감의 전단계다.
매니저는 당연히 더 경력이 길고 실력도 출중하며 개발에 관해 더 많은 히스토리를 알고 있을 확률이 높다. 그렇기 때문에 팀원의 의견이 자신의 의견과 다를 때 자신의 의견이 맞는다고 단정지어 버리기 쉽고 실제로 그럴 확률이 높다. 하지만 경청하는 자세는 매우 중요하다. 한국사람 말은 끝까지 들어봐야한다고 하지 않던가? 중간까지만 듣고 제멋대로 판단해서 말을 끊고 부정해버리면 팀원은 얼마나 억울할까. 일단 대화를 시작하면 끝까지 듣고 신중하게 생각한 뒤 자신의 의견을 말하는 습관을 가지려고 노력해야겠다. 설사 자신의 의견이 반대 의견일지라도 경청하는 것과 그렇지 않은 것은 상대방의 입장에서 천지차이다.
모든 사람은 자신의 의도를 상대방이 정확히 이해하게 말하지 못한다. 언어는 뉘앙스나 해석까지 전달해 주지 않는다.
경청을 하게 되면 팀원의 말 이상의 무언가를 캐치할 수 있다. 신체 언어와 말하는 방식을 알 수 있으며 그 외에도 많은 신호를 느낄 수 있다.
적절한 피드백 주기
우리 팀에도 최근에 입사한 팀원이 있다. 입사한지 얼마 안되는 팀원이 있다면 회사에 적응하기 위해 많은 에너지를 쏟고 있을 것이다. 피드백은 모든 팀원에게 중요하지만, 특히 새로 합류한 팀원에게 더 중요하다. 내가 팀에 잘 녹아들고 있는지 아닌지를 판가름하는 요소이기 때문이다. 잘했을 때는 어떤 부분을 어떻게 했기 때문에 잘 한 건지 자세히 설명해 주고 마찬가지로 잘못했을 때도 이유를 잘 설명해 줘야 받아들이기 쉽다.
팀 플레이어가 되기
혼자서 재미있는 작업을 전부 하고 있다면 당장 멈추자. 기술적으로 필요한데 까다롭고, 지루하고, 성가신 작업이 무엇인지 살펴보고 이런 작업을 해결할 수 있는지도 고민해야한다. 재미 없는 부분을 작업하다 보면 프로세스 어느 지점에 문제가 있는지 많이 배울 수 있다.
팀원들과 업무 분배를 할 때 고민을 많이 하게 된다. 효율성을 중시해서 이전에 해당 부분을 개발했거나 기술에 익숙해서 잘 할 수 있는 부분을 담당하거나 관련도가 높은 도메인별로 작업할 수도 있다. 재미를 중시해서 자기가 개발하고 싶은 부분을 가져가서 개발할 수도 있다. 아니면 비교적 개발 속도가 빠른 매니저가 많은 부분을 개발하고 팀원이 남은 부분을 개발할 수도 있다.
상황에 따라 다양한 선택을 할 수 있겠지만 저자가 말한 것처럼 매니저는 까다롭고, 지루하고, 성가신 작업을 담당하는 것이 맞다고 동의한다. 그래야 프로세스를 잘 파악할 수 있고 문제점을 발견하기 쉽다. 그리고 최대한 시간을 내서 팀원들의 코드를 꼼꼼히 리뷰해주어야 한다. 보통 커다란 테스크를 오랜 시간 집중해서 개발하다 보면 임시로 처리하고 넘어간 코드, 실수로 지우지 못한 코드, 덩어리가 너무 커 직관적이지 못한 코드, 이 외에도 다양한 문제를 안고 있는 코드들이 생기기 쉽다. 이런 부분을 세세하게 봐주고 이해가 안되는 코드가 있다면 물어보고 잘 한 부분이 있으면 칭찬해 주는게 중요하다. 코드 리뷰에 시간을 많이 투자하면 그만큼 프로젝트를 전반적으로 잘 이해할 수 있게 되기도 한다.
책을 읽으면서 머리가 띵 하고 울리는 부분이 있었다. 경청부분이었는데 내가 평소에 팀원들, 매니저 뿐만 아니라 주변 모든 사람들과 대화할 때 과연 경청하고 있는지 되돌아 보게 되었는데 결론은 아닌 것 같다는 생각이 들었다. 나 또한 상대방이 내 이야기에 귀 기울여주지 않으면 기분이 상하는데 나도 종종 그렇게 행동하고 있었던 것 같다. 좋은 매니저, 더 나아가 좋은 사람이 되기 위해서 공감까진 아니더라도 경청하는 자세를 가지고 살아가야겠다.
