SYDE
SYDESYDESYDE사이드프로젝트 팀이 느려진 건 사람 탓이 아닐 수 있어요
• 팀이 삐걱거릴 때 가장 흔한 함정은 “저 사람이 문제야”로 직행하는 것이에요. 하지만 실제 원인의 상당수는 구조에 있어요.
• Waterline Model은 팀 문제를 수면 위아래 4개 레이어로 진단하는 프레임워크예요: 구조 → 다이나믹스 → 대인관계 → 개인.
• 핵심 원칙은 “스노클링 먼저, 스쿠버는 나중에”예요. 가장 많은 사람에게 영향을 미치는 위층부터 점검하고, 내려가야 내려가는 거예요.
• 구조만 정리해도 팀 성과가 극적으로 개선되는 경우가 많아요.
• 개인 문제는 구조와 시스템이 충분히 건강한 상태에서만 제대로 진단할 수 있어요.
데드라인은 계속 미끄러지고, 같은 얘기를 반복하고, 뭔가 꼬여있는 건 아는데 딱히 집어낼 수 없는 순간이 있어요.
그때 가장 먼저 드는 생각이 뭔가요?
“저 사람이 문제야.” “이 팀이 실행력이 없어.” “인원을 바꿔야 해.”
Molly Graham은 Facebook, Google, Chan Zuckerberg Initiative에서 수십 년간 리더들을 곁에서 지원하며 이 패턴을 수없이 목격했어요. 그리고 명확한 결론에 도달했는데요. “구조적인 문제를 사람 탓으로 돌리는 것이 리더십에서 가장 흔한 함정 중 하나다”라는 거예요.
그가 제안하는 진단 도구가 바로 Waterline Model이에요.
비유가 직관적이에요. 팀은 배고, 목표는 목적지예요. 배가 앞으로 안 나갈 때, 진짜 문제는 수면 아래에 있어요.
Waterline Model은 문제가 숨어있을 수 있는 4개 레이어를 수면에 가까운 것부터 순서대로 점검하는 방식이에요.
🔹 레이어 1 - 구조: 팀이 무엇을 하고 있는지, 왜 하는지, 성공이 어떻게 정의되는지를 규정하는 것들이에요. 비전, 목표, 역할 정의, 기대치, 조직 설계가 여기 해당해요.
🔹 레이어 2 - 다이나믹스: 팀이 실제로 매일 어떻게 함께 일하는지예요. 의사결정 방식, 갈등 해소 방식, 정보 흐름을 봐요.
🔹 레이어 3 - 대인관계: 두 사람 사이의 긴장, 신뢰 부재, 스타일 충돌 같은 것들이에요.
🔹 레이어 4 - 개인: 한 개인 안에서 벌어지는 일이에요. 스킬 격차, 스트레스, 자신감, 개인적 상황.
핵심 원칙은 “스노클링 먼저, 스쿠버는 나중에”예요. 항상 위층부터 점검하고, 배제가 된 다음에만 아래로 내려가는 거예요.
Molly는 한 마케팅 팀을 넘겨받은 적이 있었어요. “이 팀이 대체 뭘 하는 건지, 왜 이렇게 돈을 써도 결과가 없는 건지 알아봐 달라”는 미션과 함께요.
그가 가장 먼저 한 일은 팀원 한 명 한 명에게 질문하는 거였어요.
“당신의 역할을 어떻게 설명하겠어요?”
“우리 팀이 책임지는 목표가 뭐라고 생각해요?”
“당신이 직접 책임지는 수치가 있나요?”
답변들이 제각각이었어요. 어떤 사람은 자신의 역할을 너무 좁게 정의하고 있었고, 어떤 사람은 팀의 목표와 전혀 다른 방향을 바라보고 있었어요. 리더십이 팀에 기대하는 것과 팀원들이 이해하는 것 사이에 큰 간극이 있었고요.
그런 상태에서는 사람의 역량을 제대로 평가할 수가 없어요. 구조가 망가진 시스템 안에서 움직이고 있으니까요.
Molly는 사람 교체 대신 구조 정리를 먼저 했어요. 팀의 미션을 재정의하고, 각 역할의 기대치를 명확히 세웠어요. 그러자 팀 성과가 즉각 개선됐어요. 사람이 바뀐 게 아니라, 사람들이 비로소 자기 일이 뭔지 알게 된 것만으로요.
사이드 1인 팀이더라도 이 원리는 그대로 적용돼요. “내가 지금 무엇을 만들고, 왜 만들고, 성공이 뭔지”를 내 자신에게 명확히 정의할 수 있나요?
Glue Club(Molly가 운영하는 리더십 커뮤니티)에서 한 멤버가 고민을 가져왔어요. “창업자가 팀이 너무 느리다고 답답해해요. 근데 사람들이 빠르게 움직이려 하면, 창업자가 막판에 결정을 뒤집거나 판단을 의심해요. 빠르게 움직이는 게 안전하지 않게 느껴지는 거예요.”
구조는 멀쩡했어요. 목표도 명확했고, 역할도 정의돼 있었어요. 문서상으로는 의사결정 권한도 있었고요.
하지만 실제로 결정이 안정적이지 않았어요. 작업을 앞으로 진행하면, 나중에 뒤집혔어요. 팀원들은 아주 합리적으로 반응했는데요. 느리게 움직이기 시작했어요. 정렬을 위한 레이어를 더 추가하고, 굳이 올리지 않아도 될 결정을 위로 에스컬레이션했어요.
외부에서 보면 실행력 문제처럼 보였어요. 내부에서 보면 자기 보호였고요.
팀은 리더가 만들어낸 시스템 안에서 살아남는 법을 빠르게 배워요. 다이나믹스 문제는 그 신호가 바뀌면 행동도 빠르게 바뀌어요. 해결책은 프로세스 추가가 아니라, 리더의 행동 패턴을 바꾸는 것이에요.
대인관계 레이어에서 주의할 점이 있어요. 많은 경우 “저 두 사람이 사이가 안 좋아서”처럼 보이는 갈등이 실제로는 역할이 겹치거나 인센티브가 어긋난 구조 문제인 경우가 많아요.
하지만 구조와 다이나믹스를 점검한 다음에도 진짜 신뢰 문제나 관계 갈등이 남아있다면, 그건 직접 다뤄야 해요. 갈등을 명확히 이름 붙이고, 비즈니스에 어떤 영향을 미치고 있는지를 중심으로 대화하고, 무엇이 바뀌어야 하는지를 명확히 하는 거예요.
개인 레이어는 가장 마지막이에요. 구조가 명확하고, 다이나믹스가 작동하고, 대인관계도 문제 없는데 여전히 성과가 안 나온다면, 그때 비로소 개인 이슈를 들여다보는 거예요. 그 시점에서는 모호하게 두는 것보다 명확하고 빠른 결정이 오히려 그 사람에게 더 친절한 일이에요.
사이드 프로젝트는 대부분 1인이거나 소규모 팀으로 운영되는데요. 팀이 작을수록 구조 문제는 오히려 더 쉽게 보이지 않아요. “우리가 지금 같은 목표를 보고 있는지”, “각자의 역할이 명확히 구분돼 있는지”를 너무 당연하게 여기다가, 어느 순간 서로 지쳐가는 경우가 많거든요. 팀에 뭔가 이상하다는 느낌이 들기 시작했다면, 사람 탓보다 먼저 구조부터 한번 꺼내놓고 이야기해보는 게 어떨까요?
👇 원문 보기
https://www.lennysnewsletter.com/p/how-to-debug-a-team-that-isnt-working