“제대로 하지 않았잖아요” - 프레임워크의 실패를 실행 탓으로만 돌릴 때

• WP Engine에서 교육과 개별 코칭까지 거쳐
  OKR 도입을 네 차례 시도했지만 모두 실패. 매번 “제대로 하지 않았다”는 답만 돌아온다면, 프레임워크가 조직에 맞는지도 물어야 함
• 실패할 때마다 더 정확한 이해와 실행을 요구하면서
  무엇이 ‘제대로’인지 정의하지 않으면, 아무리 실패해도 프레임워크 자체는 틀릴 수 없는 구조가 됨
• 프레임워크는
  기성복처럼 입어 보고 수선하는 것에 가까움. 조직의 문화와 사람, 기존 업무 방식에 맞춰 조정하고, 맞지 않으면 다른 것을 선택
• 전사 도입을 선언하기보다
  한 팀이 한 분기 동안 시험하며 맞는 부분과 맞지 않는 부분을 확인. 이는 반대자를 설득하는 요령이 아니라 실제로 적합성을 알아가는 과정임
• 효과가 있었던 지표 운영도
  팀이 스스로 중요하게 여기는 지표 하나에서 시작해 점차 확장. 영향을 미칠 수 있어도 완전히 통제하지 못하는 결과까지 책임지게 하지는 않았음

네 번의 OKR 도입 실패

• WP Engine에서는
  OKR을 네 차례 도입하려 했으며, 범위는 개별 팀부터 부서, 전사까지 달랐지만 모두 실패함
• 준비가 없었던 것은 아님. 관리자들이 John Doerr의
  《Measure What Matters》 를 읽고, 유료 교육과 발표, 일대일 코칭까지 진행함
• OKR은 Intel에서 시작해 Google에서 성장했고, 수많은 기술 기업으로 확산되며 책, 글, 팟캐스트, 강좌와 코칭 산업을 만들어 냄
• 전문가들에게 실패 원인을 물으면 자주 돌아온 답은 “
  제대로 하지 않았다”였음. 그러나 제대로 실행하기가 그만큼 어렵다면 프레임워크 자체가 적용하기 너무 어려운 것일 수도 있음
• 많은 조직이 OKR의 효과를 확신하므로, 이 경험만으로
  OKR은 작동하지 않는다고 결론 내릴 수는 없음

다른 프레임워크에서도 반복되는 해명

• Scrum 창안에 참여한 Ron Jeffries는 이 문제를
  Dark Scrum이라고 부름. Scrum은 어느 정도만 잘 실행해도 좋은 프레임워크이지만, 현실은 좋은 아이디어에 미치지 못할 때가 있음
• Scrum에서 실패한 팀이
  Kanban 같은 다른 프레임워크로 성공했는데도, 이전 실패에는 “제대로 하지 않았다”는 해명이 따라붙음

jobs-to-be-done을 실행하고 점검 항목을 모두 충족해도 회사가 실패할 수 있음. 이때도 “실제로는 올바르게 실행하지 않았다”는 답이 나옴

• Salesforce에서 Aaron Ross가 성공시킨
  잠재 고객 발굴과 계약 성사의 분리를 수천 개 SaaS 기업이 따라 했지만, SDR 팀이 실패한 경우도 있었음
• 흔한 해명은 적응 기간 부족, 잘못된 접촉 주기, 채용 실패, 관리 실패였음

콘텐츠 마케팅을 2년 동안 진행하고 글 200개를 게시해도 자연 유입이 정체될 수 있음

• Zappos는
  Holacracy를 전면 도입했지만, 직원의 18%가 퇴직 보상금을 받고 떠났고, 몇 년 뒤에는 도입을 되돌림
• 같은 시기 도입한 다른 기업 중 Jason Cohen이 알고 있는 기업도 모두 이전 방식으로 돌아감
• HolacracyOne은 올바르게 구현하지 않았기 때문이라고 봄

정밀성의 오류와 반증 불가능성

정밀성의 오류는 프레임워크가 언제나 작동하므로 실패는 반드시 실행자의 잘못이라는 전제에서 출발함

• 더 정밀하게 이해하거나 실행했다면 성공했을 것이라고 믿지만, 그 정밀성의 기준은 정의되지 않았거나 따라 하기 불가능할 만큼 복잡함

