[데이터조직]팀을 운영할 때 모든 것을 알아야할 필요는 없다.

보통 팀에서 일을 가장 잘하던 사람들이 리더로 올라가게 된다. 프로덕트 조직에서 리더가 되면 대체로 PM이 되는 편이지만, 조직의 형태에 따라 PM이 아니라 개발자가 리더가 될 수도 있다.

이 때 보통 가장 어려운 것이 실무를 놓는 것이다. 물론 인원이 적다면 실무를 놓지 않아야 하는 경우도 분명 있다. 하지만 리더가 되면 가장 크게 바뀌는 부분이 있다. 기존에 자신이 담당하던 컴포넌트나 프로덕트의 일부를 넘어서 프로덕트의 방향성 및 비즈니스의 이해 등이 요구되기 시작한다는 것이다.

이전에는 분명 크게 신경쓰지 않았던 영역이지만, 리더로서 종종 PO의 역할도 해야 한다고 생각하면, 딜리버리나 요구사항의 우선순위 등을 결정해야 한다고 하면 언급한 지식들은 일을 하는데 있어 꽤나 개발지식을 넘어 중요한 요인이 되버린다.

왜 이런 개발을 해야 하는지, 상황을 파악하고 말도 안되는 요구를 주었다면 조정을 해야 하기 때문입니다. 실제로 요청부서는 문제만 해결된다고 생각하기 때문에 하나의 개발부서를 만나도 해당 개발조직에 적합한 커뮤니케이션을 한다기 보다는 그냥 다 말하는 성향이 종종 있어서, 이 내용을 그대로 개발조직으로 가져갔다가는,  커뮤니케이션 비용만 증가하곤 한다.

다만 이런 커뮤니케이션까지 하려다 보면 사실 기존에 하던 실무를 할 시간은 점차 줄어들게 되는데, 그럼에도 불구하고 실무를 놓지 않는 사람들이 종종 있다. 잠깐이야 버틸 수 있지만, 장기로 보면 이는 지속가능하지 않기 때문에 결국 전체적인 퍼포먼스의 저하를 불러올 수 있다. 프로덕트라는 것이, 정말로 상호 의존성을 많이 가지고 있는만큼 커뮤니케이션 비용이 상당하고, 그 커뮤니케이션을 효율화하는 것은 또 다른 프로덕트를 빌드업하는 수준에 가깝기 때문이다.

따라서 오래가는 길을 선택하기 위해서는 실무를 조금씩 내려놓되, 어떤 일은 위임해야할지, 또는 직접해야 할지 고민하는 프레임워크를 구성할 필요가 있다. 동시에 상위부서로 의사결정을 올려야 하는 경우도 잘 걸러낼 수 있어야 한다.

이 때 쯤 되면 보이지 않던 능력이 요구되고 계발될 필요성을 느끼게 된다. 바로 회사 전체의 구성요소로서 팀이 달성해야 하는 목표와 나아가야하는 방향성이다. 목표는 단기적일 수 있지만 방향성은 시간이라는 축에서 이제 팀을 운영하는 것을 뜻한다. 정말 기존에는 크게 생각해보지 않았던 분야일 수 있다.

그리고 이 방향성을 바탕으로 팀에게 목표를 제시하고, 측정하며 피드백을 줌으로써 나와 구성원의 커리어패스가 흔들리지 않도록 도와줘야 한다. 만약 회사에 조직개편이 잦다면 이러한 방향성은 팀장의 핵심역량이 되어야 한다.

이 쯤 되면 묻고 싶다. 팀장이 팀에서 발생하는 모든 지식과 업무방식에 대해서 완벽하게 꿰둟을 수 있을까? 그렇지 않다. 언리더십이라는 책에서도 그러했지만, 팀장과 팀원은 상호의존적인 관계속에 역할이 따로 있고, 그 역할을 제대로 수행해야하기 때문에 모든 지식을 알아야 하는 것보다 그 지식이 어떻게 활용될 수 있을지를 고민해야 하는 것이 맞다.