남의 일을 대신 끝내는 능력과 넘지 말아야 할 선

TL;DR

• 내 결과물이 쓰이려면 다른 사람의 일까지 끝내야 할 때가 있다. 상대 시스템에 직접 통합하거나 필요한 기능의 패치를 보내면 도입과 일정의 병목을 풀 수 있다. 목적은 선행이 아니라 공동의 결과를 완성하는 데 있다.
• 담당자마다 일을 미루는 이유가 정당해도 전체 조직은 실패할 수 있다. Kreinin은 그 빈틈을 메우는 사람이 성과와 조직 이해를 얻는다고 본다. 다만 기여를 알아볼 만큼 조직이 건강해야 보상도 기대할 수 있다.
• 남의 일을 끝내주는 것과 같은 일을 따로 만드는 것은 다르다. 자체 개발과 부서별 서비스는 인원 확대나 관리 편의 때문에 선택되기도 한다. 구매와 개발, 공통화와 분산은 각 대안의 결함과 예상 결과로 판단해야 한다.
• 직접 해본 일은 채용과 팀 운영을 판단하는 데 도움이 될 수 있다. 그래도 조직이 커지면 리더가 수행할 수 없는 직무가 생긴다. 그때는 자신이 대신할 수 없는 사람을 관리하는 능력이 필요하다.

Yossi Kreinin은 새로운 것을 만들어도 정작 사용할 사람들이 도입에 나서지 않는 상황에서 출발한다. 이때 상대가 움직이기를 기다리는 대신 상대 시스템에 직접 통합하는 방법이 있다. 그가 만난 Intel 팀 관계자는 Intel이 첫 32비트 CPU를 만들었을 당시 Microsoft 컴파일러에 해당 CPU 지원을 추가하는 작업에 참여했다. 이 사례에서 상대의 일을 맡는 행위는 Microsoft를 돕는 자선이 아니라 자사 CPU가 활용될 조건을 만드는 일이었다.

맡은 일의 경계를 넘으면 막힌 일정이 풀린다

협업 상대의 기능 개발 일정도 비슷한 병목을 만든다. 필요한 기능을 개발 계획에 넣어 달라고 요청하는 것보다 직접 구현한 패치를 받아 달라고 설득하는 편이 쉬울 때가 있다. Kreinin은 이번 분기와 다음 분기의 계획이 이미 확정돼 다음다음 분기의 우선순위부터 논의해야 하는 Scaled Agile 계획 절차를 풍자한다. 요청을 대기열에 추가하는 대신 구현물을 가져가면 상대에게 필요한 결정이 개발 일정 배정에서 변경 사항 수용으로 바뀐다.

패치를 보낸다고 모든 장애가 사라지지는 않는다. Kreinin은 최근 들어 신중하게 만든 패치도 첫눈에는 무작위 LLM 출력과 구별되지 않아 병합이 더 어려워졌을 수 있다고 우려한다. 그는 상대가 기여자를 알게 되면 이 문제를 넘을 수 있다고 본다. 기능을 대신 구현하는 능력과 함께 자신이 만든 변경을 믿고 검토할 수 있는 관계도 필요하다.

정당한 사유가 쌓여도 전체 결과는 실패할 수 있다

관리자가 실질적인 조정을 하지 않을 때는 그 조직 안에서 협업할 사람을 직접 찾는 길도 있다. Kreinin은 관리 권한을 내세우거나 공을 요구하지 않은 채 사실상 일을 조율하는 방식을 권한다. 위계에서 내려오는 지시만 따르는 사람도 있지만 공동 작업에 응하는 사람도 남아 있다. 이 사례의 초점은 관리자를 공식적으로 대체하는 데 있지 않고 멈춘 일을 실제로 진행할 상대를 찾는 데 있다.

Kreinin은 일의 80%를 20%의 사람이 수행한다는 통념보다 더 좁은 집단에 주목한다. 그가 보기에 최종 목표를 가능하게 하는 사람은 남이 맡았으나 하지 않는 일까지 처리하는 5% 미만의 사람들이다. 이 비율은 조사 결과가 아니라 저자의 조직관을 드러내는 표현이다. 각 담당자에게는 조직이 인정하는 타당한 미실행 사유가 있어도, 그런 사유가 누적되면 전체 조직의 생존을 해칠 수 있다.

