아마존 소프트웨어 엔지니어인 저자가 40명 엔지니어 조직에서 디자인 리뷰 프로세스를 만들려고 시도했습니다. 처음에 모든 것을 혼자서 작업(그룹 구성, 사전 자료 준비, 회의 진행, 회의록 작성)하려 했고, 디자인 그룹 멤버들은 리뷰어로 참석하는 것을 의도했습니다. 하지만 결과는 대부분 리뷰어가 정기적으로 회의에 참석하지 않았습니다.
"당신은 노력이 드는 것에 헌신하게 됩니다."
마치 헬스장 회원권을 선물 받은 사람 보다, 직접 매달 비용을 지불하는 사람이 자신의 투자를 정당화하기 위해 열심히 헬스장에 가는 것처럼 그는 그룹 멤버가 자신이 맡은 주의 운영을 책임지도록 운영을 변경했습니다. 저자가 모든 책임을 혼자 처리한 것이 오히려 멤버들의 디자인 리뷰 그룹에 대한 소속감을 느끼지 못하게 방해하고 있다고 판단한 것입니다.
"야근을 통해 승진하는 것은 지속 가능하지 않습니다. 다음 단계에서 성과를 내기 위해서는 동일한 야근이 필요합니다. 대신, 지속 가능한 작업을 만들어내는 시스템을 구축하는 데 집중하세요. 다음 단계의 업무량을 처리할 준비가 되었을 때 승진하세요."
이와 같은 교훈이 저자의 디자인 리뷰 그룹 운영에도 적용된 것입니다. 그는 초반에 단기적 결과 달성에 집중하여 자신이 없이도 운영될 수 있는 지속적인 시스템 구축을 간과한 것입니다.
모든 이니셔티브의 모든 책임을 짊어지려는 사람에게 조언을 다음과 같이 저자는 합니다.
"일회성 노력의 경우, 명확한 종료 날짜를 설정할 수 있다면 혼자서 책임을 지는 것이 괜찮습니다.하지만 지속적인 작업의 경우, 처음부터 책임을 분배하는 장기적인 시스템을 구축하세요."
프로덕트 매니저도 다르지 않은 것 같습니다. 소위 남들이 하기 싫은 일을 PM이 해야한다고 생각하는 경향이 있지만, 협업하는 멤버들의 소속감, 에너지를 높이기 위해서 일정 이니셔티브 또는 정기적인 업무에 대해선 책임을 부탁하는 것이 필요합니다. 만일 작게 시작한다면 프로덕트 릴리즈 관련해서 사내 커뮤니케이션(예: 슬랙 채널 메시지 게시)을 할 때 매번 PM이 커뮤니케이션하는 것이 아니라 프로젝트 멤버들이 돌아가면서 진행을 해볼 수 있을 것 같습니다.