조직 설계가 만든 다른 선택
직전에 개발팀 안에서 남탓과 팀묵이 반복되는 구조를 바라봤다면, 이번엔 이 시선을 조직 바깥으로 조금 더 넓혀보려 한다. 개발자들이 왜 늘 앞에 서서 책임을 지게 되는지, 그리고 왜 어떤 팀들은 같은 지연 앞에서도 상대적으로 안전한 위치에 머무를 수 있는지 말이다.
대기업의 제품개발 조직에는 흔히 ‘Staff 조직’이라 불리는 팀들이 있다. 품질, 구매, 생산기술과 같은 조직들이다. 이들은 개발을 돕는 역할을 하며, 공식적으로는 제품 관련 의사결정권 보다는 지원과 검증의 기능을 수행한다. 하지만 개발을 마무리하기 위해 반드시 통과하는 게이트는 대부분 이 조직들에 의해 관리된다.
문제는 이 구조에서 일정이 지연되었을 때다. 개발팀에게 일정은 KPI(Key Performance Indicator)이자 책임이지만, Staff 조직에게 일정은 필수가 아니다. 같은 지연을 두고도 어떤 팀은 책임을 설명해야 하고, 어떤 팀은 ‘나의 할 일은 다 했다.’는 말로 넘어갈 수 있다. 이 비대칭은 협업의 태도가 아니라, 행동의 방향을 결정하는 조직 구조 설계에 가깝다.
Staff 조직을 비판하기 위함이 아니다. 오히려 각 조직이 자신의 역할을 충실히 수행하고 있으며 합리적으로 행동하고 있다고 생각하지만, 책임이 ‘어디에 먼저 쌓이도록 설계되어 있는가’의 문제를 정리해보려 한다.
1. Staff의 권한
Staff 조직은 보통 “현업을 지원하고, 전문성을 제공하는 조직”이다. 아주 좋은 조직이지만 구조를 보아야 한다. Staff 조직은 대부분 의사결정권은 없다고 하지만, 실제로는 프로젝트의 흐름을 멈출 수 있는 권한을 가지고 있다. 각 부품과 완제품의 품질 승인, 협력업체 선정과 재료비, 생산기술 검토, 서비스성 검토 등. 각 수문장은 회사에서 세운 표준에 맞춘 조건들을 맞춰오라면서 개발을 물러나게 한다. 그들의 결정은 간접적이나, 영향은 직접적이며 그 결정의 결과에 대한 설명과 부담은 개발팀으로 수렴된다.
2. 일정은 개발만의 KPI이다.
개발은 QCD 중 D를 가장 먼저 떠올린다. 개발일정이 빠르면 빠를수록 회사는 신제품을 생산해서 판매할 수 있고 곧바로 영업이익을 볼 수 있는 구조이기 때문이다.
여기서 흥미로운 점은 일정이 늦어져도 그 지연의 책임이 Staff 조직의 KPI로 직접 연결되는 경우는 거의 없다. 일정은 종종 빠져 있거나 낮은 비중으로 들어간다. 그들은 제품이 그들만의 조건을 만족하는지 확인만 하면 된다. 같은 지연이어도 각 조직이 느끼는 압박은 전혀 다르다.
- 개발: 이번 평가에 영향이 갈까?
- Staff: 이 제품은 아직 gate 통과 못 시켜.
3. 설계도, 책임도 개발이 맡게 된다.
그렇기에 개발팀은 Staff 조직이 이해하기 쉽게 문제의 원인을 면밀하게 분석하고, 설계 의도를 정리해 설명하고, PPT로 정리하여 공유하는 각종의 프로세스가 있다. 필요한 정보와 분석이 충분히 제공되지 않으면, 해당 이슈는 자연스럽게 개발만의 책임으로 귀속된다. 결국 ‘문제는 개발이 정리하는 것’이라는 기대를 학습하게 된다. 반면 다른 조직은 판단의 주체이면서도, 그 판단에 대한 설명의 주체에서는 빠진다. 품질이 issue의 현상만 확인해주면, 개발이 원인분석과 설계수정 및 재발방지 대책을 수립해야 하는 것처럼.
단기적으로 보면 가장 잘 아는 사람이 맡는 것이 효율적으로 보인다. 하지만 이 선택이 반복되면서, 조직은 ‘잘하는 사람이 더 떠안는 구조’를 학습하게 된다. 이 방식은 문제를 빠르게 해결하지만, 문제를 다룰 수 있는 사람을 늘리지는 못한다.
문제가 반복될 때 우리는 누구의 태도와 책임을 먼저 떠올릴까. 개인의 책임일까, 아니면 그렇게 판단하게 만든 구조일까. 개발이 문제를 끝까지 끌어안고, staff는 ‘결정에 관여했지만 설명하지는 않는’ 위치에 머무는 조직에서 이 선택은 개인의 성향이 아니라 가장 안전한 생존 전략이었을지도 모른다.
그렇다면 우리가 바꿔야 할 것은 사람의 자세일까, 아니면 문제가 드러나는 순간 이후의 의사결정과 책임이 배치되는 방식일까.
조직이 달라지려면, 책임을 더 강하게 묻는 방식보다 과정을 어떻게 평가하고 설명하게 만들 것인가를 먼저 설계해야 한다. 결과가 아니라 과정을 평가한다는 것은, “누가 실패했는가”가 아니라 “어떤 판단이 어떤 정보 위에서, 어떤 논의 과정을 거쳐 내려졌는가”를 묻는 것이다.
이 질문이 가능해질 때, 개발은 문제를 혼자 해결하는 집단이 아니라 staff와 함께 문제를 해석하는 주체가 되고, staff는 결정에 참여한 사람으로서 결과에 대해 공동으로 설명하는 위치에 서게 된다.
조직문화는 태도를 바꾸라는 선언으로 만들어지지 않는다.
사람들이 어떤 선택을 하게 되는지를 바꾸는 평가 기준의 설계에서 시작된다.