성과가 아주 좋은 개발자는 그렇지 못한 개발자에 비해 100배 더 뛰어날까? 나는 그런 개발자가 팀을 이끌고 조직을 이끌면 그럴 수 있다고 본다. 그러나 1대 1로 붙었을 때 평균적인 개발자보다 100배가 뛰어나는 것은 불가능하다고 본다. 예를들어 워드 프레스 테마를 초기화하는 문제에대해 뛰어난 개발자는 누구보다 훨씬 빠르게 코드에서 답을 찾아 낼 수는 있겠지만 어떻게 초기화하는게 정석인지 까지 찾는 속도가 100배가 될 수는 없다. 물리적 시간이 필요한 일은 물리적 시간이 들게 마련이다.

그러나 저성과자는 좋은 개발자에 비해 100배 더 비효율적일 수 있다. 목표를 모른다던가, 내가 무엇을 하는 사람인지 모른다던가, 기본 개념을 알지 못한다는 사실을 알지 못한다던가, 남에게 물어보거나 말거는 것이 두렵다던가, 모든 조건이 완비되지 않으면 일을 못한다는 사실을 너무나 강하게 믿는다던가 등의 의존성에 대한 강한 집착도 그런 장애물이 될 수 있다.

여기서 고민은 내가 저성과자와 일할 때 어떻게 해야하는가이다. 여기엔 몇가지 방법이 있다.

첫번째는 숨기는 방법이다. 내가 일을 잘 하냐고 물을 때 그럭저럭 잘한다고 한다던가, 다 되가고 있으니 조금만 힘을 내라고 격려하는 식이다. 이것은 모든 방법 중 가장 최악이다. 이것은 잘 알려진 radical candor가 나오게 된 배경이기도 하다. 이런 칭찬은 오해를 산다. “잘 하고 있다니까 나는 인사고과도 당연히 잘 받겠지” 라고 생각하고 그 외 피드백은 무시한다. 그리고 자기 하던대로만 한다. 참고 참다 나중에 쌓이고 쌓여서 결국 저성과자에게 화를 낸다던가하면 저성과자 입장에선 그야말로 황당하다는 얼굴을 할 수 밖에 없다. 얼마전까진 잘 하고 있다면서 왜 화를 내는가. 결국 숨기는건 절대 답이 아니다.

두번째 방법은 성장을 도와주는 것이다. 이 방법이 가장 전형적인 접근이고, 대부분이 옳다고 여기는 방법이다. 그러나 여기서 주의할 점은 도움을 받는 쪽에서 피드백을 적극적으로 받아 들이고 스스로 성장하고자 하는 욕구가 있어야하고 서로의 방향도 맞아야한다. 피드백이 나빠서 절망한 나머지 아무 것도 안한다던가, 피드백을 듣고는 회사가 하는 일 말고 자기 하고 싶은 일에 에너지를 발산한다던가, 피드백을 듣고는 피드백을 준 사람을 원망한다던가하면 최악의 사이클이 시작된다. 따라서 세번째 방법이 생겨난다.

세번째 방법은 성장을 도와주되 거기에 투자하는 자원을 조절하는 것이다. 생각해보면 우리는 고성과자에게 더 많은 시간을 쏟고 그 사람들의 성장을 더 도와야한다. 일의 진척은 그들에게 달렸을것이며 팀의 성장도 그 사람들에게 달려있다. 저성과자에게 더 많은 시간을 쏟는 것은 팀에게 공헌을 덜 할수록 더 많은 투자를 받는 아이러니를 낳게 되며, 누가 누구를 더 잘 챙겨주는가에 대해 모두에게 잘못된 메시지를 보내게 된다.

사실 세번째 방법은 First, break all the rules 라는 책에서 배웠다. 이 책에서는 효과적인 팀을 이끌기 위해 팀이 자신있게 대답해야하는 12가지 질문들을 알려준다. 그 중 가장 중요한 세가지는 다음과 같다.

1. 직장에서 내게 기대하는 것이 무엇인지 알고 있는가
2. 일을 하는데 필요한 자료와 장비를 갖추고 있는가
3. 늘 내게 가장 적절한 일이 주어지는가

한국어판은 “유능한 관리자”로 아쉽지만 절판되었다. 그러나 아쉬운대로 훨씬 비싼 가격이지만 중고를 구할 수 있으니 일독을 권한다.