반복 갈등을 위한 cross-functional alignment ritual 만들기(Build a cross-functional alignment ritual for recurring conflicts)

반복되는 갈등은 성격 문제가 아니라 거버넌스 공백이다

엔지니어링과 제품, 혹은 제품과 영업 사이의 같은 싸움이 매 planning cycle마다 반복된다면, 문제는 누가 까다로워서가 아니라 그 종류의 긴장을 해결할 팀 간 원칙이 없다는 데 있습니다. 모든 사례를 개별 debate로 다루면 시간만 낭비하고 신뢰만 깎입니다. 반복 긴장을 표면화하고, 이를 미리 해결하는 원칙을 이름 붙이고, 새로운 사례는 서면 로그와 함께 escalation하는 ritual이 바로 이 순환을 끊는 거버넌스 레이어입니다.

이 프롬프트의 작동 방식

이 프롬프트는 네 단계로 진행됩니다. Surface 단계에서는 각 기능에서 2-3명씩 인터뷰해, 매 사이클마다 반복될 갈등을 무엇으로 느끼는지 묻습니다. 그러면 긴장이 예외가 아니라 반복 패턴의 일부라는 사실이 드러납니다. Principles 단계에서는 각 긴장마다 1문장짜리 해결 원칙을 미리 씁니다. 다음 번에는 같은 갈등이 다시 fresh debate로 번지지 않게 하기 위해서입니다. Install 단계에서는 각 기능이 최근 긴장 1개씩을 가져와 원칙에 비춰 해결하는 45분짜리 월간 alignment review를 설치합니다. Governance 단계는 분기 리뷰와 신규 입사자 온보딩을 통해 principles doc을 최신 상태로 유지하게 합니다.

여기서 핵심은 escalation path입니다. 첫 arbiter, director로 올리는 조건, 서면 결정 로그가 있어야 결정력이 유지됩니다. 이것이 없으면 새로운 긴장은 몇 주씩 공중에 떠다니는 논쟁으로 남고, 이것이 있으면 48시간 안에 문서화된 결정으로 수렴합니다.

언제 사용할까

• 같은 팀 간 갈등이 매 planning cycle마다 반복될 때
• Director 수준에서 해결할 수 있는 문제가 VP까지 escalate되고 있을 때
• 새 제품 조직이 형성되며 cross-functional working pattern이 아직 흔들릴 때
• 새 VP of Product가 거버넌스 ritual을 설치하고 있을 때
• Product와 engineering(혹은 product와 sales) 사이의 신뢰가 구조적으로 약해졌을 때

흔한 함정

• 실제로 갈등을 해결하지 못하는 원칙. "커뮤니케이션을 더 잘하자"는 원칙이 아닙니다. 원칙은 "mid-cycle에 scope를 추가하지 않는다"처럼 논쟁 자체를 끝내는 구체적 규칙이어야 합니다.
• 서면 결정 로그가 없는 것. 말로 끝난 합의는 사라지고, 같은 논쟁이 다시 돌아옵니다. 반드시 적어 두세요.
• 분기별로만 ritual을 돌리는 것. 긴장은 빠르게 누적됩니다. 월간 cadence여야 곪기 전에 잡을 수 있습니다.

참고 자료

• Begin with Trust — Harvard Business Review
• The Feedback Fallacy — Harvard Business Review
• Google re:Work — Google
• Ten Principles of Product Teams — Silicon Valley Product Group