"더 빨리 할 수 있는데 왜 시켜야 하죠?" - 실력 있는 리더일수록 빠지는 함정

 

최근 실리콘밸리의 한 리더십 블로그에서 정말 인상 깊은 글을 읽었어요. 엔지니어에서 매니저로 전환한 발레리아라는 분의 이야기였는데, 많은 생각을 하게 만드는 내용이더라고요.

"발레리아, 이제 코딩 그만하세요"

회의 중에 팀원으로부터 이런 말을 들었다고 해요. 팀에서 가장 경험 많은 엔지니어였고, 가장 빠르게 코드를 작성하고 리뷰할 수 있었는데 말이죠. 대체 무슨 의미였을까요?

발레리아는 매니저가 되기로 결심했을 때를 선명하게 기억한다고 해요. 팀원들의 성장과 보상, 행복을 위해 누군가는 나서야 했다고 하더라고요. 리더십에 대한 지식은 부족했지만 최선을 다하겠다고 마음먹었대요.

그런데 그녀에게 최선이란 모든 것을 직접 하는 것을 의미했어요. 팀에서 가장 실력 있는 엔지니어로서 당연한 선택이라고 생각했죠. 실수를 할 때마다 자책했대요. "내가 제대로 못 하는데, 어떻게 남들한테 일을 시켜?"

그러다 들은 한 마디가 모든 걸 바꿨어요. "코딩을 그만두세요."

빠른 속도가 독이 되는 순간

이 경험을 통해 발레리아가 깨달은 건 정말 놀라웠어요. 그녀가 빠르게 문제를 해결할수록, 팀원들은 성장할 기회를 잃고 있었다는 거예요.

실리콘밸리의 한 연구 결과가 이를 뒷받침해요. 매니저가 직접 업무에 개입할 때 팀의 생산성은 단기적으로 15% 상승하지만, 6개월 후에는 오히려 23% 감소한다고 하더라고요. 팀원들이 스스로 판단하고 실행하는 능력을 키울 기회를 빼앗기기 때문이래요.

발레리아는 이렇게 말했어요. "제가 빨리 할 수 있다는 사실 자체가 문제였어요. 제가 뛰어들 때마다 팀원들은 자기만의 속도와 판단력을 개발할 기회를 잃었던 거죠."

오늘의 속도를 위해 내일의 역량을 포기하고 있었던 셈이에요. 그래서 답은 명확했대요. 더 빨리 할 수 있기 때문에 위임해야 한다는 것. 팀이 결국 자신보다 더 빠르게 일할 수 있는 연습을 할 수 있도록 말이에요.

코딩을 멈추자 찾아온 정체성의 위기

코딩을 멈추자 정체성의 위기가 찾아왔다고 해요. 평생 뛰어난 엔지니어로 살아왔는데, 이제 코딩을 하지 않는다고요? 여전히 가치 있는 사람일까? 이런 고민에 빠졌대요.

더군다나 매니지먼트는 완전히 새로운 영역이었어요. 실수투성이였고, 끊임없이 자신을 의심했다고 하더라고요. 칭찬을 받아도 사기꾼이 된 기분이었대요.

국내 한 IT 기업의 조사를 보면, 개발자에서 매니저로 전환한 사람들의 68%가 첫 1년 동안 심각한 정체성 혼란을 겪는다고 해요. 발레리아의 경험이 결코 특별한 게 아니었던 거죠.

"문제 해결 버튼"이라는 새로운 함정

새로운 정체성을 찾던 중 발레리아는 흥미로운 역할을 발견했어요. 팀원들이 그녀를 "문제 해결 버튼"이라고 부르기 시작했대요. 누군가 막히면 그녀에게 와서 문제를 넘기면, 바로 해결해줬다고 하더라고요.

한동안은 통했대요. 코딩은 안 해도 여전히 팀에 기여하고 있다고 느꼈으니까요. 멘토이자 가이드가 된 것 같았대요. 항상 답과 해결책을 갖고 있었죠.

그런데 뭔가 여전히 이상했다고 해요. 매니저는 기술 문제만 해결하는 게 아니라는 것. 사람들의 감정과 대인 관계도 다뤄야 했어요.

발레리아는 심리학 책들을 읽으며 사람들을 이해하려고 노력했대요. 더 나은 리더가 되고 싶었으니까요. 하지만 여전히 모든 것을 직접 해결하려는 습관을 버리지 못했어요. 배려심 많은 "감정 해결 버튼"이 되어버린 거죠.