• 핵심 문제는
  반증 불가능성임. 아무리 유능한 팀이 성실하게 여러 번 시도해 실패해도, “이 팀에는 맞지 않는다”거나 “이런 조건에서는 쓰면 안 된다”는 판단에 도달하지 못함

• WP Engine의 네 차례 실패도 OKR의 보편적 적용 가능성을 반박하는 증거로 인정받지 못함

• 팀이 다른 프레임워크를 도입해 성공한 경험도 첫 프레임워크가 맞지 않았다는 증거로 받아들여지지 않음

• Karl Popper는 Marx와 Freud의 이론을 지지하던 주변 사람들이 무슨 일이 일어나든 이론이 확인됐다고 여기는 현상을 관찰함. 어떤 증거로도 반증할 수 없는 이론은 유효한 이론이 아님

• 프레임워크에는
  작동하는 맥락과 작동하지 않는 맥락이 있음. Cohen은 작동하지 않는 경우가 더 흔하다고 봄

옷을 입어 보고 수선하듯 적용하기

• 프레임워크 없이 시작하는 일은
  셔츠를 처음부터 직접 만드는 일과 비슷함. 만드는 법을 모르는 상태에서는 엉망이 되기 쉬우며, 이미 혼란스럽기 때문에 프레임워크를 찾는 경우도 있음

• 프레임워크 도입은
  기성복 구매에 가까움. 적어도 일부 사람에게는 잘 맞지만, 다른 사람에게는 몇 군데 수선이 필요한 것이 자연스러움

• 맞는 부분과 맞지 않는 부분을 확인해 조정하면 됨

• 너무 맞지 않아 수정으로 해결할 수 없다면, 그 경험을 바탕으로 다른 프레임워크를 더 잘 선택할 수 있음

• 프레임워크는
  조직의 문화, 사람, 다른 프로세스와 구성원들의 바람에 맞아야 함. 창안자나 지지자조차 어떤 조건에서 성공하는지 정확히 모르는 경우가 많음

• 전사에 “OKR로 전환한다”고 선언하면 즉시 반대자가 생기고 도입이 실패할 가능성이 있음

• 대신 “
  한 팀이 한 분기 동안 시험한다”고 시작하면 무엇이 좋고 나쁜지 확인하는 실험이 됨

• 반대자를 설득하기 위한 말 바꾸기가 아니라, 실제로 적용해 보고 조정하거나 다른 방식을 선택하는 절차임

WP Engine에서 효과가 있었던 지표 운영

• Cohen이 이끈 팀에서는 직접 만들고 피드백으로 조정한
  지표 프레임워크가 효과를 냄

• 효과가 있었던 이유는 OKR보다 본질적으로 우월해서가 아니라, 구성원들이
  스스로 원하는 방식으로 책임을 지게 했기 때문임

• 영향을 미칠 수는 있어도 완전히 통제하지 못하는 결과까지 책임지게 하지 않았음

• 경영진이 팀이 믿지도, 존중하지도, 관심을 갖지도 않는 KPI를 요구하면 결국 팀이 이김

• 도입은
  한 팀, 지표 하나로 시작함. 지표 체계의 어느 위치에서 고르든 상관없었고, 목표도 느슨하게 정할 수 있었음

• 유일하게 중요한 조건은 관리자의 요구나 회사에 좋다는 이유가 아니라, 구성원 자신이 그 목표를 원해야 한다는 것이었음

• “이것이 충족되지 않으면 우리는 일을 제대로 하는 것이 아니다” 또는 “달성하지 못하면 우리의 전문성을 발휘하지 못한 것이다”처럼 개인의 자부심과 연결돼야 했음

• 한 분기 동안 그 지표를 추적한 뒤,
  추가할 지표 한두 개를 검토함. 한꺼번에 열 개를 더하는 대신 이미 받아들인 지표에서 바깥으로 확장함

다른 조직에 맞는지는 직접 시험해야 함

• WP Engine의 해당 팀에서 성공했다고 해서
  다른 조직에서도 성공하는 것은 아님
• 그대로 맞을 수도, 조정한 형태가 맞을 수도, 완전히 다른 방식이 필요할 수도 있음. 우선 하나를 골라
  직접 시험해 보는 것이 출발점임

댓글과 토론