Feature Tech Leadership 연구일지
불과 몇달 전까지만 해도 필자가 속한팀에는 PM 1명, 디자이너 1명 그리고 iOS/Android 각 한명, Server Engineer 1명 이렇게 구성되어있었다.
시간이 지나면서 각 직군별로 1명에서 2명으로 늘기 시작했고 어느순간 12명이 되어있었다. 동료가 늘어남에 따라 자연스럽게 업무량도 늘어나게 되었고 이에 따라서 원활한 업무 진행과 행복을 위해서 팀내에서 좋은 엔지니어링 문화를 만드는 많은 시도를 하게 되었는데 그 중 하나가<Feature Tech Leadership>이다.
개요
현재 팀에 6명의 Engineers이 있지만 Tech Leader나 Engineer Manager가 없고 팀내에 PM이 팀의 리더를 맡고 있는 상황이다.
이러한 이유는 과거부터 회사의 조직운용형태가 Empowerment 형태의 조직이고 과거부터 이러한 관성이 프로덕트 성장에 따라 탄생하게된 다양한 조직들에게도 관성으로 이어지게 되었고 주로 각 목적조직별로 PM들에게 리더권한을 부여했기 때문이다.
그렇다고 위와 같은 상황이 나쁘다는 의미는 아니지만, 미래지향적인 관점을 보았을 때는 현상황이 제품과 엔지니어들에게 미치는 부정적인 영향은 다음과 같다.
방관자 효과
필자는 방관자효과에 대해서 사람이 늘어나면서 자연스럽게 발생하는 자연의 이치라고 생각한다. 누군가가 기술 스펙 작성이나 기술적인 트레이드 오프 교통정리를 해줄 것이라 생각하고 점점 본인 일에만 집중하게 되는 현상을 볼 수 있게 될 것이다.
수동적으로 변하는 엔지니어
엔지니어 수가 늘어남에 따라서 기존에 Eng/PM/PD가 함께 제품 개발과정(Why-What-How)에서 What에 대해서 충돌하는 문화가 점차 PM이 고민하고 결정하는 분위기가 조성 시작하면서 엔지니어는 How에만 집중하게 되는데, 아직 큰 조직이 아닌데도 불구하고 점점 제품관점에서 생각을 버리게 되는 현상을 볼 수 있게 된다.
좋은 엔지니어 리더로써의 성장 기회 단절
과거 <구글 엔지니어는 이렇게 일한다> 책을 통해서 깨달은건 엔지니어가 Tech Leader/Engineer Manager가 되기까지 리더쉽 경험이나 기술 선택과 방향 결정등과 같은 어느정도 트레이닝이 필요하다. 하지만 현상황에서는 Tech Leader나 Engineer Manager와 같은 룰이 있는 상황도 아닐 뿐더로 권한도 없다. 그 말은 성장할 기회도 없다는 것이다.
속된말로 엔지니어를 단순 프로그래머로 생각하는 건 아닌지 의심하게 된다.
정말 행운인건 필자가 속한팀의 엔지니어분들은 모두가 기술적으로나 협업능력측면에서도 매우 뛰어난 동료들로 구성되어있다.
하지만, 필자는 경영진도 아니고 리더권한이 있는 것도 아니다. 하지만, 현재 팀에서 동료들과 함께 성장하고 PM/PD와 함께 제품의 성공을 위해서 필자가 현재로서 할 수 있는건 이기적이지만 팀내에서 엔지니어링 문화의 불씨를 지피는 것이 최선이라 생각하고 문화중 하나인 <Feature Tech Leadership>이라는 것을 소개해보고자한다.
Feature Tech Leader?
Feature Tech Laeder(FTL)란? 규모있는 조직이나 일반적인 IT회사에서 통상적으로 사용되는 개념은 아니고 필자의 팀내에서 엔지니어들이 함께 Tech Leader에 항상 쳐내오던 제품 Feature를 붙여서 만든 합성어 개념이다.
기존 Tech Leader가 하는 역할과의 차이점이라면,
Feature위주로 Tech Leader를 결정하게 되고 이러한 TL은 제품을 만드는 단계에서 What에 대해서 주도적으로 PM/PD와 함께 충돌하고 함께하는 동료 엔지니어들의 의견을 수렴하여 기술 방향성을 결정하게 된다.
또한, 작은 규모팀에서는 테크니컬 라이터가 있는 상황은 아니지만 회사 규모가 큰 언벨런스한 상황에서 기술스펙 작성은 불가피한데 FTL이 테크스펙을 주도적으로 작성하고 제품의 수명관리까지 책임지게 된다.
또한, 이러한 FTL은 회사나 경영진 또는 부문/팀내 리더가 권한을 내려준 형태가 아닌 반대로 팀내 동료 엔지니어들이 떠받쳐주는 리더형태가 된다.
FTL이 엔지니어에게 미치는 영향
따라서 시범적으로 팀내에서 개개인이 FTL을 최소 1회 경험하고 회고해보자는 목표를 가지고 2022년 6월을 시작으로 해서 약 두달 간 진행하게 되었고 회고를 통해서 다음과 같은 경험을 얻을 수가 있었다.
좋았던 점
- FTL의 존재로 여러 Feature를 소화해내는 환경에서 컨텍스트 스위칭이 줄었으며 안정감있게 개발을 할 수 있었다.
- FTL을 함으로써 이전보다 제품에 대한 오너쉽이 더욱 증가한 것을 체감할 수 있었다.
- 방관자 효과없이 기술스펙의 품질을 높일 수 있었고, FTL이 기술스펙을 주도적으로 작성 및 관리함으로써 테크니컬 라이팅에 대한 경험을 쌓을 수 있었다. 또한, 함께 Feature를 작업한 동료들의 프로젝트에 대한 이해도를 높일 수 있었다.
- FTL의 존재로 인해 플랫폼간의 엔지니어링 커뮤니케이션이 좋은 방향으로 많이 늘었다. 더군다나 플랫폼에 종속적이지 않고 다른 플랫폼에 대한 이해도도 높일 수 있는 기회가 되었다.
또한 아쉬웠던 점도 있었는데
- 변경사항을 더 심각하게 보고 최소 스펙을 강조하는 등과 같은 트레이드 오프를 더 잘 할 수 있었어야하는데 처음으로 테크리딩을 하는 상황이여서 서툴렀다. 테크리드로서 조금 더 팀내에 엔지니어들을 보호할 걸 그랬다는 생각했다.
- 일어났던 일은 아니지만 지나치게 리더에 의존하기보다는 이전에도 그랬듯 먼저 나서는 모습을 잃지는 않았으면 좋겠다.
- 그 이외에는 개개인이 테크리딩을 하면서 부족했던 점에 대해서 아쉬움을 표현하였다.
좋았던 점에서 꽤 긍정적인 경험들도 있었지만 이러한 경험들은 사실상 팀내에서 일반적인 테크리더가 존재 했거나 개인이 이러한 책임과 권한을 받았더라면 겪을 수 있는 보편적인 경험일 수도 있다.
하지만, 회고를 통해서 필자 팀의 엔지니어들이 크게 깨달을 수 있었던 부분은 이러한 기회를 손쉽게 접근할 수 있었고 스스로의 부족함을 깨닫고 성장할 수 있는 기회의 미개척지를 발견했다는 점이다.
즉, 다시말하자면 함께 FTL을 함으로써 엔지니어 리더쉽 부분에서의 성장경험 할 수 있었다는 점에서 가장 큰 의미를 가질 수 있었다.
FTL이 다른 직군에 미치는 영향
Feature Tech Leadership이 PM(Product Manager)나 PD(Product Designer)에게도 꽤 긍정적인 영향을 가져다 주었다.
아주 간단하게 하나의 사례만 이야기해보자면, PM입장에서는 제품개발과정중 What을 고민하는 과정에서 FTL이 함께 밀접하게 고민하고 충돌함으로써 기술적인 선택이나 해결해야하는 문제에 대한 방향성을 결정하는데 촉매제와 같은 영향을 줄 수 있었다. 더군다나 이전보다는 확실히 구현과정에서 변경되는 스펙이 많이 줄어듦으로써 제품의 안정적인 제품을 빠르게 출시 할 수 있었다.
마무리
좋은 엔지니어링 결과물은 좋은 엔지니어들이 만들어 냈기 때문이고, 좋은 엔지니어들이 있다는건 좋은 엔지니어링 문화가 있기 때문이다. 이러한 좋은 문화가 만들어 질 수 있는 건 동료들에 대한 사랑이 먼저라고 생각한다.
이러한 Feature Tech Leadership 문화가 만들어진 것도 동료들간에 사랑으로 부터 비롯된 것이며, 테크리더쉽을 경험한다는 것이 뛰어난 특정한 엔지니어나 또는 경영진이 씌워준 감투와 같은 권한이 아닌 엔지니어들이 모여있는 커뮤니티 내에서 차별없이 경험하고 부족한 부분을 함께 채워가며 성장할 수 있는 경험이 되길 바라는 마음으로 부터 시작되었음을 다시금 강조하며 글을 마무리하고자 한다.
