[Squad 팀 모델 실패, 무엇을 배울 수 있을까 🧑‍💻]

🏷큐레이터요약 1. 매트릭스 관리는 잘못된 문제(Wrong Problem)를 해결함 -제품-디자인-기술 팀은 일반적으로 엔지니어들이 더 많으니까, 전체 엔지니어들을 담당하는 매니저가 있어야 팀 내의 의견충돌 시 에스컬레이션할 경로가 생김 -프로덕트 매니저들은 기술에 대해 의논할 동등한 피어(CEO와 CTO처럼)를 가져야 함. 2. 팀의 자율성에 의존 -스포티파이는 팀 간 협업에 대한 공통 프로세스를 정의하지 않았음. 각 팀이 자신들만의 방법으로 참여하니까 전체 조직의 생산성이 떨어짐. -"스포티파이 모델"은 회사가 훨씬 작았을 때 정리된 것. 후속으로 정리된 것이 나와야 했지만, 그러지 못했음. 자율성까지만 얘기되고, 팀 간 협업에 대한 부분은 완료되지 않음. -자율성은 얼라인이 필요함. 회사의 우선순위는 경영진에 의해 정해져야 함. 자율성은 팀들이 하고 싶은 것을 맘대로 하는 것이 아님. -팀 간 협업 프로세스는 무조건 필요함. 자율성은 각 팀이 모든 문제를 혼자 해결하도록 놔두는 것이 아님. -성공을 어떻게 평가하는지도 경영진이 정해놔야, 팀 간 협업 우선순위를 결정할 때 조율이 가능. -자율성은 책임을 요구함. Product Management는 제품 가치에 대해 책임져야 함. 각 팀은 추가되는 부분을 '완료'해야 하는 책임이 있음. 성숙한 팀은 비즈니스 가치, 위험, 학습 및 다음 단계를 위한 최적의 움직임을 보여주는 것으로 자신들의 독립성을 정당화 해야 함. 3. 협업은 가정된 역량이었을 뿐 -협업은 지식과 연습이 필요한 기술임. 관리자는 사람들이 기존 애자일 프랙티스들을 이해하고 있다고 가정해서는 안 됨. -회사가 충분히 커지면 각 팀은 팀 내에서 계획을 세우고 팀 간의 협업을 가능케 하기 위한 서포트 조직이 필요함. Program Management가 플래닝 프로세스를 책임져야 함. 전담 Program Manager 들은 Product Manager 와 Engineering Manager가 각자의 역량을 수행하면서도 협업하는 것처럼 팀을 동작하게 해야 함. 4. 신화는 변경하기 어려움 -대부분의 비즈니스는 몇 개의 혁신 영역만 유지가 가능. 내부프로세스의 혁신이 시장에서 회사를 차별화하는 경우는 거의 없음. 과거를 연구하면 비즈니스가 혁신을 위한 좀 더 나은 영역을 찾을 수 있음. -이해를 최적화할 것. 조직의 생산성을 유지하기 위해서, 조직원이 배워야 하는 모든 새로운 것의 가치를 평가해야 함.