관리자가 이런 직원을 벌주지 않는다는 건 틀린 말임. 그 일을 업무로 인정하지 않는 방식으로 벌을 줌. 조직의 빈틈을 메우고, 주변을 정돈하고, 모두가 참고 무시하던 골칫거리를 처리해도 성과평가에서는 거의 0점임. 시간은 한정돼 있고, 그만큼 눈에 띄거나 정치적으로 유리하거나 보상받을 만한 일을 못 하기 때문임.
내 경험상 직원 1,000명 이상인 대기업에서는 대체로 정해진 틀에 맞춰야 함. 200명 미만의 작은 회사나 자영업·창업 환경에서는 누구 담당인지보다 노력 대비 효과가 가장 큰 일을 좇는 편이 좋음. 그 사이 규모에서는 조직 문화와 경영진을 살펴야 함.

내 경력에서 적어도 두 명은 사실상 회사를 지탱하는 기둥이었음. 허울 좋은 프로젝트에 시간을 쓰지 않고, 회사를 굴리는 데 꼭 필요한 궂고 주목받지 못하는 일을 매일 해냈음.
경영진은 이들을 터무니없이 저평가했고, 경력 발전도 눈에 잘 띄는 프로젝트를 맡은 이들보다 훨씬 뒤처졌음.

미디어 기술 분야에서 일한 지난 10년간 가장 좋은 평가를 받은 건, 남이 대충 처리하다 낸 사고에 달려들어 초보적인 오용을 바로잡았을 때였음.
정작 가장 영웅적인 작업은 고장 나면 주 작업실 전체가 멈추는 노후 장비를 PCB 수준에서 수리한 일이었음. 상사는 그 장비가 무슨 일을 하는지도 이해하지 못했고, 이후 새 장비로 교체해 달라는 요청도 거듭해야 했음. 눈에 띄는 일과 실제로 중요한 일은 자주 다르며, 해당 분야를 모르면 더욱 구분하기 어려움.

회사가 중요성을 인정하지 않는다면 그냥 고장 나게 놔둬야 함. 그래야 경영진이 제대로 관심을 기울임.

일본 기업에서 일할 때 인사 정책의 큰 축은 1~2년 단위의 순환근무였음. 한 회사에서 평생 일하니 가능한 방식이었고, 이후에는 한곳에 더 오래 머물며 전문성을 쌓았음.
코딩·문서 작성 방식과 도구도 표준화했고, 전 직원이 정기적으로 교육받았음. 숙련자를 신속히 재배치하면서 자기 일이 전체 시스템에서 어떻게 쓰이는지 이해하게 하려는 목적이었음.
대체로 효과가 있었지만, 특유의 문화에 의존했고 상당한 관리 비용과 경직성을 낳았으며 전문가 육성에도 오래 걸렸음. 개인적으로는 지금도 새로운 것을 배우고, 어떻게 해야 할지 모르는 프로젝트를 맡는 걸 즐김. 관련해서 쓴 글도 있음. https://littlegreenviper.com/miscellany/thats-not-what-ships....

일본의 종합직(総合職) 으로 중간관리자 후보가 되면 3년마다 이동하는 게 흔한 정책임. 이론적으로는 부서의 사유화를 막고, 인맥과 조직 이해를 넓히며 작은 성과를 쌓게 해줌.
이 답답한 정책은 슈퍼마켓 관리자, 전국 지점망을 둔 중견기업, 공립학교 교사와 군인을 제외한 다른 공무원에게도 적용됨. 초등학교 교사는 자기 학생들의 졸업을 못 볼 가능성이 큼.

1990년대 UPS는 유망한 신입 직원을 관리자로 키우는 데 많은 노력을 들였음. 좋은 관리자는 어느 부서든 관리할 수 있다고 보고 여러 근무지로 이동시켰고, 배송 기사 출신도 많았음.
이런 관리자들이 사내외 소프트웨어 개발·지원과 여러 헬프데스크를 맡는 IT 부서에 배치되면 꽤 흥미로운 상황이 벌어졌음.

이 방식은 종신고용에도 의존하므로 노사 양쪽 모두 큰 문화적 전환이 필요함. 직원은 사업상의 문제를 고치기보다 퇴사하는 데 익숙하고, 기업은 직원을 대체할 수 있다는 이유로 함부로 대하는 데 익숙함. 지금 문화는 이를 시도할 수 있는 수준과도 거리가 멂.

체코 의사들도 약 2년 반 동안 병원 부서를 의무적으로 순환함.

어머니가 Cisco에서 비기술직으로 30년간 일했는데, 거기도 이런 방식이었음. 여러 팀에서 일반 실무자로, 이후에는 관리자로 각각 3~5년씩 근무했음.