보상에 관한 주장에도 조건이 붙는다. 남의 일까지 떠맡아야 할 만큼 문제가 있으면서도 그 기여를 언젠가는 알아볼 만큼 건강한 조직이라야 보상을 기대할 수 있다. Kreinin은 조직이 실제로 어떻게 돌아가고 무엇을 해야 일이 끝나는지 이해하는 것 자체도 간접적인 보상으로 본다. 자신의 업무와 멀거나 지루하다는 이유로 배울 수 있었던 영역을 외면한 일을 후회하는데, 남의 일이 저절로 끝나리라 믿었다가 예방 가능한 문제에 빠졌을 때는 이미 늦을 수 있기 때문이다.

대신 끝내주는 일과 중복해서 만드는 일은 다르다

자체 개발은 앞선 사례와 구분해야 한다. 누군가의 일을 끝내주는 대신 구매 가능한 제품이나 표준적인 무료 대안과 비슷한 것을 사내에서 따로 만드는 선택이기 때문이다. 어떤 조직은 표준을 선호하거나 채용보다 지출 승인이 쉽다는 이유로 품질이 나쁜 외부 제품까지 구매한다. 반대로 지출 승인은 어렵고 인원 확대는 쉬운 조직은 자체 개발을 지나치게 늘릴 수 있다.

이런 사정은 선택이 쉬운 이유를 설명할 뿐, 결과가 좋은 이유를 보장하지 않는다. 구매와 개발을 비교하려면 내부 역량의 결함뿐 아니라 후보 공급업체의 결함과 시장의 구조적 문제까지 알아야 한다. Kreinin은 어느 한쪽을 보편적인 정답으로 제시하지 않는다. 조직 안에서 승인받기 편한 경로와 실제로 나은 결과를 낼 경로를 따로 판단하는 것이 이 대목의 기준이다.

부서마다 같은 서비스를 따로 운영하는 선택에도 관리자의 이해관계가 작용한다. 부서장은 자기에게 보고하지 않는 다른 조직에 의존하지 않아도 되므로 이를 선호한다. 상위 관리자는 중앙 서비스 조직이 정말 실패했는지, 아니면 다른 부서가 자기 실패를 설명하려고 핑계를 대는지 조사하고 해결할 부담을 피한다. 그렇다고 공통 서비스가 언제나 우월한 것은 아니며 전사 표준화와 부서별 운영 역시 관리 편의와 예상 결과를 구분해 따져야 한다.

직접 할 줄 아는 능력만으로 조직을 키울 수는 없다

초안을 검토한 Dan Luu는 자신이 해본 직무의 사람을 더 잘 채용할 수 있다는 창업자들의 견해를 덧붙였다. 신뢰할 만한 경험자를 곁에 두는 방식도 비슷한 도움을 줄 수 있지만 누구를 믿을지 잘못 판단할 가능성이 남는다. 이 대목은 직접 업무를 수행하는 경험이 채용 판단에도 도움이 될 수 있다는 추론이다. Kreinin은 그럴듯하다고 받아들이면서도 자신이 회사를 키워 이 주장을 확인한 경험은 없다고 선을 긋는다.

팀을 키우는 상황에서는 자신보다 일을 잘하는 사람을 관리할 수 있다는 조건 아래 직접 경험이 도움이 된다는 것이 그의 판단이다. 그러나 팀이 수백 명으로 커지면 리더가 수행할 수 없는 직무를 맡은 사람이 생기며 독립 회사에서는 그 상황이 훨씬 빨리 온다. 그 단계에서는 남의 일을 직접 해내는 능력만으로 운영의 한계를 해결할 수 없다. 자신이 도저히 대신할 수 없는 업무를 맡은 사람을 관리하는 능력이 부족하면 그것이 성장의 제약이 된다.

참고 자료

Doing everyone else’s job — Yossi Kreinin