개요
다른 사람의 업무를 직접 해낼 수 있는 능력은, 그들이 어떻게 일하고 무엇을 필요로 하는지 배우게 해주며, 담당자가 하지 않는 일을 끝내야 할 때 특히 유용하다. 이 글은 그 행동이 왜 철학적으로는 “비틀린 자선”처럼 보이지만, 실제로는 조직이 최종 목표에 도달하는 데 필요한 소수의 행동이라는 관점을 다룬다. 동시에 남의 일을 돕는 것과, 이와 비슷해 보이지만 전혀 다른 동기(인원 확대, 관리 편의)로 진행되는 자체 개발·부서별 중복 구축을 구분해야 한다고 지적한다.
링크
- 원문: https://yosefk.com/blog/doing-everyone-elses-job.html
- 정리 스레드: https://news.hada.io/topic?id=33793
- 관련: Dan Luu — Nothing works
- 참고: Scaled Agile Framework
다른 사람의 일을 직접 끝내기
- 새로 만든 것을 대상 사용자들이 도입하지 않는다면, 그들의 시스템에 직접 통합하는 방법이 있다. Intel이 첫 32비트 CPU를 만들었을 때, 자사 인력을 투입해 Microsoft 컴파일러에 해당 CPU 지원을 추가한 사례가 그 예다. 남의 시스템에서 일하는 것을 불필요한 자선처럼 볼 수 있지만, 실제로는 그 성공으로부터 자신도 이익을 얻기 위한 행동일 수 있다.
- 관리자가 실질적으로 관리하지 않더라도, 그 조직의 구성원과 직접 협력해 사실상 업무를 조율할 수 있다면 일을 진행할 수 있다. 이를 “관리”라고 부르거나 자기 공으로 내세우지 않고, 협업을 역할로 받아들이는 사람을 찾아 함께 일하는 방식이다.
- 위계에서 내려온 지시만 따르는 구성원도 많지만, 그 밖의 필요한 일에도 나서는 사람이 남아 있을 수 있다.
- 사용하는 제품에 필요한 기능이 있다면, 개발 일정에 넣어달라고 요청하기보다 직접 작성한 패치를 받아들이도록 설득하는 편이 더 쉬울 때가 많다. Scaled Agile 계획 절차에서는 이번 분기와 다음 분기 일정이 이미 확정돼 있고, 다다음 분기 기능들과 우선순위를 비교하려면 몇 주를 기다려야 할 수 있다.
- 정성 들인 패치도 언뜻 보면 무작위 LLM 출력처럼 보일 수 있어, 최근에는 병합이 더 어려워졌을 수 있다. 다만 상대가 기여자를 알게 되면 문제가 줄어들 수 있다.
조직의 빈틈을 메우는 사람과 그 보상
- 20%가 80%의 일을 한다는 통념보다 더 나아가, 그 일이 최종 목표에 도달하는 것은 남의 미완료 업무까지 맡는 5% 미만의 사람들 덕분이라는 관점.
- 담당자가 일을 하지 않는 이유는 조직 내부 논리로는 정당할 수 있다. 그러나 그런 정당한 이유가 누적되면 조직 전체를 무너뜨릴 수 있다.
- 이런 개입이 필요할 만큼 상태가 나쁘지만, 기여를 결국 인정할 정도로는 건강한 조직이라면, 남의 일까지 수행한 데 대한 직접·간접 보상을 기대할 수 있다. 대부분의 조직에는 이런 개입이 필요하며, 가치를 인정할 수조차 없다면 이미 존립이 위태롭다고 본다.
- 조직이 실제로 어떻게 움직이고 무엇을 해야 일이 끝나는지 이해하는 소수가 되는 데서 오는 간접적인 보상도 있다.
- 자기 업무와 거리가 멀거나 지루하다는 이유로, 충분히 배울 수 있었던 분야에 들어가지 않은 것은 돌이켜보면 후회로 남을 수 있다. 남의 일이 저절로 끝날 것이라고 기대하다가 예방 가능한 문제에 빠지면, 그 일은 더 이상 지루하지 않지만 손쓰기엔 너무 늦을 수 있다.
남을 돕는 것과 별도로 대체하는 것은 다름
- 남의 일이 끝나도록 돕는 것과, 같은 일을 별도로 하거나 대체하는 것은 구분해야 한다. 고위 직급자들은 후자를 “비틀린 자선”으로 거부하기보다, 인원을 늘릴 수 있다는 이유로 선호할 수 있다.
- 대표적인 두 경우는 외부 제품 대신 자체 개발하기와, 중앙 서비스 대신 부서마다 별도로 구축하기다.
구매와 자체 개발의 판단
- 어떤 조직은 구매나 표준 무료 버전 활용 대신 자체 개발을 지나치게 많이 하고, 다른 조직은 품질이 나빠도 외부 제품을 선호한다.
- 외부 제품을 선호하는 쪽에서는 표준이 좋다는 믿음이나, 채용보다 지출이 쉽다는 사정이 작용할 수 있다. 자체 개발을 선호하는 쪽에서는 비용 승인은 거의 불가능하지만 인원을 늘리기는 상대적으로 쉬운 사정이 작용한다.
- 구매와 개발 중 선택은 조직에서 가장 하기 쉬운 행동이 아니라, 기대 결과를 개선하는 방향으로 해야 하는 어려운 결정이다. 사례별 세부사항을 충분히 파악하고, 자체 역량의 결함, 공급업체 후보의 결함, 시장의 구조적 문제를 정직하게 비교해야 한다.
중앙 서비스와 부서별 구축의 판단
- 회사 전체가 하나의 서비스를 쓰는 대신 부서마다 같은 일을 별도로 수행하는 방식도 흔하다.
- 부서장은 자신에게 보고하지 않는 조직에 대한 의존을 하나 줄일 수 있어 이를 선호한다. 상위 관리자는 중앙 서비스 조직이 정말 제 역할을 못하는지, 어떻게 고쳐야 하는지, 아니면 다른 부서가 자기 실패를 돌리는 것인지 따질 필요가 없어져 이를 선호한다.
- 전사 표준화와 부서별 구현 중 선택 역시 어려운 판단이며, 고위 경영진에게 편한 방식과 실제로 더 나은 결과를 내는 방식은 구분해야 한다.
직접 해본 업무의 채용 가치와 관리 능력의 한계
- 채용하려는 사람의 업무를 직접 해본 경험은 좋은 채용에 도움이 될 수 있다. 일부 창업자는 이것을 회사를 처음부터 키워보는 경험의 장점으로 본다.
- 판단력이 좋다고 평가된 성공한 두 번째 창업자도, 직접 해본 업무의 인력을 채용하기가 훨씬 쉽다고 말한다. 해당 업무를 해본 적절한 사람을 신뢰할 수 있다면 같은 가치를 얻을 수도 있지만, 경험상 누구를 신뢰할지 잘못 판단하는 경우가 더 많다고 본다.
- 직접 업무를 해본 경험의 효용에는 공감하되, 회사를 직접 확장해 검증한 경험은 없다는 단서가 붙는다.
- 팀을 키울 때는 자신보다 해당 업무를 잘하는 사람을 관리할 줄 안다는 조건 아래 도움이 되지만, 팀이 수백 명으로 커지면 자신이 할 수 없는 업무를 맡은 사람이 생긴다. 여러 팀 중 하나가 아니라 독립 회사라면 그런 상황이 훨씬 빨리 온다.
- 결국 자신이 수행할 수 없는 업무의 담당자를 관리하는 능력이 부족하면 성장의 제약이 될 수 있다. 이 능력은 직접 일을 해본 경험을 보완하지만, 익히기 쉽지 않다.
토론에서 나온 관점
- 관리자가 이런 일을 하는 직원을 공식적으로 벌주지 않더라도, 그 일을 업무로 인정하지 않는 것 자체가 불이익이다. 정리·정돈, 불편을 해결하는 일은 평가에서 사실상 0점에 가깝다.
- 대기업(1,000명 이상)에서는 대체로 정해진 틀 안에서 움직이는 편이 낫고, 200명 미만의 작은 조직이나 창업에서는 담당보다 효과 기준으로 움직이기 좋다. 중간 규모는 조직 문화와 경영진을 살펴야 한다.
- 회사의 가치를 떠받치는 사람들이 정작 경영진에게는 과소평가되고, 경력 발전이 눈에 띄는 프로젝트를 맡은 사람보다 훨씬 뒤처지는 경우가 있다는 경험담이 있다.
- 일본 기업의 1~2년 단위 순환근무는 전사 이해를 높이고 부서를 사유화하지 않으려는 취지로 작동했지만, 관리 비용과 경직성, 전문가 양성에 시간이 많이 든다는 한계도 있었다.
- 다른 팀의 본업을 무시하고 만만한 사람에게 자기 일을 떠넘기는 경우가 실제 회사에서는 더 흔하다는 지적도 있다. 다른 팀을 돕는 것은 좋지만, 들어오는 요청과 시간을 자기 관리자에게 알려야 한다.
- 초대형 기업의 중앙 AI 플랫폼 사례처럼, 단일 플랫폼에 강제하면 사용자별 요구사항과의 불일치가 커지고, 어느 쪽이든 사용자에게 불리해질 수 있다.
- 여러 부서를 직접 둘러보는 활동을 통해 제품·고객지원·마케팅에 대한 관점을 얻는 사람도 있고, 온보딩에 넣는 경우도 있다. 다만 온보딩에서 부작용 없이 설계하는 것이 관건이다.
- 다른 사람의 일까지 할 줄 알면 영향력이 늘고, 문제를 어디서 어떻게 풀어야 하는지 알게 된다. 다만 상사는 하라고 남이 시키는 것을 다 하지 말고 거절하는 법을 배우라고 조언하기도 한다.
관련 페이지
- automation — 자동화에 대한 상위 개념 페이지
- moc-ai-agents — AI 에이전트 관련 노트 모음 MOC