10. 동기 부여
모범이 되어야 한다.
많은 리더들은 어떻게 하면 구성원들에게 동기 부여를 할 수 있을지 고민한다. 나 또한 처음 팀장이 되고 나서 어떻게 하면 구성원들이 업무를 통해 기여하며 성장을 위해 노력하도록 동기 부여를 할지 고민했었다. 처음 리더가 되었을 때는 구성원들에게 잘해야 한다고, 열심히 해야 한다고 강요했었다. 그러다 구성원들과 갈등이 생겨서 한참을 고생했었다. 회사에 가면 그들을 봐야 한다는 중압감에 회사를 가기 싫었던 적도 있었다.
언제인가 한 팀원이 인정과 보상에 대해 불만이 있었다. 그리고 연말 평가 면담 때 열심히 해서 높은 평가를 받아도 보상은 크게 차이가 나지 않으니
받은 만큼만 일하겠다
고 했다. 이 말에 당시 나는 어떤 반박도 하기 어려웠다. 그저 그러면 안 될 것 같다고만 했다. 이후 왜 많이 받지 않아도 열심히 일해야 하나에 대해서 고민을 많이 했고, 운칠기삼이라는 말이 떠 올랐다. 운칠기삼에서 중요한 것은
세상은 7할의 불합리가 지배하고 있으나, 3할의 이치가 틀림없이 행해지고 있음을 또한 명심해야 한다
는 것이다. 내가 계속 열심히 잘하고 있으면 언젠가 나에게 기회가 왔을 때 그 기회를 살릴 수 있지만, 지금 열심히 해도 달라질 게 없다는 생각에 대충 하면 좋은 기회가 왔을 때 그 기회를 살릴 수 없다는 생각이 들었다.
이전 회사에서 팀장님 한분이 굉장히 어려운 일을 맡아서 열정적으로 일하시며 높은 성과를 냈었다. 하지만 그분의 업무는 당시 회사에서는 중요하게 보고 있지 않아서 노력과 성과에 비해 낮게 평가를 받았다. 그 팀장님에게 정말 열심히 하셨는데 그만큼 성과로 인정되지 못해서 아쉽다고 말씀을 드렸는데 그 팀장님은
나는 받은 만큼 일하지 않습니다. 나는 받고 싶은 만큼 일합니다.
라며 괜찮다고 했다. 당시 본부장이었던 내 생각보다 훨씬 더 멋진 생각을 지닌 분이었다. 이후 나 또한 그분 말씀처럼 받고 싶은 만큼 일하려고 노력하게 되었다. Kent Beck도 Tidy First에서 일한 만큼 받는 것이 아니라 앞으로 일할만큼 받는 것이라고 말하는 것을 보면 매우 일리가 있는 말인 것 같다.
어떻게 하면 누군가를 변화시킬 수 있나?
Daum 시절 매년 개발자 콘퍼런스가 있었다. 입사 첫 해에 SEDA(Staged Event Driven Architecture)를 주제로 발표를 했다. 거의 50분을 숨 막히게 설명을 했었다. 결과는 참담했다. 이해하거나 동의해 주는 분이 거의 없었다. 그때는 정말 중요하고 어려운 것을 공유했는데 듣는 분들이 그걸 몰라주는구나라고 아쉬웠었다. 내 잘못이 아니라 다른 사람들이 몰라서 알아주지 못한다고 생각했었다.
몇 년 후에 레거시 코드 리팩터링에 대한 강연을 했다. 이때는 설명보다는 IDE를 사용해서 리팩터링을 멋지게 하는 라이브 코딩 위주로 공유를 했다. 예제 또한 책에 있는 것이 아니라 당시 담당하고 있던 게시판 소스를 활용했었다. 이때는 반응이 참 좋았다. 청중들의 눈을 보면 이전 SEDA를 발표했을 때와 달리 공감하는 눈 빛을 느낄 수 있었다.
강연 후 메신저 등을 통해 질문이 꽤 많이 들어왔는데, 주로 핫키가 뭐냐, 어떤 플러그인을 쓴 거냐 등의 질문이었다. 내심 강연에서 사용한 레거시 코드 의존성 분리 기법이나 리팩터링 기법에 대한 질문이 아니어서 아쉬웠지만 그래도 관심을 가지고 질문을 주신 분들이 있다는 것에 기뻐했었다. 그리고 이때 그런 사소로운 질문을 하신 분들은 나중에 "Working Effectively with Legacy Code"나 "Refactoring"을 공부하시는 것을 보고 꽤나 기분이 좋았었다.
그렇다 내가 누군가를 변화시킬 수는 없다. 나 자신도 고치지 못하는 나쁜 습관이 아직도 꽤나 많으니 말이다. 하지만 뭔가 하고 싶은 것을 보여주면 소수라도 따라 하는 분들은 생긴다.
소프트웨어 장인 정신을 쓴 샌드로 만쿠소도 "How do you inspire your team to adopt that mentality(craftmanship. TDD, Pair Programming)" 라는 영상에서 다음과 같이 답을 했다.
- 좌절할 준비를 하라.
- 당신이 원한다고 남에게 영감을 줄 수는 없다. 당신은 당신 자신도 맘대로 하지 못한다.
- 당신 자신의 태도만 제어 가능하고 타인이 나의 태도에 어떻게 반응할지는 제어 불가하다.
- 영감은 부산물(side effect)이다(즉 이를 목표로 할 수는 없다).
- 내가 어떻게 하면 모범이 될 수 있을까?
- 특정 행동이나 특정 기술을 채택하도록 하려면 모범이 되어야 한다.
- “나를 보고 따라 하고 싶어야 한다"
- 기술을 마스터해야 함
- 그러니 모범이 돼라
- 지각하지 말아라. 업무에 기여하라. 긍정적으로 임해라. 사람들을 잘 대하라
- 기술적 훈련(Technical Discipline)에 대해 언급하려면 고도로 숙달되어야 한다
- 키보드로 코딩을 할 때 사람들이 경악을 하도록 해라
- 이렇게 당신이 엄청난 모습을 보여주면 아마도 몇몇 사람들에게는 영감을 줄 수도 있을 것이다
보통 개발자들은 개발을 잘하는 사람들의 말을 잘 따르는 것 같다. 그러니 잘하는 모습을 보여주면 변하는 사람들도 생길 것이다.
동기 부여를 위해 하지 말아야 할 결정을 하지 말아라
얼마 전에 모업체에서 주체하는 스타트업 CTO 님들을 위한 강연에 참여했었다. 주요한 주제는 내가 케이타운포유에 합류하면서 1.6년 동안 겪은 사례를 공유하는 것이었다. 강연을 마치고 나온 질문 중에
개발자들이 회사를 위한 일이 아니라 자신들이 하고 싶은 일을 하는데 어떻게 하면 좋겠는가?
라는 질문이 있었다. 이 질문과 같은 상황을 이전에도 꽤 겪은 나의 답은 못하도록 하라는 것이다. 그 개발자가 그 일로 인해 퇴사를 하는 상황이 발생하더라도 말이다.
우리기 하는 일은 회사나 업무를 위한 것이어야 한다. 회사나 서비스에 도움이 되지 않는데, 개발자의 경력이나 호기심을 위한 일을 해서는 안된다. 그런 일은 집에서 하는 게 맞아 보인다. 사실 난 그런 일은 집에서도 큰 노력을 들이기에는 아깝다고 생각한다.
무언가를 공부하고 연습하더라도 그게 업무를 통해서 가치 창출에 기여하지 않았다면 내가 배운 것이 실제로는 가치가 별로 없을 가능성이 높다. 또 정말 중요한 기술이라도 내가 업무에서 사용할 기술이 아니라면 금방 잊어버리게 된다. 그리고 내가 정말 그 기술을 사용할 때가 되었을 때 그 기술보다 더 좋은 신기술이나 업그레이드가 되었을 수도 있다. 꾸준히 관심을 가지고 적절한 수준으로 공부하다가 정말 그 기술을 업무에서 사용하기 바로 전에 진지하게 공부하는 것이 맞아 보인다.
또, 이런 질문도 있었다.
간단한 기술로 해결할 수 있는 문제인데, 매우 복잡한 기술을 적용해서 시간이 오래 걸린다.
이 경우도 나는 반대한다. 우리는 다양성의 시대에 살고 있다. 한 가지 해결책을 모든 문제에 획일적으로 적용할 수 없다. 만일 한 가지 해결책으로 모든 문제를 해결하고자 한다면 모든 문제를 해결할 수 있는 가장 복잡한 해결책이어야 할 것이다. 그런 복잡한 해결책은 대부분의 문제를 풀 때는 과한 해결책이어서 비효율적이다.
개발자는 향후의 모든 변경을 잘 예측해서 미리 준비하는 것을 지향해서는 안된다. 이런 방식은 개발자가 아니라 예언가에게 적합한 방식일 것이다.
개발자는 당장의 문제를 빠르고 효율적으로 풀고, 향후 변경을 낮추기 위한 적절한 수준의 설계 개선을 해서 향후 변경이 요구되었을 때 빠르고 안정적으로 대응할 수 있어야 한다.
개발자들이 하고 싶은 일을 못하게 하면 그 개발자들이 떠 날까 봐 우려될 수 있다. 하지만 그 일을 하게 허용하더라도 대개는 약간 더 있을 뿐 그 일을 한 것을 이력서에 추가해서 떠나는 경우가 더 많았다. 그리고 남은 인력들은 불필요한 기술로 과하게 복잡해진 시스템을 운영하는 부담을 떠 앉게 된다.
결국 동기부여는 스스로해야 하는 것이다.
누군가를 우물로 나를 데려갈 수는 있어도 물을 마실지 말지는 그의 결정이다.
그들에게 좋은 것을 많이 보여줘서 하고 싶은 마음이 들도록 하는 것이 리더들이 할 수 있는 일이라고 생각한다. 자신이 모범이 되면 제일 좋고, 그렇지 못하다면 조직 내에 모범이 될 만한 개발자를 통해서라도 좋은 모습을 조직 내에 많이 보여주는 것이 좋을 것이다.
