업무 평가 하기
과연 개발자의 업무 평가를 제대로 하는 것이 가능할 것인가라는 주제는 논의가 많습니다. 그럼 반대로 '개발자의 업무평가를 하지 않는 것은 가능할까'라는 질문을 해보면 어떨까요?
아마도 초조해하시는 분들은 관리자 들일 확률이 클 겁니다. 인사고과도 매겨야 되는데 어떻게 하란 말인가라고 말이죠. 반면에 일반 개발자들은 그냥 평범할 수도 있을 겁니다. 대부분 그런 것과 상관없이 일해왔을 확률이 크기 때문입니다.
어떤 조직은 '일정 준수'에 대해 책임을 묻겠다는 조직이 있긴 합니다만, 하나 궁금한 것이 있습니다. 그 일정 엔지니어들이 잡은 것인가요? 책임을 진다는 것은 그 의사 결정에 참여해야 의미가 있습니다. 만약에 엔지니어가 잡지 않은 일정에 대해 책임을 지라 하고 고과를 매기겠다면 이것은 남이 변을 보다 말았으니 네가 보시라는 것과 똑같은 이야깁니다. (쾌변 하세요, 꼭.)
제가 이런 이야기를 하는 이유는 이렇습니다. 개발 업무의 특징은 집단으로 하는 공학이란 겁니다. 솔직히 다소 '집단예술'에 가까운 일입니다. 한 사람이 특출 나게 뭔가 잘해서 되는 경우보다는 같이 '협력'해서 얻어지는 이익이 많습니다. 그렇다면 그 '협력'이 바로 이른바 '황금알을 낳는 거위'인데 이 거위에게 어떻게 먹이를 주시겠습니까?
곶감이 잘 되려면 감나무 혼자 퇴비 많이 먹는다고 되는 게 아닙니다. 날씨와 사람의 노력 모두가 잘 되어야 하는 것입니다.
협력을 깨는 보상/평가는 차라리 안 해야 합니다. 그럼 아무것도 안 하고 있으면 될까요? 아닙니다. 바로 그 협력의 '단위'를 보상하는 겁니다. 팀에 대한 보상을 키우고 팀 간의 협력으로 일군 성과에 대해 더 가치 있게 평가하라는 것입니다.
그럼 누구를 승진시킬 것인가를 놓고 또 머리 쓰실 분들이 있을 것입니다. 하지만 이미 팀에서는 알고 있을 겁니다. 와인버그의 말 대로 '모든 사람이 문제 해결에 참여하게 해주는 사람이 리더'입니다. 그리고 이미 팀은 그 사람을 알고 있습니다. 관리자만 모를 공산이 크지요.
그러한 사람들의 헌신을 무시하거나 혹은 모른척한다면 아마 인력이 썰물 빠지듯 빠질 겁니다. 어떤 회사는 매년 업무실적을 평가하는데 늘 일부러 '깎아'주는 문화가 회사 안에 있었습니다. 무언가 한 것보다는 못한 것을 더 찾아서 고과를 깎는 식으로 평가를 준겁니다. 결과는 매년 1/4 정도의 인력이 물갈이되었고 무엇보다 이들이 나가면서 한 번도 후임자에게 제대로 업무 인수인계를 한 적이 없었습니다. 모든 업무의 지연은 물 보듯 뻔했습니다.
냉정한 평가를 내려야만 하는 순간이 있겠지요, 그렇지만 냉정한 평가는 스스로 하게 해야 합니다. 인사고과를 깎는 식의 평가보다는 차라리 조직의 회고 문화를 통해 스스로 교정 해나가게 하는 것이 더 효과가 있습니다. 잘못한 사람은 이미 자신의 잘못을 알고 있는 경우가 많습니다. 다만 이를 스스로 부정하는 사람과 인정하고 고치는 사람이 있습니다.
그렇게 하지 못할 바에는 차라리 후하게 점수를 줘서 기분 좋게 하는 게 낫습니다. 서로 높은 에너지를 가진 상태에서 '우리 그런데 좀 개선할 바는 없나?'라고 서로 이야기하게 해서 스스로 조직이 문제를 해결할 수 있는 힘을 길러줘야 할 것입니다.
이때 반드시 필요한 것은 '다른 시선'이 필요합니다. 개인적으로는 시뮬레이션을 하되 회사 밖의 조직이라든가 혹은 다른 부서의 사람들을 놓고 팀을 관찰하는 역할을 맡겨서 하는 것도 좋은 방법일 것입니다.
간단히 정리하자면 이렇습니다.
- 개발자가 공언한 일정/계획이 아닌 것에 대해서는 고과를 매길 수 없습니다. 매기는 순간 그 개발자는 다른 회사 사람이 됩니다.
- 협력을 증진시키는 방식으로 고과를 매기는 것이 좋습니다. 팀 단위로 고과를 매겨보십시오. 그중 승진 대상자는 그 팀의 협력을 증진시키거나 효과를 높인 사람을 찾아 하면 됩니다.
- 조직이 에너지를 얻은 상태에서 스스로를 돌아볼 수 있는 자리를 만들어 주십시오. 시뮬레이션 같은 방법을 이용하시길 권합니다. 이때 타 조직의 사람들이 관찰을 해주고 그 이야기를 들을 필요가 있습니다.
아래 비디오의 영상을 꼭 보시길 권장드립니다.