진 킴의 "피닉스 프로젝트"에서 찾은 답

전환점은 진 킴의 "피닉스 프로젝트"를 읽으면서 찾아왔대요. 특히 멘토 에릭이라는 캐릭터에게서 영감을 받았다고 해요. 직접 개입하지 않고도 주인공이 해야 할 일을 찾도록 돕는 현명한 가이드 같은 존재였대요.

발레리아는 그때 깨달았어요. 자신은 너무 개입하고 있었고, 팀의 일이 미치는 영향조차 제대로 측정하지 못하고 있었다는 것을요.

"피닉스 프로젝트"에는 인상적인 질문이 나온다고 해요. "어떤 숫자가 올라가야 당신이 행복할까요?" 이 질문이 전체 조직 변혁의 시작이었대요.

발레리아도 자신의 팀에 적용하려 했지만 쉽지 않았어요. 당시 그녀는 5개 팀에 걸쳐 12명의 개발자를 관리하고 있었고, 각자 목표와 지표가 달랐거든요. 회사의 전체 목표는 알았지만, 웹 개발자들만으로 어떻게 그 목표에 기여할 수 있는지 명확하지 않았대요.

이해관계자라는 복잡한 세계

매니저로서 가장 어려웠던 건 다양한 이해관계자를 다루는 것이었대요. 제품 매니저, 디자이너, 콘텐츠 편집자, 고객 지원, 데이터팀, 아키텍트, 보안팀... 각자 우선순위와 기대치가 달랐어요.

발레리아가 문제 해결에만 집중할 때는 괜찮았대요. 하지만 프로세스를 개선하려고 하자 반발이 시작됐다고 해요. 제품 팀 구조를 제안했는데 "절대 안 돼"라는 반응을 받았대요.

그제야 깨달았다고 해요. 함께 일하는 사람들에 대해 너무 모르고 있었다는 것을요. 처음에는 이해관계자가 개발자들과 상사뿐이라고 생각했는데, 실제로는 의존하는 사람이 훨씬 많았고 각자의 목표와 필요가 있었던 거죠.

"비즈니스는 사람에 관한 것"이라는 말의 진짜 의미를 이해하게 됐대요. 그들의 필요를 배우고, 장애물을 제거하고, 경계를 존중하는 것. 말은 쉽지만 실천은 어려웠다고 하더라고요.

매니지먼트 업무도 위임이 필요하다

모든 이해관계자를 정리해보니 충격적이었대요. 너무 많았거든요. 각자 다른 우선순위와 일정, 기대치를 가지고 있었어요.

이 시점에서는 코딩이나 기술 문제가 가장 작은 걱정거리였대요. 슬라이드 만들고 회의 참석하는 데 시간을 다 써서 다른 생각할 여유가 없었다고 해요.

그때 깨달았대요. 기술 업무뿐만 아니라 매니지먼트 업무도 위임해야 할 때라는 것을요. 일대일 미팅만으로도 일정의 대부분이 차버렸으니까요.

팀 토폴로지를 공부하면서 중요한 사실을 발견했대요. 각 팀이 성공하려면 명확한 하나의 목적이 필요한데, 당시 팀은 다섯 개의 목적을 가지고 있었다고 해요.

그래서 팀을 분리하고 "웹 목표 키퍼"라는 특별한 역할을 만들었대요. 목표 설정을 여러 팀원에게 위임한 거죠. 팀 내에서 목표를 소유할 전담자가 생기자 큰 변화가 일어났다고 해요.

지표보다 먼저 비전이 필요하다

여전히 팀의 영향력을 측정하는 건 어려웠대요. 목표 및 핵심 결과, 핵심 성과 지표, 지표 대시보드 등 다양한 방법을 시도했지만 제대로 작동하지 않았다고 해요.

전환점은 "파운데이션 팀"이라는 이니셔티브가 해체되면서 찾아왔어요. 공유 인프라와 전략적 프로토타입을 담당하는 팀이었는데, 다른 부서의 지원을 받지 못해 중단됐대요.

하지만 그 과정에서 제품 매니저와 성공 지표에 대해 깊이 있는 대화를 나눴다고 해요. 그녀에게서 중요한 교훈을 얻었대요. 지표를 정하기 전에 먼저 비전이 필요하다는 것이요.