다른 팀 관리자를 건너뛰고 그 팀 직원에게 일을 시키는 행동을 관리자와 순진한 직원 양쪽 입장에서 겪어봤음. 내 경우에는 예외 없이 상대 팀의 원래 업무에는 관심 없이 만만한 사람에게 자기 일을 떠넘기려는 행동이었음. “저 관리자는 아무 일도 안 한다”는 비난도 대개 그 팀이 무슨 일을 하는지 이해하려 하지 않는 다른 팀에서 나왔음.
좋게 해석하면 노는 인력을 조직 전체를 위해 활용한다는 뜻이겠지만, 실제로는 오만한 관리자가 부탁을 거절하지 못하는 직원들에게 자기 일을 분산시키는 경우가 대부분이었음.
남을 돕고 싶어 하는 좋은 동료들을 많이 채용하고 함께 일했지만, 이런 사람들은 찾아오거나 메시지를 보내 다른 일을 부탁하는 이들에게 쉽게 휘말림. 반복되면 자기 업무가 밀리고, 또 다른 팀 일을 떠맡지 않았는지 거의 매일 확인해야 할 정도가 됨.
여유가 있을 때 다른 팀을 돕는 건 좋지만, 들어온 요청과 소요 시간을 자기 관리자에게 알려야 함. 모든 부탁을 들어주느라 과로하면서 정작 자기 팀의 진척을 막는 사람이 되어서는 안 됨.

상대방의 원래 업무에 관심이 없다는 건 맞지만, 그게 반드시 나쁜 것처럼 말하고 있음. 결국 각자 자기 시간을 관리해야 함. 모두가 지휘계통과 예정된 우선순위만 신경 쓰면 전체 효율은 급락함. 조직도 밖의 작은 협력만으로 얻을 성과도 위원회와 프로그램 관리자 검토를 거치다 사라질 수 있음.
착취적인 관계가 생길 수 있다는 건 이해하지만, 생산적인 운영을 방해하는 실패 유형은 여러 가지이므로 더 큰 차원에서 균형을 잡아야 한다고 봄.

중앙집중화에는 동의하지 않음. 지금 초대형 기업의 중앙 AI 플랫폼을 만드는 프로젝트에 참여 중인데, 이미 각 사업부에는 나름 만족하며 쓰는 플랫폼이 있음. 본사는 이 중복을 낭비로 보고 하나로 통합하려 함.
단일 공급원에 의존하면 제공되는 기능과 일정에 묶이게 됨. 10만 명이 함께 쓰는 플랫폼은 내 용도에 맞기보다 지나치게 범용적이거나 무관한 기능으로 가득 차기 쉬우며, 어느 쪽이든 사용자에게는 더 나쁨.
무료 라이브러리가 요구를 충족하지 못하고 불필요하게 복잡해서, 이를 바탕으로 사내 라이브러리를 만들거나 완전히 대체한 적도 많음. 유지 비용이 들더라도 정말 필요한 것을 얻는다면 가치가 있음.
공통 플랫폼을 강제하면 사용자가 요구와 기능의 불일치를 우회하거나, 플랫폼이 모두의 요구를 떠안아야 함. 둘 다 비효율적이고 다른 사용자에게도 해가 됨. 독자 개발에는 좋은 이유가 있어야 하지만, 단일 해법 강제가 특수 목적 애플리케이션 몇 개보다 비쌀 수도 있음.

이런 플랫폼의 사용자로서, 제대로 만들려고 노력하는 사람이 있다는 사실만으로도 희망이 생김. 지금은 서로 다른 사용자 모두에게 기묘하게 뒤섞인 기능이 일괄 적용되고 있음.

현 직장에서 싫은 점 중 하나는 이런 식으로 나서서 개선하는 게 불가능하다는 것임. 모든 것이 여러 겹의 권한으로 잠겨 있어, 보직 변경이나 신규 입사 때 본래 업무에 필요한 권한을 받는 데도 몇 주가 걸림.
공식 담당이 아닌 시스템을 개선하려면 더 큰 마찰을 감수해야 함. 누가 무슨 권한을 가져야 하는지 아무도 정확히 몰라 잘 부탁하면 받을 수도 있지만, 그냥 “담당자”에게 요청하는 것보다 훨씬 번거로움.

본인에게는 조직이 너무 큰 것임. 큰 조직에서는 고칠 수 있는 문제를 발견해도 네 일이 아니라는 말을 듣지만, 작은 조직에서는 도와주겠다고 나선 것만으로도 크게 반김.

그렇게 고칠 수 있는 회사에서 일해봤지만, 어떤 사람은 수정 자체를 집안에 대한 모욕처럼 받아들임. 개인적으로는 안 나서는 편이 나을 수도 있음.

기업은 이런 마찰이 생산성을 얼마나 파괴하는지 과소평가함. 모든 마찰은 누적됨.

