목차4개 항목
출처와 참고
「Spotify's Failed #SquadGoals」를 바탕으로 재구성한 노트다.
스포티파이 모델이란
스포티파이 모델은 2012년 무렵 스포티파이가 공개한 애자일 조직 구성 방식이다. 영상과 백서로 널리 퍼져 많은 회사가 그대로 따라 했다. 그러나 정작 스포티파이 안에서도 문서에 적힌 대로 완전히 구현된 적이 없는 지향점이었다.
| 단위 | 구성 | 책임자 |
|---|---|---|
| 스쿼드(Squad) | 작은 교차 기능 팀. 작은 스타트업처럼 한 기능 영역을 자율적으로 맡는다 | 프로덕트 매니저가 「미니 CEO」 |
| 트라이브(Tribe) | 관련 스쿼드 여럿을 묶은 부서 | 트라이브 리드 |
| 챕터(Chapter) | 트라이브 안에서 같은 전문 분야(백엔드, 안드로이드 등) 엔지니어의 모임 | 챕터 리드가 사람 관리 |
| 길드(Guild) | 트라이브를 넘어 관심사로 모이는 자발적 공동체 | 없음 |
엔지니어는 업무로는 스쿼드에, 인사로는 챕터에 속하는 매트릭스 구조다.
왜 잘 안 됐나
| 문제 | 원인 |
|---|---|
| 갈등이 위로만 올라간다 | 스쿼드 안에 엔지니어링 관리자가 없어 PM에게 대등한 상대가 없다. 의견이 갈리면 여러 관리자를 거쳐 올라간다 |
| 챕터 리드에게 결과 책임이 없다 | 역할이 개인 성장 관리에 머물고 팀의 납기·품질은 책임지지 않는다 |
| 자율이 정렬보다 앞섰다 | 리더십이 공통 우선순위, 성공 지표, 팀 간 프로세스를 정하지 않았다. 팀마다 일하는 방식이 달라 협업 비용이 커졌다 |
| 협업 능력을 가정했다 | 공통된 애자일 어휘와 기술이 없는데 코칭도 부족했다 |
| 새 용어가 개념을 가렸다 | 부서·팀·관리자를 새 이름으로 부르자 무엇이 문제인지 평가하기도, 바꾸기도 어려워졌다 |
조직 설계 원칙
- 팀마다 책임지는 엔지니어링 관리자 한 명. PM에게는 팀 결과를 함께 책임지는 엔지니어링 짝이 있어야 한다.
- 자율에는 정렬 장치가 따른다. 리더십이 우선순위와 성공 지표, 팀 간 프로세스를 정하고, 팀은 가치와 완료된 일로 책임진다.
- 협업은 가르쳐야 느는 기술이다. 가정하지 말고 코칭과 공통 어휘에 투자한다.
- 규모가 커지면 프로그램 관리를 둔다. 팀 간 계획과 조율을 전담하는 역할이 필요해진다.
- 표준 용어를 쓴다. 부서, 팀, 관리자처럼 누구나 아는 말이 역할을 이해하고 바꾸기 쉽다.
- 이름 붙은 모델을 통째로 들여오지 않는다. 오래 효과가 확인된 요소를 골라 자기 맥락에 맞춘다.
정리
- 스포티파이 모델은 실제 운영 결과가 아니라 지향을 적은 문서였다.
- 매트릭스 구조는 팀 안의 책임 공백을 만들었다.
- 자율은 정렬(우선순위·지표·프로세스)이 있을 때만 작동한다.