팀이 존재하는 명확한 이유, 모두가 모일 수 있는 북극성. 그게 있으면 지표 정의가 훨씬 쉬워진다고 하더라고요.

발레리아는 질문을 던졌어요. "우리가 스타트업이라면 미션이 뭘까?" 답이 나오기 시작했대요. 그들은 웹 개발 전문가였고, 회사 내 여러 팀의 장기 컨설턴트였으며, 신뢰할 수 있는 사내 솔루션을 구축하고 있었어요.

비슷한 시기에 서비스 수준 지표와 목표라는 개념을 접했고, 모든 게 맞아떨어졌다고 해요. 팀과 함께 다음 3개월 동안의 지표를 정렬했대요. 고객 경험과 비즈니스 결과에 직접 연결된 것들이었죠. 지연 시간, 가용성, 비용.

그리고 다음 날 대시보드가 생겼대요. 무엇을 통제할 수 있고 무엇을 우선순위로 둬야 하는지 명확해졌다고 해요.

문화가 없으면 지표는 재앙이 된다

발레리아는 지표의 위험성도 지적했어요. 숫자는 악용될 수 있거든요. 지연 시간만 신경 쓰면 사용자 경험이나 보안을 희생하게 되고, 가용성만 보면 비용을 무시하게 되죠.

올바른 가치에 맞춰진 문화가 없으면 지표는 재앙이 될 수 있대요. 무작정 지표를 따르는 게 많은 실패의 원인이라고 하더라고요.

그래서 리더십 워크숍에 참석하고 대니얼 코일의 "컬처 코드" 같은 책을 읽으며 문화 구축 방법을 배웠다고 해요. 소규모 그룹 미팅으로 전환하고, 피드백 문화를 만들고, 개인 목표를 설정했대요.

최근에는 팀이 다음 기술 스택을 논의하는 회의에 참석하지 않았다고 해요. 초안만 남겨뒀는데, 팀이 기대 이상의 결과를 냈대요. 직접 했어도 더 잘하거나 빠르게 할 수 없었을 거라고 하더라고요.

리더로서 꼭 기억해야 할 것들

발레리아는 여전히 한 명의 엔지니어링 매니저가 직접 관리하는 인원은 5~7명을 넘지 않아야 한다고 강조해요. 품질이 떨어지고 복잡성이 기하급수적으로 증가하기 때문이래요. 그리고 한 팀은 하나의 명확한 방향을 가져야 한다고 해요.

리더는 상황이 완벽하지 않을 때 성장한다고 하더라고요. 책임을 지고 통제를 놓아주는 데는 시간과 엄청난 용기가 필요하지만요.

일이 멈추는 게 아니라 변형된다는 게 흥미로웠어요. 엔지니어링과의 유사점도 강하다고 해요.

회의와 슬라이드가 새로운 코딩 세션이에요. 예전에 코드로 우아한 솔루션을 만들었듯이, 이제는 소통으로 명확성을 만드는 거죠.

갑작스러운 이해관계자 불만은 새로운 버그예요. 근본 원인 분석이 여전히 필요하죠. 디버깅 도구가 로그 대신 대화일 뿐이래요.

사람들의 성장을 돕는 것이 새로운 기능 배포라는 비유가 정말 인상적이었어요. 가장 긴 피드백 루프를 가진 작업이지만, 팀원이 몇 년 전의 당신도 어려워했을 문제를 해결할 때, 그게 바로 성공적인 배포라고 하더라고요.

마치며

발레리아의 마지막 말이 기억에 남아요. "전에도 해냈잖아요. 코딩을, 디버깅을, 배포를 배웠듯이. 이제는 실시간으로, 자연어를 사용해서, 훨씬 복잡한 환경에서 하는 거예요. 그냥 다차원 퍼즐이에요. 별거 아니죠."

기술 리더로의 전환을 고민하고 있거나, 이미 그 과정에 있다면 발레리아의 이야기에서 많은 인사이트를 얻을 수 있을 거예요. 더 빨리 할 수 있다는 게 문제가 아니라, 바로 그 이유 때문에 위임해야 한다는 역설. 팀의 성장이 곧 리더의 성공이라는 진실을 말이에요.

여러분도 혹시 "내가 더 빨리 하는데 왜 시켜야 해?"라고 생각하고 계신가요? 그렇다면 이 글이 조금이나마 도움이 되었으면 좋겠어요.