[책 후기] 개발 7년차, 매니저 1일차

 

이 책은 어떤 개발 리더 관련 행사에서 강의를 하셨던 권원상 님을 알게 되면서 자연스럽게 알게 되었다.

그때 강의의 내용도 꽤나 인상적이었고, 이 책 한번 읽어봐야겠다라고 위시리스트에 남겨뒀다가 이번 기회에 읽게 되었다. 

 

사실 이책은 1일 차 매니저를 위한 책이 아니다.

모든 매니저, 모든 조직의 리더, 리더의 리더 등 모든 위치의 매니저에 대해 얘기하고 있다.

리더뿐만이 아니라 사수나 멘토의 위치에서도 얘기하고 있다.

 

세상에 리더쉽에 관련된 좋은 책이 많다. 하지만 이 책에서 가장 좋은 점은

바로 "개발자" 출신의 "개발조직"의 리더의 입장으로 포커스가 맞춰져 있다.

다른 리더십 관련된 책은 몇 가지 풀어주지 못한 것들이 있었는데

"개발자 출신의 개발조직 리더"라면 가질 만한 고민을 이 책에서 풀어 준다.

 

 

 

1. 개발조직의 리더(이하 테크리드)는 개발을 해야 하는가 말아야 하는가?

 

엔지니어링 리드는 코드 작성에 상대적으로 적은 시간을 쓰지만, 팀의 작업을 방해하거나 작업 속도를 떨어뜨리지 않는 정도의 버그를 수정하고, 작은 기술 산출물에 관여한다. 코드 작성 말고도 팀의 성공을 위해 개발 프로세스의 병목 지점과 장애물을 찾고 이를 제거하는 책임을 맡는다.

두 개의 회사에서 상반된 업무의 테크리드를 해보고 있다.

이전 회사에서는 적극적으로 개발하였고,

지금의 회사에서는 직접 개발하는 것을 지양하고 있다.

 

이전 회사의 경우, 처음부터 적극적 개발을 하려고 했던 것은 아니다. 

그 당시 CPO와 소통에서 투자등의 사정상 제품이 빠르게 출시되어야 했었고, 명확한 데드라인까지 지정이 되어 있었으며

기획에 구멍이 엄청 많고, 그 구멍을 메꾸면서 정책과 디자인이 시도 때도 없이 변경되면서 개발하기 어려운 상황이었고, 

퍼포먼스에 책임이 있는 내 입장에서는 매니징의 관점보단 시니어 개발자로서의 역할을 해왔다.

 

그 결과,

납기에 맞춘 제품은 출시하였지만

나는 새롭게 성장한 포인트가 없었으며,

팀원들 또한 나로 인해 도전해 보고 경험해 볼 기회를 잃어버려 성장을 할 수 없었다.

결과적으로 그 누구도 성장할 수 없는 프로젝트였으며, 성장하지 못한 조직은 고스란히 리더의 책임이다.

내가 잘못했다.

 

지금의 회사의 경우, 제품에 최대한으로 코드를 병합하는 행위를 지양하고 있다.

전혀 하지 않은 것은 아니고 약 한 달의 시간 동안 내가 작성한 코드들은 다음과 같다.

• convention을 위한 eslint config package 개발
• boilerplate code를 자동으로 생성해 주는 package 개발
• 아키텍처와 Grid System의 예시를 보여주기 위한 단일 라우팅 랜딩페이지
• CI/CD용 workflow

즉, 팀의 규칙을 생성, 통제하고 자동화하여 결과적으로 생산성을 높이기 위한 작업들을 해왔다. 

이는 실제 제품으로의 가치는 없지만,

앞으로 팀원들이 개발에 있어 다른 부분보다 더 개발에 집중할 수 있는 환경을 만들기 위한 작업이었으며 

제품 코드의 관여는 기술, 경험적 부족해 해결이 어려워하는 경우만 개입하고자 한다.

 

 

2. 테크리드는 조직에서 개발을 제일 잘해야 하는가?

 

기술 팀에게 존경을 받으려면 팀원들이 기술적으로 신뢰할 수 있어야 한다.

 

 

 

이 부분은 반대 반향으로 내 공감을 얻은 문구다.

내가 경멸하고 무시했던 리더들을 다양하게 접하면서

나는 저런 리더가 되지 않겠다는 좀 강박이 있게 되었고,

그로 인해 나는 이직 등 새로운 조직을 접할 때마다 가장 먼저 해야 하는 것은 항상 같았다.

 

