완성된 결과만 공유하는 팀은 깔끔해 보입니다.
문제는 방향이 틀렸을 때입니다. 일주일 동안 공들인 뒤 처음 결과를 보여주면, 잘못된 가정을 발견하는 데도 일주일이 걸립니다.
반대로 빠른 팀들은 결과물을 더 빨리 만드는 것보다 중간 결과를 더 자주 드러내는 방식을 택했습니다. 결과를 기다리는 시간을 줄이는 대신, 판단할 수 있는 순간을 앞당긴 것입니다.
ING: 일을 작은 단위로 나누고 고객 반응을 확인했습니다
ING의 애자일 전환 사례에서 팀은 여러 직무가 한 스쿼드로 일하며 고객에게 제공할 내용을 지속적으로 시험했습니다. 긴 계획을 세운 뒤 마지막에 확인하기보다, 작은 결과를 내고 반응을 다음 판단에 반영하는 방식입니다.
핵심은 회의를 많이 하는 것이 아닙니다. 중간 결과가 있어야 대화가 취향이 아니라 실제 반응을 중심으로 움직인다는 점입니다.
Spotify: 실험을 일부 팀의 기술이 아닌 일하는 방식으로 만들었습니다
Spotify는 2013년 사내 실험 플랫폼 ABBA를 만들고, 이후 더 많은 팀이 제품 실험을 운영할 수 있도록 체계를 확장했습니다.
모든 아이디어가 정답이라는 전제보다 작은 사용자 집단에서 먼저 확인하고, 결과를 다음 선택의 근거로 삼는 방식입니다. 실험을 쉽게 만들수록 “누가 맞는가”보다 “무엇이 실제로 작동했는가”를 이야기하기 쉬워집니다.
당근: 결과를 기다리게 하지 않고 평소 일하는 곳으로 보냈습니다
실험이 끝났다는 사실을 담당자가 늦게 발견하면 다음 결정도 늦어집니다.
당근의 Slack 봇 사례는 A/B 테스트 결과를 Slack으로 보내 팀이 흐름을 놓치지 않도록 했습니다. 결과를 만드는 과정만큼 결과가 제때 보이는 구조도 중요하다는 이야기입니다.
세 사례의 산업과 규모는 다르지만 공통점은 선명합니다.
- 일을 검토 가능한 크기로 나눕니다.
- 완성 전에도 판단할 수 있는 결과를 만듭니다.
- 그 결과가 다음 행동을 할 사람에게 바로 보이게 합니다.
중간 공유가 잦으면 간섭이 늘어난다고 생각하기 쉽습니다. 하지만 공유의 목적이 승인받기라면 그럴 수 있어도, 잘못된 방향을 빨리 찾기 위한 것이라면 이야기가 달라집니다.
여기서 한 가지 질문이 생깁니다. 중간 결과를 자주 공유하는 문화를 만들었더라도, 그 내용을 다시 정리하고 다음 행동으로 옮기는 일이 또 다른 업무가 된다면 팀은 계속 빠르게 움직일 수 있을까요?
CROS v2: 대화의 속도를 다음 행동까지 이어가려면
이 질문에서 CROS v2로 자연스럽게 이어집니다. 빠른 팀에 필요한 것은 새로운 입력 절차가 아니라, 팀이 이미 대화하는 곳에서 중요한 변화와 리스크를 발견하고 다음 행동이 보이게 만드는 구조이기 때문입니다.
CROS Air는 팀이 매일 사용하는 대화 공간과 연동해, 대화에서 리스크를 감지하고 프로젝트 관리에 필요한 내용을 정리하는 방향을 제안합니다. 중간 결과를 공유한 뒤 누군가가 다시 복사하고 정리해야 하는 시간을 줄여, 대화의 속도가 실행의 속도로 이어지게 하는 접근입니다.
“아직 덜 됐습니다”를 편하게 보여줄 수 있는 팀은 실패를 없애는 팀이 아닙니다. 실패가 커지기 전에 발견하고, 다음 선택을 더 빨리 하는 팀입니다.
팀의 속도가 느리다면 구성원이 게을러서가 아니라, 판단할 수 있는 결과가 너무 늦게 나타나거나 그 결과가 다음 행동으로 이어지기까지 불필요한 정리가 반복되는 구조인지 살펴볼 필요가 있습니다.