<div id="readability-page-1" class="page"><div>기술 조직이 커질수록 어려운 문제는 팀 안이 아니라 팀과 팀 사이에 남습니다. 각 팀은 자기 역할을 잘하고 있는데도, 전체로 보면 중요한 공백이 생깁니다. 모두가 중요하다고 말하지만 끝까지 책임지는 사람은 없고, 상태는 계속 공유되는데 현실은 쉽게 바뀌지 않습니다.이런 문제는 보통 한 영역에서 깔끔하게 다루어지지 않습니다. 인프라의 문제처럼 보였지만 제품의 문제기도 하고, 기술 전략 방향이 잘못 되었을 때도 있고, 운영 방식을 근본적으로 재설계할 필요가 있을 때도 있으며, 때로는 조직 구조와 역할 정의부터 건드려야 할 때도 있습니다. Cross Functional, Cross Domain 기술 문제가 생긴 것입니다. 이러한 문제를 푼다는 것은 단순히 협업을 잘하는 것만으로는 안됩니다. 회의를 잘 진행하고, 일정을 잘 관리하고, 리스크를 잘 정리하는데도 문제가 풀리지 않을 때가 있죠. 정말 중요한 것이 빠져서입니다. 흩어진 단서들을 다시 모아, 문제를 재정의하고 조직이 함께 실제로 풀 수 있는 형태로 바꾸는 과정. 이것이 핵심이자 정수입니다. 토스에서는 TPM(Technical Program Manager)이 이러한 문제를 푸는 역할을 하고 있습니다. 저는 이 글을 통해 토스 TPM이 이 문제를 풀어나갈 수 있는 힘과 방식이 무엇인지 이야기해보려 합니다. 결국 필요한 것은 화려한 기술이 아니라, 중요한 문제를 끝까지 실행시켜 현실의 변화를 일으키게 하는 몇 가지 핵심 역량과 관점입니다. 그리고 토스가 아닌 다른 팀에서도 이 방식을 차용하는 단계적 접근법도 설명해보고자 합니다. <h2 id="364a360d-33e3-8033-aa5c-f130136e9b7c">가장 먼저 기억해야 할 한 문장</h2>Cross Functional 기술 문제는 조율만으로 풀리지 않는다고 믿습니다. 문제를 다시 정의하고, 구조화하고, 사람이 움직일 수 있는 실행 구조로 바꾸는 역량이 있어야 비로소 근본적으로 해결되는 경험을 해왔습니다. 이 문장이 중요한 이유는, 많은 조직에서 문제 해결을 위해 실제 수행해야하는 액션보다 더 작은 시도들만 하게 되기 때문입니다.문제가 생기면 흔히 밟은 단계입니다. 물론 이런 일도 필요합니다. 하지만 이 활동만으로는 문제의 중심에 닿지 못하는 경우가 많습니다. 진짜 병목은 일정표에 적혀 있지 않고, 보고서에도 직접 쓰여 있지 않기 때문입니다. 대개는 결정 구조가 비어 있거나, Owner가 모호하거나, 우선순위가 충돌하거나, 여러 팀이 각자 최선을 다하고 있는데도 전체 구조가 맞물리지 않는 데에 있습니다.그래서 이 문장을 기억해야 합니다. Cross Funtional 기술 문제를 푼다는 것은 관리의 밀도를 높이는 일이 아니라, 문제를 해결 가능한 구조로 바꾸는 일입니다.<h2 id="364a360d-33e3-800a-9e9c-e8e28fb9dd4e">왜 이런 문제가 더 자주 생기는가</h2>조직이 덜 성숙했을 때는 병목이 비교적 선명합니다. 누가 늦는지, 어디서 커뮤니케이션이 끊기는지, 누가 결정을 미루는지 눈에 잘 보이죠.하지만 조직이 좋아질수록 남는 문제는 달라집니다. 각 팀이 더 잘할수록, 각자의 책임이 더 선명할수록, 오히려 경계 밖의 문제가 더 많이 남습니다. 누구도 틀린 일을 하고 있지 않은데도 전체 최적화가 되지 않는 상태가 생깁니다.특히 기술 환경이 복잡해질수록 이런 현상은 더 강해집니다.그래서 중요한 문제일수록 누군가가 선을 넘고 나서서 새로 정의해야 합니다. 그대로 두면 모두가 보고는 있지만 아무도 풀지 않는, 혹은 풀 수 없는 상태로 오래 남기 쉽습니다.<h2 id="364a360d-33e3-8083-aedd-f4fbca517db2">필요한 역량은 무엇인가</h2>이제 핵심으로 들어가 보겠습니다. Cross Funtional 기술 문제를 풀기 위해 필요한 역량은 많아 보이지만, 사실은 몇 가지 축으로 정리할 수 있습니다.<h3 id="364a360d-33e3-8051-b9eb-e2ba6e26756d">1. 문제를 다시 정의하는 힘</h3>가장 먼저 필요한 것은 문제 정의 역량입니다.겉으로 드러난 현상은 대부분 이미 모두가 알고 있습니다. 일정이 밀린다, 협업이 느리다, 우선순위가 자주 바뀐다, 의사결정이 늦다 같은 말은 누구나 할 수 있죠. 하지만 이런 말만으로는 실제 해결이 시작되지 않습니다.중요한 것은 현상 아래에 있는 진짜 문제를 다시 붙잡는 일입니다.문제를 정확히 다시 정의하지 못하면, 조직은 계속 증상만 관리하게 됩니다.<h3 id="364a360d-33e3-80e4-90ed-ef7e7b4c7437">2. 모호함을 구조로 바꾸는 힘</h3>좋은 문제 정의가 끝이 아닙니다. 그 다음에는 여러 사람이 함께 다룰 수 있는 구조로 바꿔야 합니다.여기서 필요한 것이 구조화 역량입니다. 무엇을 결정해야 하는지, 어떤 선택지가 있는지, 누가 어떤 책임을 져야 하는지, 어떤 순서로 풀어야 하는지를 보이게 만들어야 합니다.복잡한 문제는 원래 복잡합니다. 하지만 해결되는 문제는 늘 더 단순한 구조로 재정의된 문제입니다. 애매함을 그대로 견디는 사람보다, 애매함을 다룰 수 있는 단위로 쪼개는 사람이 결국 조직을 움직입니다.<h3 id="364a360d-33e3-80df-83c1-cae288ec9e9b">3. 무엇이 진짜 중요한지 가려내는 힘</h3>모든 Cross Functional 문제가 같은 무게를 갖는 것은 아닙니다. 어떤 것은 단기 조정으로 충분하고, 어떤 것은 구조적으로 개입해야 합니다.그래서 전략적 판단력이 필요합니다.중요한 문제를 붙드는 사람은 바쁜 문제보다 큰 문제를 구분할 수 있어야 합니다.<h3 id="364a360d-33e3-80b1-bab3-f2bd4388530c">4. 실행이 일어나게 만드는 힘</h3>좋은 문제 정의와 좋은 문서만으로는 현실이 바뀌지 않습니다. 결국 누군가는 사람을 움직이게 해야 합니다. 
여기서 필요한 것은 실행 전환 역량입니다.핵심은 실행을 옆에서 관리하는 것이 아니라, 실행이 실제로 일어나도록 만드는 것입니다.<h3 id="364a360d-33e3-8075-94cf-d0c6fa39bfa2">5. 공식 권한 없이도 움직이게 만드는 힘</h3>Cross Functional 문제는 대개 공식 권한만으로 풀리지 않습니다. 여러 팀의 우선순위가 다르고, 각자의 제약도 다르기 때문입니다.그래서 영향력과 신뢰가 중요합니다. 상대의 맥락을 이해하고, 서로 다른 언어를 번역하고, 필요한 순간에는 불편한 대화도 열 수 있어야 합니다. 사람들이 이 사람의 말에 시간을 쓰는 이유는 직함이 아니라 판단력과 신뢰여야 합니다.<h3 id="364a360d-33e3-8065-90f8-c94a794950d4">6. 사람과 구조를 함께 보는 힘</h3>기술 문제처럼 보이는 많은 이슈는 사실 기술만의 문제가 아닙니다. 역할 정의가 애매해서 생기기도 하고, 팀 구조가 현재 문제를 감당하지 못해서 생기기도 하며, 운영 매커니즘이 낡아서 반복되기도 합니다.그래서 정말 중요한 문제를 다루려면 사람과 구조를 함께 볼 수 있어야 합니다. 프로세스만 바꾸면 해결되는지, 역할을 다시 나눠야 하는지, 리더십의 개입이 필요한지까지 함께 볼 수 있어야 합니다.<h2 id="364a360d-33e3-806a-9f0b-d1befc9bde95">한 번 더 요약하면</h2>회의를 더 해야 하나보다, 보고를 더 자주 해야 하나보다, 리스크 표를 더 정교하게 만들어야 하나보다 먼저 아래의 질문을 하는 것이 중요합니다. 좋은 문제 해결은 활동량이 아니라 질문의 수준에서 시작됩니다.<h2 id="364a360d-33e3-8022-8b4d-e02d51619b48">자율성이 높지 않은 조직에서는 어떻게 시작할까</h2>여기까지 읽으면 이렇게 생각할 수 있습니다. 맞는 이야기이긴 하지만, 우리 조직은 아직 그렇게 자율적이지 않다고요. 권한이 분산되어 있지도 않고, R&amp;R이 선명하지도 않고, 역할 경계 밖으로 나가는 것이 자연스럽지도 않을 수 있습니다.그렇기 때문에 더더욱 한 번에 이상형을 들이밀기보다, 단계적으로 접근하는 것이 중요합니다.<h3 id="364a360d-33e3-80d9-94eb-e16ee553a237">1. 먼저 작은 문제를 실제로 풀어 신뢰를 만든다</h3>처음부터 역할의 크기를 주장하기보다, 작지만 분명한 병목 하나를 구조적으로 풀어내는 것이 더 효과적입니다. 이 사람이 들어오면 일이 더 복잡해지는 것이 아니라 더 선명해지고 더 빨리 풀린다는 경험이 쌓여야 합니다.<h3 id="364a360d-33e3-8007-a0df-c688fb643344">2. 조율 속에 구조화를 심는다</h3>처음에는 조율 역할만 기대받을 수 있습니다. 괜찮습니다. 다만 거기서 멈추지 않는 것이 중요합니다. 회의를 진행하더라도 무엇을 결정해야 하는지 드러내고, 일정을 관리하더라도 어떤 의존성이 병목인지 보이게 만들면 됩니다. 익숙한 역할 안에서 한 단계 높은 기여를 시작하는 방식입니다.<h3 id="364a360d-33e3-807f-b86a-c3f392c4bd3b">3. 작은 범위에서라도 Owner를 선명하게 만든다</h3>조직 전체가 한 번에 바뀌지 않더라도, 작은 이니셔티브 안에서는 책임 구조를 더 선명하게 만들 수 있습니다. 누가 실질 Owner인지, 어떤 결정은 누가 하는지, 완료 기준은 무엇인지 맞추는 것만으로도 실행 밀도는 크게 달라집니다.<h3 id="364a360d-33e3-807b-8f09-e38ef94b49e4">4. 역할을 설명하기보다 작동 사례를 쌓는다</h3>많은 조직에서 새로운 역할은 정의문보다 사례로 먼저 인정됩니다. 그래서 내가 무슨 역할을 하는 사람인지 길게 설명하기보다, Owner 없는 문제를 끝까지 푼 사례, 반복 병목을 줄인 사례, 여러 팀의 공백을 메운 사례를 만드는 것이 훨씬 강합니다.<h2 id="364a360d-33e3-8053-b3f8-d2b68af052cc">특히 주의해야 할 점</h2>마지막으로, 이 역량을 갖추는 과정에서 조심해야 할 것도 있습니다.첫째, 조율을 낮게 보면 안 됩니다. 조율은 여전히 중요합니다. 다만 조율 자체가 목적이 되면 안 됩니다. 조율은 문제 해결을 위한 수단일 때 가장 강합니다.둘째, 권한이 없다고 영향력까지 없는 것은 아닙니다. 오히려 공식 권한이 약한 환경일수록 신뢰, 구조화 능력, 문제 해결 실적이 더 중요하게 작동합니다.셋째, 너무 빨리 이상형을 강요하면 오히려 방어를 부를 수 있습니다. 중요한 것은 철학을 크게 선언하는 것이 아니라, 지금 환경 안에서 실제로 작동하게 만드는 것입니다.<h2 id="364a360d-33e3-800c-930b-d4f4727dd2e3">결국 남아야 하는 것</h2>이 글을 다 읽고 하나만 기억하시면 좋겠습니다.Cross Functional 기술 문제는 조율만으로 풀리지 않습니다. 문제를 다시 정의하고, 구조화하고, 사람이 움직일 수 있는 실행 구조로 바꾸는 역량이 있어야 비로소 풀립니다.조직 안에는 늘 그런 문제가 있습니다. 모두가 바쁘게 움직이는데도 잘 풀리지 않는 문제, 각자 최선을 다하고 있는데도 전체로 보면 비어 있는 문제, 중요하다는 데에는 동의하지만 끝까지 밀어붙일 사람이 없는 문제 말입니다.그런 문제를 만났을 때 일정표부터 고치기보다, 보고 체계부터 늘리기보다, 먼저 문제를 다시 정의해보면 좋겠습니다. 무엇이 진짜 병목인지, 누가 빠져 있는지, 어떤 구조가 실행을 막고 있는지부터 다시 보는 것입니다.그 순간부터 우리는 단순히 협업을 관리하는 사람이 아니라, 더 중요한 문제를 풀 수 있는 사람에 가까워집니다.</div></div>

