매니저들은 내가 새로운 아이디어를 언급할 때마다, “안 돼! 또 다른 은 총알은 없어!” 라고 보는 것 같았다. 그러나 매니저들 중 한 명은 나의 아이디어에서 꼭 지켜야 할 것은 무엇이고? 나의 아이디어에서 중요하지 않는 (지저귀는 새소리) 것이 무엇인지 물어봤다.이러한 질문 방법에 나는 감탄했다.

관리자 들은 조언을 구하기 위해 하나의 아이디어를 두 개의 개별적인 것(장점과 단점을 비교)으로 본다는 것이다.

그래서 나는 모든 매니저에게, 아이디어를 검증하는 팀을 만들 수 있게 도와달라고 요청했다. 각각의 매니저들은 자기 팀에서 한 명의 검증 자를 임명했다.  어느 날 오후에 그 팀을 만났을 때, 나는 짧은 프레젠테이션을 한 다음,질문에 답변을 했다. 나는 필기하고 보고서를 작성했다. 그리고  보고서를 경영진에 전달하기 전에, 임명된 검증 자들의 동의를 얻었다.

이러한 활동은 혁신이 가지는, 장점들을 경영진에 설득하게 만들었을 뿐만 아니라, 내가 생각지도 못한 몇몇 이슈들을 발견하게 되었다. 생각해보면, 경영진이 심지어 회의적인 사람일지라도, 검증 팀은 모든 관련된 혜택으로 경영진들을 자기 주장에 끌어들였다.

Guru on Your Side (구루를 자신의 편으로 가지고 있는) 사람과 매니저와 다른 개발자들을 위한 새로운 아이디어를 평가하는데 흥미를 가진 동료들을 모아라.

여러분은 조직에 새로운 아이디어를 도입하기 위해 노력하는 Evangelist (144)와 Dedicated Champion(129)이다. 몇몇 매니저들과 개발자들이 당신을 지지하더라도, 상당한 아이디어라는 것을 매니저와 개발자들이 일부 보증을 해줄 때까지는 다른 이들은 참여하는 것을 꺼려한다.  매니저와 개발자들은 정보에 질렸다. 매니저와 개발자는 최신의 휼룡한 것들을 미리 대비하지 않는다. 매니저와 개발자는 끝없이 발표된, 은 총알이 보증한 밝은 가능성에 이미 실망했을 수도 있다. 그리고 회의를 느끼거나, 심지어 대부분 논쟁을 야기시키며 일을 진척시키는 것을 꺼려할 수도 있다.

그렇지만, 매니저와 개발자들은 그들의 업무를 쉽게 해주거나, 제품의 품질을 향상시키는 어떤 것에는 항상 흥미를 느낀다. 그들은 단지 믿을 수 있는 증거를 원한다. 보통, 매니저와 개발자는 그들의 같은 부서(그룹)에 있는 Guru (전문가)의 판단을 신뢰한다.   특히 매니저/개발자와 오랜 시간 동안 같이 일해온 Guru를 신뢰한다.그래서 Guru는 항상 최신의 트랜드에 뒤쳐지지 않기 위해 항상 노력해한다. Guru는 전문가(신뢰할 수 있는 지식의 제공자)로써, 사건 문제들을 맡을 수 도 있다. 이런 신뢰할 수 있는 인식이 Guru가 (관리자를 포함한) 거대한 청중들에게 영향력을 미칠 수 있다.

그러므로:

새로운 아이디어를 검증하기 위해, 조직 내에 존경 받는 Guru들로 구성된 검증 팀을 구성해라.

여러분은 Guru on Your Side(158)로써 판단되는 사람들 중에서, 잠재적인 팀 구성원들을 찾는 것부터 시작해라. 이 팀은 경영진과 다른 영향력 있는 사람들로부터 존경을 받게 되고, 유능한 평가자가 될 수 있는 배경(가망성)을 가지고 있다.  Ask for Help (104). (도움을 요청해라). Connector 나 관리자로부터 이름을 얻어내라. 모든 적합한 사람들을 포함해라. 남은 누군가는 상처받을 수도 있다. Guru들 중에 한 명이 회의적인 사람이라면, 여러분은 그룹에서 Champion Skeptic(116)으로써, 그를 포함시킬 수도 있다.

개인적으로, 잘 구성된 검증의 일부게 될 수 있는 Guru 각각을 초대해라. 예산이 허락한다면, Do Food(132)와 Location, Location, Location(189) 해라. 정보 공유 세션을 연속해서 잡거나, 하루나 반 날(half day)짜리 워크샵을 열어라. 검증 팀에게 질문 리스트나 언급해야 할 이슈들을 줘라. 어떤 영역이든지 여지없이 다 밝혀 낼 수 있게 토론을 장려해라. External Validation(148)의 자료들을 포함해라. 여러분은 질문에 대답하고, 고민들을 설명할 수 있도록 준비해라.

경영진을 위한 보고서를 준비해라. 관리지가 “이건 다 뭐에 대한 건지?” 알기를 원할 때, 이 보고서를 사용할 수 있다. 보고서를 통해 발생할 수 있는 질문들에 대한 대답을 준비해라. 그리고 Next Plan(195)을 위한 계획을 준비해라. 만약 이 보고서가 경영진의 몇몇 지원을 만들어 낸다면, 보고서는 기회를 잡을 수 있는 Right Time(207) 계기가 된다.

이 특별 테스크 포스 (task force)는, 혁신을 위해 지속적인 검토위원회가 될 용의가 있다. 이 위원회는 Guru를 포함할 수 있고, Guru는 테스크 포스(task force)를 구성하거나, 관심을 가지고 함께 참여하기를 원하는 다른 이를 지명할 수 있다. 어떠한 지원이든지 Just Say Thanks(183) 할 것을 기억해라.

이 패턴은 존경 받는 동료들의 직접적인 평가를 통해 혁신을 위한 자료들을 생산할 수 있다. 긍정적인 측면에서, 보고서는 (특히 경영층으로부터) 새로운 아이디어에 대한 더 많은 지원을 이끌어 내기 위해 사용될 수도 있다. 하지만 이 패턴의 사용은 위험할 수도 있다. 팀들의 보고서가 긍정적이지 않거나, 몇몇 구성원들이 염려한다면, 새로운 아이디어를 도입하고 하는 노력들이 휴지상태에 빠질 수도 있다. Corridor Politics(126)를 사용함으로써 휴지상태에 빠질 가망성을 막고, 평가 과정 동안 Stay in Touch(221)을 사용해라.

새로운 아이디어에 관한 Brad의 초기 프레젠테이션 끝난 후, 부사장과 그의 직원은 검증을 요청했다. 부사장의 직원 각각은 팀을 평가하기 위해 한 사람을 지명했다. 애초부터 참여해왔던 Innovator들 역시 초청 되었다. 긍정적인 평가가 마친 후, 경영진은 혁신의 능동적인 지지자가 되었고, 조직에 널리 퍼질 수 있게 명령했다.

조직에 Lotus Notes를 도입하기 이전에, 소프트웨어의 안정성에 대한 정보를 모으기 위해, 구성된 다양한 기능(을 검증하는) 정보 수요 위원회(Information Needs Committee)가 구성되었다. 철저한 검증을 이끌어 낸 후에, 위원회는 Note(노트)들을 구현하기 위한 권고사항들을 만들었다. 위원회중 몇몇은 그 다음, 먼저 사용해야 할 어플리케이션이 무엇인지 정의하기 위한 프로젝트 팀을 만들었다.