많은 회사가 이와 같음. 대부분 자기의 좁은 업무 범위에 만족하고 나머지는 외면함. 더 할 시간·관심·기력이 없거나, 자기 자리 밖에서 회사에 무슨 일이 생기든 급여에 포함된 책임이 아니라고 여기게 됨.
더 많은 일을 하기 쉽게 바꾸려다가 본인도 지칠 수 있음. 조직이 의욕을 꺾는 장치가 된 채 아주 오래 버티기도 하고, 다르게 해보려는 시도 자체를 못마땅해하는 사람도 있음.
그래도 적절한 사람을 찾아 물어보면 돌파구가 생기기도 함. 마찰을 피하거나 줄이는 방법을 문서화하거나 기억해 두면서 모두가 일하기 쉽게 만들 수 있음.

나는 조직 안에서 여러 부서를 직접 돌아보는 것을 적극적으로 실천함. 개발자로 입사하든 임원으로 합류하든 제품·지원·마케팅 조직과 시간을 보내며, 덕분에 남들과 다른 관점을 얻음. 다른 사람에게도 권하고, 온보딩을 설계할 때는 정식 과정에 넣음.
고객층과 제품을 빠르게 이해하는 데 가장 효과적인 방법임. 가능하다면 지원 전화를 들으면서 제품을 써보고, 개발자가 평소 접하지 못하는 불편과 까다로운 부분을 배울 수 있음.

조직 내부 사정을 잘 알면 모든 프로젝트에 끌려들어갈 위험도 있음. 온보딩을 계획할 때는 그런 부작용 없이 여러 부서를 경험하게 하려 함.

이런 걸 어떻게 시작하면 좋을까요? 일반 개발자로서 잘 모르는 다른 팀을 만나러 건물 반대편까지 갈 명분을 찾기가 가끔 어려움.

다른 사람의 일까지 할 줄 알면 개인이 발휘할 수 있는 영향력이 여러 방향으로 커짐. 부탁을 해결해 줄 수 있고, 어디서 사고가 나든 다음 행동이나 연락할 사람을 알 가능성이 큼. 누군가 움직이지 않을 때도 남보다 큰 지렛대는 없을지언정 어디에 힘을 줘야 하는지는 정확히 알 수 있음.
때로는 FedEx에 물건을 맡겨주는 일로 고객에게 시간당 300달러를 청구하기도 함. 현장에 있고, 일을 제대로 해내며, 그 배송의 마감이나 내용물에 얽힌 특수한 사정을 따로 설명받을 필요가 없기 때문임. 보통 수석 컨설턴트의 일이 아니더라도 유용함.

상사들은 내가 할 수 있다는 이유만으로 남의 부탁을 다 들어주지 말고 좀 더 매정해질 필요가 있다고 했음. 그동안 배운 가장 큰 교훈 중 하나는 확실히 거절하는 것임.
그래도 가끔은 회의 후 호텔 방에 틀어박혀 구현한 뒤, 다음 회의에서 48시간 전에 논의했던 것이 실제로 된다는 걸 보여주는 재미와 짜릿함을 즐김. 요즘은 AI 덕분에 걸리는 시간도 훨씬 짧아졌음.

조직이 목표를 달성하는 건 남이 해야 하지만 하지 않는 일까지 맡는 5% 미만의 사람들 덕분이라는 대목에 이만큼 공감한 HN 글이 있었나 싶음.
나도 남들이 안 하는 일을 추가로 떠맡는 쪽임. 이타적이어서가 아니라, 내 업무가 멍청하게 느껴지면 일할 의욕 자체가 생기지 않기 때문임. 충분히 큰 조직에서는 서로 방향을 공유하는 사람이 거의 없어 많은 업무가 그런 식으로 변함.

기업에서는 선행도 반드시 대가를 치르게 됨.

무언가를 해냈을 때 실제로 그 말을 들은 적이 있음. 이제는 행동에 신중해졌는데, 한번 손대거나 고치면 영원히 담당자가 되기 때문임.

50~100년 전에는 밑바닥부터 올라가는 것이 일상이었음. 학위가 직업 훈련이 아니라 세상을 알아가는 수단이었으니, 학위를 내세운 지름길도 없었음. 다시 그 방향으로 돌아가는 모습은 흥미롭지만, AI CEO가 인간 지원자를 모두 거절하기 전까지 기업이 학위 요건을 없앨지는 의문임.

고등학교를 중퇴하고 GED를 취득한 입장이라 공감함. 내 교육은 거의 전부 현장훈련과 세미나·강좌였음.
오랫동안 비웃음도 많이 받았지만, 정작 중요한 사람들은 신경 쓰지 않았음. 세계 최고 수준의 광학 장비 회사에서 경력 대부분을 보내며 세계적인 전문가들과 동료로 일했음. 겸손해지는 동시에 큰 보람을 느낄 수 있었음.