- 기술 리더가 운영 총괄로 전환할 때 처음 만나는 실패는 대부분 답이 틀려서가 아니라 납득을 만들지 못해서 생깁니다.
- 기술에서 답을 찾는 방법과 조직이 그 답을 받아들이게 만드는 방법은 완전히 다른 능력입니다. 전환 초기에 두 가지를 혼동하면 혼자 옳은 채로 아무것도 실행되지 않는 상태가 됩니다.
- 운영 총괄의 성과는 본인이 내린 결정의 질이 아니라 조직 전체의 실행 속도와 일관성으로 측정됩니다. 측정 기준이 달라지면 일하는 방식도 달라져야 합니다.
옳은 답이 실행되지 않는 첫 번째 경험
벤 호로위츠는 2014년 '하드씽'(The Hard Thing About Hard Things)에서 기술 출신 CEO가 겪는 전환 충격을 이렇게 묘사했습니다. 기술에서는 문제와 해법이 명확한 피드백 루프 안에 있지만, 경영에서는 결정이 실행되는지 자체가 불분명하다고 했습니다. 실행이 됐는지 확인하는 방법, 실행이 안 됐을 때 그 이유를 파악하는 방법이 기술 영역의 디버깅과 완전히 다릅니다.
기술 조직에서 운영 총괄로 전환한 직후 가장 자주 만나는 장면이 있습니다. 분석을 통해 명확한 결론을 도출하고 전체 회의에서 발표합니다. 팀장들이 고개를 끄덕입니다. 다음 주에 확인하면 아무것도 바뀌지 않았습니다. 문제는 설명이 아니었습니다. 팀장들이 왜 이 방향이어야 하는지를 납득하지 못한 채 회의를 나간 것이었습니다.
납득은 논리만으로 만들어지지 않습니다. 팀장이 이 방향이 내 팀에 어떤 영향을 주는가, 내가 왜 지금 하던 것을 바꿔야 하는가에 대한 답을 스스로 내리지 못하면, 아무리 좋은 분석도 행동으로 연결되지 않습니다.
기술 능력이 운영에서 방해가 되는 세 가지 경우
첫째는 최적해 집착입니다. 기술에서는 더 나은 알고리즘이 있으면 교체하는 것이 맞습니다. 운영에서 현재 프로세스보다 좋은 방법이 있다는 사실만으로 변경을 밀어붙이면 팀 전체의 학습 비용과 저항이 생깁니다. 70점짜리 현실 가능한 방법이 90점짜리 실행 불가능한 방법보다 낫습니다.
둘째는 데이터 의존입니다. 기술 결정에서는 근거가 불충분하면 더 모아야 합니다. 운영 결정에서는 데이터가 충분하지 않아도 결정을 내려야 하는 상황이 빈번합니다. 데이터가 더 필요하다는 말이 운영 팀장에게는 결정을 피한다는 신호로 읽힙니다.
셋째는 혼자 해결하려는 경향입니다. 기술에서 뛰어난 개인은 혼자 빠르게 문제를 풀 수 있습니다. 운영에서 총괄이 혼자 빠르게 문제를 해결하면 팀은 그 방식을 학습하지 못합니다. 총괄의 가치는 문제 해결 속도가 아니라 조직이 스스로 문제를 해결하는 능력을 만드는 것입니다.
전환 초기 6개월에 달라져야 할 것
Ahn Partners 판단: 이 글은 기술 리더에서 운영 총괄로 전환한 실제 경험을 바탕으로 씁니다. 아래는 통계 연구가 아닌 실행자 관찰입니다.
첫째, 결정을 내리는 것보다 결정이 실행되는지를 추적하는 데 더 많은 시간을 씁니다. 이 결정이 현장에서 어떻게 번역됐는가를 확인하는 루프를 만드는 것이 첫 번째 과제입니다.
둘째, 팀장들이 납득하는 속도를 기술 결정의 배포 속도와 같다고 생각하지 않습니다. 조직이 새 방향을 받아들이는 데는 반복적 노출과 자기 언어로의 재해석 시간이 필요합니다. 이것을 느리다고 보지 않고, 실행 전에 납득이 필요한 비용으로 보는 관점이 필요합니다.
셋째, 자신이 가장 잘 이해하는 기술 영역에서는 의도적으로 뒤로 물러납니다. 기술 문제를 운영 총괄이 직접 해결하면 기술팀의 자율성이 줄어들고, 총괄은 기술 업무와 운영 업무 모두에서 병목이 됩니다.
점검 목록
- 최근 한 달 동안 운영 방향 결정 후 팀이 실제로 실행에 옮긴 비율은 어느 정도인가
- 팀장들이 새 방향을 납득하는 데 걸리는 시간을 의도적으로 설계에 포함했는가
- 기술 전문성을 직접 발휘하는 일과 조직이 스스로 실행하도록 돕는 일을 구분해서 시간을 배분하고 있는가
출처
- Horowitz, B. (2014). The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers. HarperCollins.
- Kotter, J. P. (1996). Leading Change. Harvard Business School Press. 조직 변화에서 납득과 실행의 순서.
- Lencioni, P. (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass.
개발자 출신 팀장이 처음 6개월을 버텨내는 방법은 처음 팀장이 된 개발자가 가장 먼저 잃는 것은 기술이 아닙니다에서 이어집니다.