빨리 가려면 혼자, 멀리 가려면 함께 가라.
누구나 한 번쯤 들어본 이 격언은 협업의 가치를 강조하는 대표적인 문구입니다. 하지만 PostHog의 찰스 쿡은 최근 뉴스레터에서 충격적인 주장을 펼쳤습니다. 바로 이 말이 당신의 회사를 서서히 죽이고 있다는 것입니다.
협업이라는 이름의 속도 저해 요소
운전을 한다고 상상해보세요. 옆자리 동승자가 길 안내를 해주고, 주유소 위치를 알려주며, 간식을 살 곳을 추천한다면 이는 유용한 협업입니다. 하지만 10분마다 운전대를 바꿔 잡거나, 지나가는 행인에게 차가 마음에 드는지 물어보거나, 누군가 계속 운전 스타일에 대해 지적한다면 어떨까요? 목적지에 빨리 도착하기는커녕, 원하는 곳에 도달하지 못할 가능성이 높습니다.
대부분의 스타트업이 바로 이 두 번째 시나리오에 빠져있습니다. PostHog가 성장하면서 발견한 것도 바로 이것이었습니다. 가치를 더하지 않거나, 투입된 시간 대비 너무 적은 가치만 창출하는 협업이 점점 늘어나고 있었던 것입니다. 이 문제가 심각하다고 판단한 PostHog는 최근 전사 회의에서 “협업은 나쁘다(Collaboration sucks)”를 주제로 다뤘습니다.
“당신이 드라이버다” – PostHog의 핵심 철학
PostHog는 “당신이 드라이버다(You’re the driver)”라는 핵심 가치를 내세웁니다. 이는 “뛰어난 인재를 고용하고 그들의 일을 방해하지 않는다”는 철학의 실천입니다. 데드라인도 없고, 최소한의 조율만 하며, 매니저가 무엇을 하라고 지시하지 않습니다.
그 대신 극도로 높은 주인의식과 혼자서 많은 일을 해낼 수 있는 능력을 요구합니다. 마케터가 직접 코드를 배포하고, 영업 담당자가 백업 없이 기술 질문에 답변하며, 프로덕트 엔지니어가 전체 스택에서 작업합니다. 각자가 자신의 분야에서 완전한 오너십을 가지고 일하는 것입니다.
하지만 현실에서는 항상 유혹이 존재합니다. 거의 모든 경우, 당신보다 그 일을 더 잘하는 사람이 회사 어딘가에 있기 마련입니다. 그래서 사람들은 협업하고 싶어집니다. 그러나 이러한 협업은 드라이버가 속도를 늦추고 배경, 맥락, 생각을 설명하도록 강제합니다.
협업 과잉을 알리는 위험 신호들
PostHog는 과도한 협업을 나타내는 몇 가지 핵심 표현들을 발견했습니다:
- “X가 어떻게 생각하는지 궁금해”
- “Y의 의견을 듣고 싶어”
- “Z와 함께 작업해야 해”
이런 표현들은 때때로 가치 있는 통찰로 이어지기도 하지만, 항상 드라이버의 속도를 늦춥니다. 그리고 이는 드라이버의 동기, 자신감, 효율성을 서서히 침식시켜 결국 출시량 감소로 이어집니다.
모두가 협업 과잉의 공범이다
그렇다면 왜 사람들은 과도한 협업을 하는 걸까요? PostHog의 분석에 따르면 모두가 원인 제공자입니다.
- 첫째, 사람들은 도움이 되고 싶어합니다. 누군가 슬랙에 진행 중인 작업을 올리면, 피드백 문화 때문에 다른 사람들이 피드백을 줘야 한다고 느낍니다. 반대로 특정인에게만 피드백을 요청하는 것이 포괄적이지 않다고 느껴져 요청하지 않는 경우도 있습니다.
- 둘째, 어떤 피드백이 필요한지 충분히 구체적이지 않습니다. 이는 불필요한 협업이 끼어들 여지를 만듭니다. 특정 기능 구축에 대한 논의가 전체 제품 로드맵 재평가로 확대될 수 있습니다.
- 셋째, “논의하자(let’s discuss)”가 기본 반응이 됩니다. 누군가 좋은 아이디어를 내면 “그것을 해라”가 아니라 “논의하자”가 나옵니다. PostHog의 슬랙에는 “let’s discuss”라는 표현이 175번이나 등장했습니다. 사람들은 너무 바쁘거나 귀찮아서 실행 대신 논의로 전환합니다. Pull request에서 이슈/RFC로, 슬랙으로, 그리고 “논의하자”로 계속 이동하는 것입니다.
- 넷째, 누가 주인인지 명확하지 않습니다. 또는 아무도 논의 중인 것을 소유하고 싶어하지 않습니다.
물론 짜증나는 일이지만, 때로는 한 사람이 처음부터 끝까지 충분히 높은 품질로 출시할 수 없는 경우도 있습니다. 깨진 코드는 고칠 수 있지만 뉴스레터는 재발송할 수 없는 것처럼 말입니다.
협업을 적으로 간주하고 물리치는 방법
PostHog가 제시하는 해결책은 명확합니다.
- 1. 기본은 실행 우선입니다.
- Pull request > Issue > Slack 메시지 순으로 우선순위를 둡니다.
- 2. 과도한 협업을 발견하면 즉시 개입합니다.
- “너무 많은 사람이 관여하고 있다. X, 너가 운전자야, 네가 결정해”라고 명확히 선을 긋습니다.
- 3. 피드백은 구체적으로 요청합니다.
- 누구에게 무엇을 원하는지 태그하고, 공허하게 던지지 않습니다.
- 4. 출시 전 리뷰보다 출시 후 피드백을 선호합니다.
- 사전 피드백은 유사 승인 프로세스로 변질될 수 있습니다. 다음 반복 전에 피드백을 제공하는 것이 더 효과적입니다.
- 5. 리더는 피드백을 자제합니다.
- ‘그냥 해보라(you can just do stuff)’는 태도를 유지합니다.
- 6. 각자는 ‘정보를 가진 선장(informed captain)’으로 행동합니다.
- 피드백을 들을 수는 있으나 최종 결정은 본인이 내립니다.
적게 협업할수록 더 멀리, 더 빠르게
PostHog도 모든 협업을 뿌리 뽑을 수는 없다는 것을 인정합니다. 일부 협업은 분명 유용합니다. 찰스 쿡의 이 뉴스레터조차도 Ian과 Andy의 편집을 거쳤으니까요.
핵심은 이것입니다. 적극적으로 협업을 줄이려 하지 않으면, 기본적으로 너무 많이 협업하고 있을 가능성이 큽니다. 협업은 본질적으로 속도를 늦추기 때문에, 적게 협업할수록 더 멀리, 더 빠르게 갈 수 있습니다.
“빨리 가려면 혼자, 멀리 가려면 함께”라는 격언은 이제 뒤집어야 할 때입니다. 올바른 협업 문화는 모두가 함께 의견을 나누는 것이 아니라, 각자가 드라이버로서 자율성을 가지고 빠르게 실행하되, 필요한 순간에만 정확한 피드백을 주고받는 것입니다. 이것이야말로 스타트업이 멀리, 그리고 빠르게 갈 수 있는 진짜 비결입니다.
참고 자료: Charles Cook, “Collaboration sucks”