바로 Show & Prove 다.

 

먼저 나의 실력을 보여주고 증명해야 다른 사람들에게 신뢰를 얻을 수 있다고 생각했다.

먼저 보여주는 것이 코드 품질이고 그다음 생산성이었다. 

내가 먼저 증명되지 않으면 나의 리뷰, 피드백이 대상자에게 신뢰가 떨어진다.

새로운 조직에 들어가면 처음 몇 달은 심신이 고생하면서 나를 증명하고자 해왔다.

 

나는 조직에서 테크리드는 기술력이 가장 좋아야 한다고 생각해 왔다.

하지만 이 책에서는 가장 잘할 필요는 없지만, 존경을 받을 수 있는 기술력이 있어야 하고,

매니저라는 말이 개발에서 멀어져도 된다는 말이 아니라 계속 붙잡고 있어야 한다고 한다.

 

좀 더 심신이 덜 고생하게 될 것 같다.

 

 

 

 

3. 피드백을 어떻게 해야 하는가? 감정이 상해도 빠른 길로 가야 하는가? 아님 위로와 칭찬을 통한 느린 길로 가야하는가?

자존심에서 벗어나기 위해 사용했던 또 다른 방법은 호기심을 일으키는 방법이었다.

 

 

1on1이나 코드 리뷰를 하다 보면 솔직한 피드백이 상대의 감정을 상하게 하는 일이 빈번하게 발생한다.

내 입장에서는 문제를 물 위로 올리고 성장을 위해 피드백을 제공한다 라는 생각이지만 

피드백을 받는 입장에서 항상 좋게 받아들이는 게 어렵다는 것은 잘 알고 있다. 나도 그런 적이 꽤나 있으니까

생각해 보면 이런 경우는

자존심에 상처가 나서 발생한 일이 대부분이다.

 

그 자존심을 상처 나지 않게 하기 위해 피드백을 안 할 수는 없다.

내가 알기론 피드백이 성장을 위한 가장 빠르고 확실한 방법이니까

 

그러면 이 것을 어떻게 해야 하는가? 어르고 달래 가며 문제를 감추면서 피드백해야 하는가?

이런 부분에 있어 이 책은 호기심이라는 키워드를 제공했다.

 

내가 피드백을 A부터 Z까지 제공하는 것이 아니라 

키워드와 방향정도만 제공하고 스스로가 학습하고 비교해서 결정할 수 있게 가이드하는 방법인 것 같은데

다방면의 피드백을 제공해야 하는 내 입장에서는 큰 인사이트를 받게 되었다.

어쩌면 두 마리 토끼를 잡을 수 있는 방법이지 않을까 생각한다.

 

4. 아 힘들다 사람이랑 언어로 대화하는 것보다 컴퓨터랑 언어로 대화하는 게 편하다.

 

매니저를 쉬게 만드는 것도 팀원의 업무다. 매니저 역시 사람이고 불완전하고 스트레스를 받는다.

 

우리 조직의 팀원들이 꼭 이 책을 보면 좋겠다.

 

 

 

총평 

기존에 읽었던 리더십 관련 책은 내 상황과 맞지 않는 내용이 많았다. 

보고 체계, 보고서, 수직 체계, 승진 같은 경우의 얘기들인데 

뭐 github pr을 보고서, 리뷰어를 보고 체계라고 볼 수 있으려나.. 싶지만 

"개발자"와 "테크리드"라는 직무의 특수성이 이 책에선 명확히 타게팅이 되어 마치 나를 위한 책 같았다.

 

나는 경험, 고민, 생각, 실험을 통해 나의 역할과 만들어가야 할 조직과 이상적인 조직에 대해

나만의 정의를 내렸었고 또 그 정의가 추가되거나 수정되고 있다.

이 책은 이런 내가 내린 정의들에 대해 더 확신을 할 수 있는 정의도 생겼으며 추가되고 수정된 정의들도 있다.

꽤나 현재에 내게 도움이 된 책이고,

앞서 말했듯이 다양한 위치에서의 관점을 얘기해 주기 때문에

내 위치가 변경되었을 때에도 다시 또 도움을 받을 수 있을 것 같다.

그때 다시 읽는다면 또 한 번 내가 내린 정의가 첨삭되지 않을까 싶다.

 

 

개발 7년차 매니저 1일차:개발만 해왔던 내가 어느 날 갑자기 ‘팀’을 맡았다!

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다