왜 분산 리더십이 명령·통제보다 더 효율적인가
Source: Dev.to
제가 인정하겠습니다. 저는 10년 동안 프로페셔널 리마인더로 살아왔습니다. 그게 제 일이라고 생각했죠. **“시니어 리더”**라는 것이 시계를 바라보며 체크리스트를 확인하는 사람이라고 생각했습니다. 모든 코드 라인과 보드에 있는 모든 티켓을 눈여겨 보지 않으면 배 전체가 가라앉을 것이라고 믿었습니다.
그것을 **“고성능”**이라고 부렀고, **“표준 유지”**라고 불렀습니다. 하지만 솔직히 말하자면, 그것은 아주 정중한 형태의 두려움에 불과했습니다.
저는 무시당할까 두려웠습니다. 팀이 저 없이도 움직일 수 있다면, 회사가 저를 필요로 하지 않는다는 사실을 깨달을까 봐 두려웠습니다. 그래서 저는 자신을 병목 현상으로 만드는 시스템을 만들었습니다. 저는 휠의 중심이었습니다. 모든 결정은 제 책상을 통과해야 했고, 모든 산출물은 제 도장이 찍혀야 했습니다.
저는 영웅이 된다고 생각했지만, 지금은 제가 단지 벽에 불과했다는 것을 깨달았습니다.
오늘날 기술 팀을 이끌고 있다면, 아마도 **“금속 같은 차가움”**의 무게를 느끼고 있을 것입니다. 더 빠르게 움직여야 한다는 압박감, 더 높은 속도와 더 많은 산출을 요구하는 지속적인 요구를 느끼고 있을 겁니다. 업계는 더 나은 지표와 더 엄격한 통제가 그 해답이라고 말합니다.
하지만 저는 “현장 감독” 사고방식이 소프트웨어를 구축하는 가장 비효율적인 방법이라고 말씀드리고 싶습니다. 명령과 통제의 리더십은 창의적인 엔지니어들로 가득 찬 방에서는 전혀 통하지 않는 공장 시대의 유물입니다.
제가 힘들게 배운 진실은 이렇습니다: 분산 리더십은 사람들을 대하는 “멋진” 방법일 뿐만 아니라, 실제로 지속 가능한 무언가를 만들면서 인간성을 유지할 수 있는 유일한 방법입니다.
구세주 신화
우리는 기술 분야에 “Hero”(히어로) 문제가 있습니다. 우리는 생산 버그를 고치기 위해 새벽 3시까지 깨어 있는 사람에게 보상을 줍니다. 우리는 코드를 “구원”하기 위해 모든 PR에 뛰어드는 리드를 축하합니다.
저는 그 사람이었습니다. 모든 답을 가지고 있다는 짜릿함을 사랑했죠. 제 희생이 팀에 대한 선물이라고 생각했습니다. 팀을 압박으로부터 보호하고 있다고 생각했습니다.
하지만 히어로가 됨으로써 저는 실제로 그들의 성장을 빼앗고 있었습니다.
통제에서 비롯된 리더십을 하면 “Users”(사용자들) 로 구성된 팀을 만들게 됩니다. 그들은 당신의 지시를 기다립니다. 당신의 승인을 기다립니다. 스스로 생각하지 않게 되는데, 그 이유는 결국 당신이 그들을 위해 생각해 줄 것이라고 믿기 때문입니다.
이는 믿을 수 없을 정도로 비효율적입니다. 팀 전체의 속도가 한 사람의 두뇌 속도에 의해 제한되는 시스템을 만들게 됩니다. 그 사람은 보통 피곤하고 스트레스를 받으며 실제 작업과는 단절된 상태입니다.
저는 매일 아침 그 무게를 느꼈습니다. 캘린더를 보면 다른 사람들의 우선순위가 격자처럼 보였습니다. 저는 제 직함에 빚을 지고 있었습니다. 저는 제가 싫어하던 바로 그 존재가 되어버렸습니다. 이제는 아무것도 만들 줄 모르는 매니저가 되었습니다.
이를 해결하기 위해 저는 두려운 일을 해야 했습니다: 놓아주다.
신뢰는 궁극적인 저지연 네트워크
엔지니어링에서는 마찰을 줄이기 위해 많은 시간을 투자합니다. 파이프라인을 최적화하고, 코드를 리팩터링하며, 생각과 배포 사이의 최단 경로를 찾습니다.
어떤 팀에서든 가장 큰 마찰의 원천은 신뢰 부족입니다.
명령‑통제 구조를 갖추면 모든 의사결정에 거대한 지연이 발생합니다. 엔지니어에게 아이디어가 떠오르면 회의를 기다려야 하고, 몇 달째 코드를 건드리지 않은 매니저에게 아이디어를 설명해야 합니다. 그 매니저는 또 다른 매니저와 확인해야 합니다.
아이디어가 승인될 때쯤이면 불꽃은 사라지고, 엔지니어는 문제 해결이 아니라 작업 수행만을 하게 됩니다.
분산 리더십—제가 “Growing a Garden”(정원 가꾸기) 라고 부르는 것—은 바로 그 지연을 없애는 것입니다. 결정을 내릴 권한을 실제로 토양을 만지는 사람들에게 넘겨주는 것이죠.
팀이 자신의 작업을 소유하면 어떤 매니저도 강제할 수 없는 속도로 움직입니다. 벽에 붙은 지표를 만족시키기 위해 일하는 것이 아니라, 자신이 만드는 것이 미치는 파급 효과에 대해 고민하며 일합니다.
신뢰는 부드러운 스킬이 아니라 기술적 이점입니다. 팀이 스스로 격차를 메우게 하는 연료이죠. 시스템을 강제해야 한다면, 그 시스템은 이미 부서진 것입니다. 좋은 팀은 숲과 같아야 합니다: 스스로 성장하고, 적응하며, 현장 감독이 클립보드로 감시하지 않아도 스스로 유지됩니다.
작업의 영혼
기업 세계는 관리가 **“일을 실현하는 것”**이라고 말합니다.
하지만 솔직히 말하면, 이는 종종 사람들을 자리에 앉게 하는 것에 불과합니다. 우리는 사무실—디지털 사무실조차도—를 공장 바닥처럼 대합니다. 우리는 기능 목록의 길이로 가치를 측정합니다. 우리가 충분히 빠르게 움직이면, 우리가 단지 알고리즘의 중개자에 불과하다는 느낌을 뛰어넘을 수 있다고 생각합니다.
나는 책상 위 햇빛을 바라보며 내가 성공적인 배포의 연속 그 이상임을 기억합니다. 우리 팀은 속도 차트 그 이상입니다.
분산 모델로 전환하면, 당신은 결국 이끄는 사람들의 인간성을 인정하게 됩니다. 당신은 이렇게 말하는 것이죠:
“나는 당신의 논리를 신뢰합니다. 나는 당신의 양심을 신뢰합니다. 나는 당신이 배가 아니라 물을 신경 쓰길 신뢰합니다.”
이것은 방 안의 분위기를 바꿉니다. 감시에서 청지기 역할로 전환됩니다.
우리는 우리가 만든 파급 효과에 대해 책임이 있습니다. 그 파동은 코드에만 머무르지 않고, 엔지니어들의 가족과 그들이 하루를 마치고 노트북을 닫을 때의 감정까지 영향을 미칩니다.
당신의 리더십 스타일이 사람들을 기계처럼 느끼게 한다면, 당신은 그들을 실망시키는 것입니다—비록 모든 일정을 맞추고 “최적화”가 완벽하더라도. 당신은 **“금속성 냉기”**를 만들어 결국 모두를 소진시킬 것이기 때문에 실패하는 것입니다.
리팩터 시작하기
당신이 영웅 역할에 지쳤다면, 오늘 바로 리팩터를 시작할 수 있습니다. 새로운 프레임워크가 필요하지 않습니다. Jira 설정을 바꿀 필요도 없습니다.
“모르겠다.” 라고 말할 만큼 용기가 필요합니다.
다음에 팀원이… (필요에 따라 계속)
문제를 가져왔을 때, 해결책을 주지 마세요. 설령 당신이 이미 알고 있더라도, 정확히 어떤 파일을 바꿔야 하는지 알더라도 말입니다. 대신에 질문을 던지세요:
“우리에게 무엇을 해야 할지 어떻게 생각해?”
그 다음, 가장 어려운 부분을 수행하세요. 조용히 있으면 됩니다. 침묵이 방 안에 머물게 두세요. 그들에게 스스로 리더십을 발휘할 공간을 주세요. 잠시 그들이 고군분투하는 모습을 지켜봐야 할 수도 있습니다. 실수를 하는 모습을 지켜봐야 할 수도 있습니다. 그러나 그 고군분투 속에서 성장합니다. 바로 그곳에서 **“리소스”**가 **“파트너”**가 됩니다.
저는 기술 리더들이 직함 뒤에 숨지 않고 물을 바라보게 돕습니다. 우리는 사람을 기계로 만드는 것이 아니라, 팀을 정원으로 키우는 일이라고 믿습니다.
우리는 소프트웨어를 넘어선 유산을 설계하는 건축가입니다. 우리 아이들이 결국 일하게 될 문화를 만들고 있습니다. 숨 쉬는 문화, 햇빛이 바닥까지 닿을 수 있는 장소를 만들어요.
배를 측정하는 것을 멈추세요. 물이 더 중요합니다.
Source: …
패치: “모르겠어요” 스크립트
리더십의 무게를 나누고 싶다면, 다음 회의에서 이 방법을 시도해 보세요.
누군가가 보통 혼자서 내리던 결정을 당신에게 물어볼 때, 이렇게 말하세요:
“몇 가지 생각은 있지만, 제 관점이 코드와 너무 동떨어져 있을까 걱정돼요. 이번엔 당신의 직감을 믿고 싶어요. 당신의 직감이 옳은 방향이라고 말해주는 건 뭐인가요?”
그 다음엔, 들어 주세요. 바로잡으려 하지 마세요. “최적화”하려 하지 마세요. 그냥 들어 주세요. 씨앗을 심는 겁니다. 자라나는 데는 시간이 걸리겠지만, 그 열매는 기다릴 가치가 있습니다.
저는 기술 리더십, 공유 소유권, 그리고 기계 중심 산업 속에서 인간다움을 유지하는 이야기를 씁니다. 이 글이 와 닿았다면, newsletter.diamantinoalmeida.com에서 제 다른 작업들을 찾아보실 수 있습니다.