토스테크

기술 조직이 커질수록 어려운 문제는 팀 안이 아니라 팀과 팀 사이에 남습니다. 각 팀은 자기 역할을 잘하고 있는데도, 전체로 보면 중요한 공백이 생깁니다. 모두가 중요하다고 말하지만 끝까지 책임지는 사람은 없고, 상태는 계속 공유되는데 현실은 쉽게 바뀌지 않습니다.
이런 문제는 보통 한 영역에서 깔끔하게 다루어지지 않습니다. 인프라의 문제처럼 보였지만 제품의 문제기도 하고, 기술 전략 방향이 잘못 되었을 때도 있고, 운영 방식을 근본적으로 재설계할 필요가 있을 때도 있으며, 때로는 조직 구조와 역할 정의부터 건드려야 할 때도 있습니다. 
Cross Functional, Cross Domain 기술 문제가 생긴 것입니다. 이러한 문제를 푼다는 것은 단순히 협업을 잘하는 것만으로는 안됩니다. 회의를 잘 진행하고, 일정을 잘 관리하고, 리스크를 잘 정리하는데도 문제가 풀리지 않을 때가 있죠. 정말 중요한 것이 빠져서입니다. 흩어진 단서들을 다시 모아, 문제를 재정의하고 조직이 함께 실제로 풀 수 있는 형태로 바꾸는 과정. 이것이 핵심이자 정수입니다. 
토스에서는 TPM(Technical Program Manager)이 이러한 문제를 푸는 역할을 하고 있습니다. 저는 이 글을 통해 토스 TPM이 이 문제를 풀어나갈 수 있는 힘과 방식이 무엇인지 이야기해보려 합니다. 결국 필요한 것은 화려한 기술이 아니라, 중요한 문제를 끝까지 실행시켜 현실의 변화를 일으키게 하는 몇 가지 핵심 역량과 관점입니다. 그리고 토스가 아닌 다른 팀에서도 이 방식을 차용하는 단계적 접근법도 설명해보고자 합니다. 
가장 먼저 기억해야 할 한 문장
Cross Functional 기술 문제는 조율만으로 풀리지 않는다고 믿습니다. 문제를 다시 정의하고, 구조화하고, 사람이 움직일 수 있는 실행 구조로 바꾸는 역량이 있어야 비로소 근본적으로 해결되는 경험을 해왔습니다. 
이 문장이 중요한 이유는, 많은 조직에서 문제 해결을 위해 실제 수행해야하는 액션보다 더 작은 시도들만 하게 되기 때문입니다.
문제가 생기면 흔히 밟은 단계입니다. 
회의를 더 자주 엽니다.
진행 상황을 더 자주 공유합니다.
리스크를 더 촘촘히 정리합니다.
이해관계자를 더 많이 정렬하려고 합니다.
물론 이런 일도 필요합니다. 하지만 이 활동만으로는 문제의 중심에 닿지 못하는 경우가 많습니다. 진짜 병목은 일정표에 적혀 있지 않고, 보고서에도 직접 쓰여 있지 않기 때문입니다. 대개는 결정 구조가 비어 있거나, Owner가 모호하거나, 우선순위가 충돌하거나, 여러 팀이 각자 최선을 다하고 있는데도 전체 구조가 맞물리지 않는 데에 있습니다.
그래서 이 문장을 기억해야 합니다. Cross Funtional 기술 문제를 푼다는 것은 관리의 밀도를 높이는 일이 아니라, 문제를 해결 가능한 구조로 바꾸는 일입니다.
왜 이런 문제가 더 자주 생기는가
조직이 덜 성숙했을 때는 병목이 비교적 선명합니다. 누가 늦는지, 어디서 커뮤니케이션이 끊기는지, 누가 결정을 미루는지 눈에 잘 보이죠.
하지만 조직이 좋아질수록 남는 문제는 달라집니다. 각 팀이 더 잘할수록, 각자의 책임이 더 선명할수록, 오히려 경계 밖의 문제가 더 많이 남습니다. 누구도 틀린 일을 하고 있지 않은데도 전체 최적화가 되지 않는 상태가 생깁니다.
특히 기술 환경이 복잡해질수록 이런 현상은 더 강해집니다.
여러 팀의 시스템과 의존성이 한 번에 얽힙니다.
제품, 인프라, 데이터, 보안, 운영 이슈가 분리되지 않습니다.
단기 대응과 장기 구조 개선이 계속 충돌합니다.
중요한데도 공식 Owner가 없는 회색지대가 커집니다.
그래서 중요한 문제일수록 누군가가 선을 넘고 나서서 새로 정의해야 합니다. 그대로 두면 모두가 보고는 있지만 아무도 풀지 않는, 혹은 풀 수 없는 상태로 오래 남기 쉽습니다.
필요한 역량은 무엇인가
이제 핵심으로 들어가 보겠습니다. Cross Funtional 기술 문제를 풀기 위해 필요한 역량은 많아 보이지만, 사실은 몇 가지 축으로 정리할 수 있습니다.
1. 문제를 다시 정의하는 힘
가장 먼저 필요한 것은 문제 정의 역량입니다.
겉으로 드러난 현상은 대부분 이미 모두가 알고 있습니다. 일정이 밀린다, 협업이 느리다, 우선순위가 자주 바뀐다, 의사결정이 늦다 같은 말은 누구나 할 수 있죠. 하지만 이런 말만으로는 실제 해결이 시작되지 않습니다.
중요한 것은 현상 아래에 있는 진짜 문제를 다시 붙잡는 일입니다.
일정이 왜 밀리는가
어떤 결정이 비어 있는가
누가 Owner여야 이 문제가 해소 되는가
어떤 구조가 반복적으로 공백을 만드는가
문제를 정확히 다시 정의하지 못하면, 조직은 계속 증상만 관리하게 됩니다.
2. 모호함을 구조로 바꾸는 힘
좋은 문제 정의가 끝이 아닙니다. 그 다음에는 여러 사람이 함께 다룰 수 있는 구조로 바꿔야 합니다.
여기서 필요한 것이 구조화 역량입니다. 무엇을 결정해야 하는지, 어떤 선택지가 있는지, 누가 어떤 책임을 져야 하는지, 어떤 순서로 풀어야 하는지를 보이게 만들어야 합니다.
복잡한 문제는 원래 복잡합니다. 하지만 해결되는 문제는 늘 더 단순한 구조로 재정의된 문제입니다. 애매함을 그대로 견디는 사람보다, 애매함을 다룰 수 있는 단위로 쪼개는 사람이 결국 조직을 움직입니다.
3. 무엇이 진짜 중요한지 가려내는 힘
모든 Cross Functional 문제가 같은 무게를 갖는 것은 아닙니다. 어떤 것은 단기 조정으로 충분하고, 어떤 것은 구조적으로 개입해야 합니다.
그래서 전략적 판단력이 필요합니다.
이것이 일시적 이슈인지 반복될 구조적 문제인지
팀 단위에서 풀 수 있는지, 더 넓은 관점이 필요한지
지금 개입해야 하는지, 조금 더 관찰해도 되는지
이 문제를 풀면 조직의 실행 Bar 자체가 올라가는지
중요한 문제를 붙드는 사람은 바쁜 문제보다 큰 문제를 구분할 수 있어야 합니다.
4. 실행이 일어나게 만드는 힘
좋은 문제 정의와 좋은 문서만으로는 현실이 바뀌지 않습니다. 결국 누군가는 사람을 움직이게 해야 합니다. 
여기서 필요한 것은 실행 전환 역량입니다.
누가 움직여야 하는지 명확히 하고
어떤 결정이 먼저 필요한지 정리하고
Blocker를 제거하고
명료하지 못한 논의를 결정 포인트를 드러내고 결정해야 할 담당자가 실제 결정하게 하고, 액션 플랜의 합의를 완료해 실제 액션으로 바꾸는 힘
핵심은 실행을 옆에서 관리하는 것이 아니라, 실행이 실제로 일어나도록 만드는 것입니다.
5. 공식 권한 없이도 움직이게 만드는 힘
Cross Functional 문제는 대개 공식 권한만으로 풀리지 않습니다. 여러 팀의 우선순위가 다르고, 각자의 제약도 다르기 때문입니다.
그래서 영향력과 신뢰가 중요합니다. 상대의 맥락을 이해하고, 서로 다른 언어를 번역하고, 필요한 순간에는 불편한 대화도 열 수 있어야 합니다. 사람들이 이 사람의 말에 시간을 쓰는 이유는 직함이 아니라 판단력과 신뢰여야 합니다.
6. 사람과 구조를 함께 보는 힘
기술 문제처럼 보이는 많은 이슈는 사실 기술만의 문제가 아닙니다. 역할 정의가 애매해서 생기기도 하고, 팀 구조가 현재 문제를 감당하지 못해서 생기기도 하며, 운영 매커니즘이 낡아서 반복되기도 합니다.
그래서 정말 중요한 문제를 다루려면 사람과 구조를 함께 볼 수 있어야 합니다. 프로세스만 바꾸면 해결되는지, 역할을 다시 나눠야 하는지, 리더십의 개입이 필요한지까지 함께 볼 수 있어야 합니다.
한 번 더 요약하면
회의를 더 해야 하나보다, 보고를 더 자주 해야 하나보다, 리스크 표를 더 정교하게 만들어야 하나보다 먼저 아래의 질문을 하는 것이 중요합니다. 
우리가 지금 풀어야 할 진짜 문제는 무엇인가
누가 빠져 있는가
어떤 결정 구조가 비어 있는가
무엇을 바꾸면 실제 실행이 움직이는가
좋은 문제 해결은 활동량이 아니라 질문의 수준에서 시작됩니다.
자율성이 높지 않은 조직에서는 어떻게 시작할까
여기까지 읽으면 이렇게 생각할 수 있습니다. 맞는 이야기이긴 하지만, 우리 조직은 아직 그렇게 자율적이지 않다고요. 권한이 분산되어 있지도 않고, R&R이 선명하지도 않고, 역할 경계 밖으로 나가는 것이 자연스럽지도 않을 수 있습니다.
그렇기 때문에 더더욱 한 번에 이상형을 들이밀기보다, 단계적으로 접근하는 것이 중요합니다.
1. 먼저 작은 문제를 실제로 풀어 신뢰를 만든다
처음부터 역할의 크기를 주장하기보다, 작지만 분명한 병목 하나를 구조적으로 풀어내는 것이 더 효과적입니다. 이 사람이 들어오면 일이 더 복잡해지는 것이 아니라 더 선명해지고 더 빨리 풀린다는 경험이 쌓여야 합니다.
2. 조율 속에 구조화를 심는다
처음에는 조율 역할만 기대받을 수 있습니다. 괜찮습니다. 다만 거기서 멈추지 않는 것이 중요합니다. 회의를 진행하더라도 무엇을 결정해야 하는지 드러내고, 일정을 관리하더라도 어떤 의존성이 병목인지 보이게 만들면 됩니다. 익숙한 역할 안에서 한 단계 높은 기여를 시작하는 방식입니다.
3. 작은 범위에서라도 Owner를 선명하게 만든다
조직 전체가 한 번에 바뀌지 않더라도, 작은 이니셔티브 안에서는 책임 구조를 더 선명하게 만들 수 있습니다. 누가 실질 Owner인지, 어떤 결정은 누가 하는지, 완료 기준은 무엇인지 맞추는 것만으로도 실행 밀도는 크게 달라집니다.
4. 역할을 설명하기보다 작동 사례를 쌓는다
많은 조직에서 새로운 역할은 정의문보다 사례로 먼저 인정됩니다. 그래서 내가 무슨 역할을 하는 사람인지 길게 설명하기보다, Owner 없는 문제를 끝까지 푼 사례, 반복 병목을 줄인 사례, 여러 팀의 공백을 메운 사례를 만드는 것이 훨씬 강합니다.
특히 주의해야 할 점
마지막으로, 이 역량을 갖추는 과정에서 조심해야 할 것도 있습니다.
첫째, 조율을 낮게 보면 안 됩니다. 조율은 여전히 중요합니다. 다만 조율 자체가 목적이 되면 안 됩니다. 조율은 문제 해결을 위한 수단일 때 가장 강합니다.
둘째, 권한이 없다고 영향력까지 없는 것은 아닙니다. 오히려 공식 권한이 약한 환경일수록 신뢰, 구조화 능력, 문제 해결 실적이 더 중요하게 작동합니다.
셋째, 너무 빨리 이상형을 강요하면 오히려 방어를 부를 수 있습니다. 중요한 것은 철학을 크게 선언하는 것이 아니라, 지금 환경 안에서 실제로 작동하게 만드는 것입니다.
결국 남아야 하는 것
이 글을 다 읽고 하나만 기억하시면 좋겠습니다.
Cross Functional 기술 문제는 조율만으로 풀리지 않습니다. 문제를 다시 정의하고, 구조화하고, 사람이 움직일 수 있는 실행 구조로 바꾸는 역량이 있어야 비로소 풀립니다.
조직 안에는 늘 그런 문제가 있습니다. 모두가 바쁘게 움직이는데도 잘 풀리지 않는 문제, 각자 최선을 다하고 있는데도 전체로 보면 비어 있는 문제, 중요하다는 데에는 동의하지만 끝까지 밀어붙일 사람이 없는 문제 말입니다.
그런 문제를 만났을 때 일정표부터 고치기보다, 보고 체계부터 늘리기보다, 먼저 문제를 다시 정의해보면 좋겠습니다. 무엇이 진짜 병목인지, 누가 빠져 있는지, 어떤 구조가 실행을 막고 있는지부터 다시 보는 것입니다.
그 순간부터 우리는 단순히 협업을 관리하는 사람이 아니라, 더 중요한 문제를 풀 수 있는 사람에 가까워집니다.

Cross Functional 기술 문제 풀기 위한 역량 성장 Tip

댓글