Cross Functional 기술 문제 풀기 위한 역량 성장 Tip
조직이 커질수록 각 팀이 맡은 일은 잘 수행해도 팀과 팀 사이의 공백이 커지며, Cross Functional 기술 문제가 발생합니다. 이런 문제는 회의·보고·리스크 관리 같은 조율만으로 해결되지 않으며, 문제를 재정의하고 구조화해 실제 실행으로 전환해야 합니다. 토스의 TPM은 공식 권한보다 문제 정의력, 구조화 능력, 영향력과 실행력을 바탕으로 복합적인 문제를 끝까지 해결하는 역할을 합니다. ## 조직 성장과 함께 커지는 경계의 문제 - 팀별 책임과 전문성이 높아질수록 팀의 경계 밖 문제가 늘어납니다. - 인프라, 제품, 데이터, 보안, 운영 이슈가 서로 얽혀 한 조직만으로 해결하기 어렵습니다. - 단기 대응과 장기 구조 개선이 충돌합니다. - 중요하지만 공식 Owner가 없는 회색지대가 생깁니다. - 각 팀이 최선을 다해도 전체 최적화가 이뤄지지 않을 수 있습니다. ## 조율만으로 해결되지 않는 이유 - 회의를 더 자주 열고 진행 상황을 공유해도 문제의 본질은 남을 수 있습니다. - 리스크 목록이나 일정표에는 결정 구조의 공백, 모호한 책임, 충돌하는 우선순위가 잘 드러나지 않습니다. - 핵심은 관리의 밀도를 높이는 것이 아니라, 문제를 해결 가능한 구조로 바꾸는 것입니다. - 먼저 “진짜 병목은 무엇인가”, “누가 빠져 있는가”, “어떤 결정이 비어 있는가”를 물어야 합니다. ## TPM에게 필요한 핵심 역량 ### 문제를 다시 정의하는 힘 - 일정 지연이나 협업 속도 저하 같은 표면적 현상에 머물지 않습니다. - 지연의 원인, 비어 있는 의사결정, 불명확한 Owner, 반복되는 조직 구조의 문제를 찾아냅니다. - 증상을 관리하는 대신 해결해야 할 문제 자체를 다시 설정합니다. ### 모호함을 구조로 바꾸는 힘 - 무엇을 결정해야 하는지 명확히 합니다. - 가능한 선택지와 책임자를 정리합니다. - 문제를 실행 가능한 단위로 쪼개고 우선순위와 순서를 만듭니다. - 복잡한 문제를 여러 사람이 함께 다룰 수 있는 단순한 구조로 바꿉니다. ### 전략적 판단력 - 일시적인 이슈인지 반복될 구조적 문제인지 구분합니다. - 팀 내부 해결이 가능한지, 조직 차원의 개입이 필요한지 판단합니다. - 지금 개입해야 하는 문제와 관찰해도 되는 문제를 나눕니다. - 해결했을 때 조직의 실행 수준 자체를 높일 수 있는 문제에 집중합니다. ### 실행으로 전환하는 힘 - 실제로 움직여야 할 사람을 명확히 합니다. - 선행 결정과 Blocker를 정리합니다. - 모호한 논의를 결정 포인트로 바꾸고 담당자가 결론을 내리게 합니다. - 합의된 액션 플랜을 실제 행동으로 연결합니다. ### 공식 권한 없이 영향력을 만드는 힘 - 직함이나 지시가 아니라 신뢰와 판단력으로 참여를 이끌어냅니다. - 각 팀의 맥락과 제약을 이해하고 서로 다른 언어를 번역합니다. - 필요한 경우 불편한 대화를 열어 우선순위와 책임 문제를 드러냅니다. ### 사람과 구조를 함께 보는 시각 - 기술 문제가 역할 정의, 팀 구조, 운영 방식에서 비롯될 수 있음을 고려합니다. - 프로세스 개선만으로 충분한지, 역할 재설계나 리더십 개입이 필요한지 판단합니다. - 사람과 시스템을 분리하지 않고 함께 바라봅니다. ## 자율성이 낮은 조직에서의 단계적 접근 - **작은 문제부터 해결하기:** 분명한 병목 하나를 구조적으로 해결해 신뢰를 쌓습니다. - **조율에 구조화를 더하기:** 회의를 진행하면서 결정 사항, 의존성, 병목을 함께 드러냅니다. - **작은 범위에서 Owner 명확히 하기:** 담당자, 의사결정권자, 완료 기준을 구체화합니다. - **사례로 역할 증명하기:** 역할을 설명하기보다 Owner 없는 문제를 해결하고 반복 병목을 줄인 실적을 만듭니다. ## 주의할 점 - 조율은 중요하지만 목적이 아니라 문제 해결을 위한 수단이어야 합니다. - 공식 권한이 없어도 신뢰와 구조화 능력으로 영향력을 만들 수 있습니다. - 조직에 이상적인 역할 모델을 한 번에 강요하기보다 현재 환경에서 작동하는 작은 성공 사례부터 만들어야 합니다. 결국 Cross Functional 기술 문제를 풀기 위해서는 일정과 회의부터 관리하기보다 문제를 다시 정의해야 합니다. 진짜 병목, 누락된 사람과 책임, 실행을 가로막는 구조를 찾아 작은 범위에서부터 바꾸는 것이 실용적인 출발점입니다.
원문 읽기(새 탭에서 열림)
