EB 되짚어 보기
EB들은 자신의 테두리를 전체의 테두리라 굳게 믿고, 지역적 최고점에 도달해 배움을 멈춘 개발자를 뜻했다.
시야가 좁아서 큰 그림을 볼 수 있는 능력이 없으니 자신이 Expert가 아님을 인지하지 못한다.
단순히 특정 기술을 싫어하거나 사용해보지 않았다고 EB는 아니다. 내가 하지 않은 것이 값어치 있는 게 아니라고 결론 짓는 자기중심적인 마인드를 말한다.
또 다른 EB의 특징은 일반적으로 집단 내에서 권위를 가진 위치에 올라 있다는 것이다.
AB는 초심자중 조금 더 성숙한 수준에 있는 것이지만 EB는 아이러니하다.
보통 Expert는 스스로가 그렇게 생각해서 쓰거나 그 사람보다 지식이 부족한 동료가 불러주는 명칭이기 때문이다.
EB가 되기 매우 좋은 조건은 쉽게 성공할 수 있고 요구되는 기준이 낮으며, 진짜 전문가는 존재하지 않고, 경쟁도 없으며, 외부와의 교류도 없는 것이다.
한 부분에서 발생한 부패가..
어떻게 EB가 집단의 전문성을 퇴화시킬까?
볼링장의 매출이 선수가 얼마나 볼링을 잘 치냐에 달려있다고 가정해본다. 나는 스타트업 볼링장에 다닌다. 내 실력이 빠르게 느는 걸 발견하고 볼링장도 돈을 벌고 완벽하다.
내 평균이 150쯤, 볼링장을 조금 더 확장해서 초보 선수를 영입해 내 밑에서 일하기로 결정한다. 그들의 첫 출근날 어떻게 나처럼 공을 드는지, 걷는지를 가르친다. 그들이 구멍을 어디에 쓰냐고 물어보면 나는 그냥 아 그건 신경쓰지마. 여기선 그거 안 써. 라고 대답한다. 열심히 하는 모습을 보이려고 그대로 따라서 점수가 오른다.
나는 점수에 정체기가 온다.
대부분은 내 식대로 하는 데 만족하고 몇몇은 여유 시간에 따로 연습한다. 나에게 TV에서 손가락을 공 안에 넣고 쳐서 엄청 높은 점수를 내던데요. 200이상! 라고 말한다.
그들은 그들만큼 내가 성장에 관심 있길 바라지만 난 그렇지 않다.
나는 너희 태어나기 전부터 볼링을 했고 내가 제일 잘 알아. TV를 다 믿으면 안돼.
나는 결정권을 상기시키고 집단의 혁신을 빠르게 제거한다. 완벽히 불합리한 추론이자 불만족한 대화다.
절반은 아직도 열정적으로 연습해서 그들의 점수가 나의 점수를 제쳐 접근법의 우수함을 증명한다.
하지만 나는 화를 그들에게 화를 내며 설교한다.
그들은 역행하는 볼링장, 고집 때문에 저급한 방법을 선택하지 않는 곳으로 떠난다.
... 전체를 오염시킨다
떠나지 않은 볼링 선수는 두 가지 교훈을 얻는다.
1.
기다리면 실제 능력과 관계 없는 권력을 얻을 수 있게 된다.
2.
그저 그런 상태로 있는 게 더 좋을 수도 있다.
EB는 EB의 문화를 생성한다.
채용 프로세스에도 영향을 미친다.
열정 넘치는 신입을 만나기 싫은 나는 그저 그런 “팀 플레이어"를 모집하는 방향으로 바꾼다.
나의 위치를 위협하지 않을 팀 플레이어들. 그렇다고 그들이 큰 그림을 보게 됐다고 볼 수 없다.
이는 무의식이나 합리화에 가깝다. 나보다 더 나은 사람들을 채용하지 않겠다 가 아니라 이 사람들은 나의 고정관념을 깬다거나 전문적인 방법과 어울리지 않아 라고 생각하는 것이다.
C나 E 수준의 작업과 무능한 수준의 작업을 구분할 정도의 지식도 갖추지 못하여, 둘을 혼동할 가능성이 있다.( 볼링 면접에서 결과가 아닌 자세에 집중해서 220점인 선수가 내 자세랑 다르다는 이유로 나쁜 선수라고 생각할 수 있다는 것 )
이는 볼링장을 EB에 빼앗기는 것이고 브루스 웹스터가 말한 ‘사해 효과(Dead Sea Effect)가 완성, 실현되는 단계다.
현실로 돌아와서
소프트웨어 개발 환경에 적용해보는 건 간단하다.
자동화 테스팅의 부재, 거대한 함수나 클래스들, 수많은 복붙 코딩, 오래 되었거나 적절하지 못한 툴 사용, 프로세스 등등이 있지만 중요한 건 부족한 지식으로 점철된 치명적인 문화의 사람들이 힘 있는 위치에 있단 것이다.
개인의 문제이고 고집 세고 무능한 사람들에게 책임을 맡겨서 생기는 일이라 여길 수 있지만 나는 조금 더 심오하다고 생각한다.
EB는 사실 인격적인 문제는 없을 수도 있다. 외부와 격리된 환경, 낮은 기대치, 효율성 산출이 불가능한 그저 그런 수행 능력에 대한 꾸준한 보상이 만들어낸 자연스런 결과라 본다.
우리 산업의 특성은 릴리즈 일정이 늦어지고, 버그는 많고 예산이 초과됐을 때 따로 릴리즈 팀을 운영하는 회사가 많은가?? 제대로 관리하기 힘든 앱을 포기하고 처음부터 다시 작성하는 팀은??
추락하는 로켓을 만들고 승급하는 로켓 기술자마냥 그들은 승급하고 포상을 받는다.
“너도 많이 배웠을테니까 너를 수석으로 승급시키고 두번째 버전의 설계를 맡길게"
소프트웨어에 대한 기대치는 로켓보다 낮기 때문에 더더욱 용인된다.
외부 피드백과 자신의 인식에 따라 얼마나 쉽게 자신의 실력을 오해하는지를 말하고 싶다.
정체하지 않고 진전하는 문화 만들기
집단의 부패를 최대한 방지할 간단한 방법을 제시해본다.
1.
EB의 덫에 빠지지 않기 위해 제일 중요한 건 자신의 들뜬 감정을 믿지 않는 것이다. 적절한 자신감은 좋으나 이성적인 주장/증거 없이 학습이 완성되었다거나 질문을 받을 필요도 없다는 생각을 지양한다. 건강한 겸손함과 지속적으로 성장하기 위한 노력을 겸비하고, 객관적 수치들을 주관적인 고려사항들보다 우선순위에 둔다면 EB로부터 충분히 거리를 둘 수 있을 것이다.
소프트웨어 집단에서 막기 위한 방법도 있다.
1.
팀 멤버에게 최대한 자유로운 상상의 기회를 주고, 그들이 발견한 방법을 직접 보여주도록 독려한다.(실패에서 배우는 게 더 많다.)
2.
새로운 언어, 접근법, 프레임워크, 패턴, 스타일 등을 학습하는 것에 대한 인센티브를 제공하라.
3.
특정 주장이 더 낫다고 평가하거나 수용할 때, 절대로 그 사람의 연차를 근거로 삼지 말아라.
4.
외부의 의견을 사내에 강제로 주입받을 수 있는 정책을 만든다.(점심시간 네트워킹, 월간 트레이닝, 감사 등)
5.
가능하다면 논쟁이나 의견 충돌이 있을 때 직급이나 투표 등의 주관적인 기준이 아닌 객관적인 기준으로 해결해라.
6.
“증명하는 문화(culture of proof)”를 만들어라. 실제 레퍼런스, 통계, 사실이 확인되지 않으면 없는 의견이다.
7.
주기적으로 주니어와 시니어를 아우르는 설문을 진행하라. 그들의 강점과 그 개수만큼의 모르는 것/알고 싶은 것에 대해 작성시켜라. 직원들이 자신이 모든 걸 다 안다고 생각하는 분위기를 미연에 방지하기 위해서다.
우선적으로 매니저와 팀 리더를 위한 것이지만 멤버들도 가능하다. 만약 소용없다면 이미 가망이 없으니 가능성 있는 곳으로 떠나라.
팀원 누구든지 “모르겠다.”라는 답을 할 수 있는 문화를 만드는 것이 중요한 방책이다.
EB는 절대로 “모르겠다.”라는 답을 하지 않는다.
이는 기술을 배우고 있는 사람과 자신이 이미 알건 다 안다고 생각하는 사람 사이의 중요한 차이다.
그룹이 성장하지 않고 있으면 부패하는 것이다.
