지금까지 참여한 프로젝트에서 가장 느렸던 건 코드가 아니었습니다. 대기열이었죠. 매니저 한 명의 캘린더 앞에 의사 결정이 줄줄이 쌓여서, 사흘 뒤에야 도착하는 “오케이"를 기다리는 것. 비동기 커뮤니케이션과 자율적인 팀이 정석적인 해법이고 저도 지지하는 쪽이지만, 이 전환의 정체는 툴 문제의 탈을 쓴 신뢰 문제입니다.
애초에 왜 모든 일에 결재가 필요해졌나#
승인 문화가 어디서 오는지는 공정하게 봐 둘 필요가 있습니다. 통제는 정밀함처럼 느껴집니다. 모든 결정이 매니저 책상을 거치면 아무것도 옆길로 새지 않을 것 같으니까요. 잘못된 판단은 프로젝트만 망가뜨리는 게 아니라 매니저 본인의 평판도 깎기 때문에, 상당 부분은 두려움이 움직입니다. 팀에 판단할 만한 경험이 있는지 진심으로 의심하는 경우도 있고요. 그리고 순전히 관성인 경우도 있습니다. 조직도가 원래 그렇게 돌아갔으니 오늘도 그렇게 돌아가는 것뿐인 거죠.
이 네 가지 이유 중에 실제로 팀에 관한 건 하나뿐입니다. 나머지는 전부 매니저에 관한 이야기입니다.
자율에 정말 필요한 것#
방향 정렬 없는 자율은 사기만 높은 혼돈입니다. 구성원이 목표를 진짜로 이해하고 있으면, 각자의 독립적인 결정은 대체로 같은 방향을 가리킵니다. 사실상 이게 비법의 전부예요. 교육도 중요합니다. 제대로 준비된 사람은 열정만 있는 사람보다 믿기 쉬우니까요. 그리고 경계는 남겨 두세요. 경영진에게 남아야 할 결정은 실제로 있고, 어떤 결정이 그런지 소리 내어 말해 두면 최악의 서프라이즈를 막을 수 있습니다. 그다음엔 피드백 루프를 돌리면서, 피할 수 없는 실수를 “증거"가 아니라 “수업료"로 취급하면 됩니다.
신뢰가 이미 상해 있다면 — 승인 문화에서 빠져나오는 팀은 대개 양방향으로 상해 있습니다 — 지름길은 없습니다. 열린 대화에서 문제에 이름을 붙이고, 경영진이 자기 몫의 실수를 먼저 인정하고, 그다음 몇 달 동안 지루할 만큼 일관되게 행동하는 것. 역할을 명확히 하고 정기적으로 대화하는 쪽이 거창한 이벤트보다 복구에 훨씬 효과적입니다.
비동기 쪽이 오히려 쉽습니다#
툴 이야기는 짧게. Slack이든 Microsoft Teams든 충분합니다. 진짜 일은 문서화입니다. 아무도 같은 방, 같은 시간대에 있지 않으니, 글로 남긴 결정이 팀의 기억이 됩니다. 응답 기준도 정해 두세요. 비동기가 슬그머니 무응답이 되지 않도록요. “하루 안에"가 “언젠가"보다 낫습니다. 그리고 좋은 비동기 업데이트 쓰는 법은 따로 가르쳐야 합니다. 판단에 충분한 맥락, 필요한 결정, 기한. 타고나는 기술이 아니거든요.
Slack 도입은 오후 한나절이면 끝납니다. 신뢰는 몇 달이 걸리고, 이 전체가 성공할지 실패할지를 가르는 건 그쪽입니다. 목표를 명확히 하고, 실수의 대가가 커리어가 아니라 교훈이 되게 만드세요. 거기까지 하면 비동기 부분은 대체로 알아서 굴러갑니다.