동기부여는 환상이다: <하이 아웃풋 매니지먼트>의 5가지 동기부여 이론
(stdy.blog)직원의 성과가 저조한 이유는 두 가지다. 역량 부족과 동기 부족이다.
어느 쪽이 부족한지 구분하는 방법은 단순하다. 목숨이 걸렸더라도 못 한다면 전자다.
관리자의 결과물은 곧 그가 관리하거나 영향력을 미치는 팀의 결과물과 같다. 팀이 좋은 결과물, 즉 좋은 성과를 내려면 팀으로서의 시너지도 중요하지만 개별 직원의 성과도 중요하다. 높은 역량을 갖추고 동기가 충만하여 고성과를 내는 직원이 얼마나 존재하느냐에 팀 성과가 큰 영향을 받기 때문이다.
따라서 관리자의 가장 중요한 업무는 직원이 최고의 성과를 내도록, 즉 직원의 역량과 동기가 높아지도록 돕는 것이다. 이를 위해 관리자가 할 수 있는 행동은 크게 세 가지다.
- 교육과 훈련을 통해 직원의 역량을 향상시킨다.
- 직원의 욕구를 자아실현 단계로 끌어올려 스스로 동기를 부여하도록 한다.
- 동기가 충만한 직원들이 잘 활동할 수 있는 환경을 조성한다.
앤디 그로브는, 동기는 내면에서 나오는 것이므로 타인이 동기를 부여하는 게 불가능하다고 생각했다. 그래서 직원 스스로 동기가 부여되도록 욕구를 자극하고, 그 욕구가 유지되도록 돕는 게 관리자에게 최선이라고 믿었다.
관리자가 직원의 욕구를 자아실현 단계로 효과적으로 끌어올려 유지하는 방법은 무엇일까? 책에 명료하게 나오진 않았지만 책의 내용과 내 머릿속 내용을 조합하여 5가지를 만들어보았다.
1. 교육과 훈련
자아실현 욕구는 역량을 높이고자 하는 욕구와 성취를 높이고자 하는 욕구로 나뉠 수 있다. 즉 교육과 훈련은 역량 향상의 도구이지만, 동시에 자아실현 욕구를 높이는 도구도 될 수 있다.
2. 손에 잡히는 결과물을 중시하고 인정해주는 환경
교육을 통해 지식이 쌓이더라도 그것만으로는 아직 성과가 나온 게 아니다. 향상된 역량이 성과로 이어지게 하려면, 단순히 지식욕을 채우거나 시도해보는 데서 그치지 말고 결과물을 만들어내는 분위기를 조성해야 한다.
3. 도전적인 목표 제시
현재 역량에서 최선을 다해도 달성 가능성이 70% 정도일 수준으로 맞춰서, 성취욕을 자극하면서도 효능감을 떨어뜨리지 않게 하자.
4. 스스로를 측정하는 지표 수립
자아실현 욕구 단계에 이른 사람은 자신의 성취를 측정하는 방법이 필요하며, 가장 좋은 측정 방법은 본인의 성과에 대한 피드백이다. 관리자가 팀의 중요 업무에 관련된 성과지표를 설정하고, 그에 기반해 적절한 피드백을 남기면 직원들이 이를 본인 성취를 측정하는 가이드라인으로 삼을 수 있다.
5. 실험과 실패를 장려하는 환경
자아실현 욕구를 위협하는 가장 큰 적은 실패에 대한 두려움, 또는 실패로 인한 역량 퇴보 및 성취 저하의 두려움이다. 장기적으로 더 좋은 결과물을 내는 데에 실험과 실패가 필수적임을 관리자가 주지시킨다면, 이런 두려움으로 인해 직원들이 지나치게 보수적으로 행동하는 일이 줄어들 것이다.
아 그렇게 느끼셨군요. 저는 사실 이 책이 상당히 따뜻하고 인간적인 책이라고 생각해요. 첫문단은 제가 너무 요약했나봅니다.
이 글은 ”목숨 걸렸어도 못하는 게 있냐? 그냥 해라“ 같은 건 전혀 아니라고 봅니다. 예를 들어 저자는 “나한테 갑자기 바이올린 연주하라고 하면 목숨 달렸어도 못한다“는 이야기를 했어요.
그래서 저는 관리자가 역량에 맞는 일을 주고 있나? 를 잘 판단해야 한다는 의미로 받아들였습니다.
몇가지 가정이 있어야 한다고 생각합니다.
- 회사에서 제시하는 정확한 방향성이 있다.
- 방향성에 알맞은 목표들이 제시되어있다.
- 목표를 달성하기위해 주기적인 관리가 진행되고 있다.
당연히 신입 또는 이러한 과정이 처음인 직원들은 제대로된 목표 설정이 어렵습니다.
매니저도 처음보는 직원이라면 어느정도 감으로 할뿐 쉽게 되지는 않습니다.
스프린트를 도입하고 스프린트 단위로 목표 달성률을 보고 회고를 하거나, 월별, 분기별로 목표를 수립하고 달성지표를 지속적으로 관찰 후
결과에 따라서 다음 목표를 좀더 상향시킬지 하향시킬지 결정을 하는 과정의 반복을 통해서 평균적인 수치를 찾아갑니다.
(이런 데이터가 굉장히 많은 회사라면 이런 과정이 최소화되겠죠)
물론 하향에도 적정선은 있어야 합니다. 누가봐도 최소치도 못하는 사람은 문제가 있으니 혼내든 뭘하든해야겠죠
이런 목표를 설정하는것도 훈련과 교육이 많이 필요하다고 생각이 드는데 대부분의 회사에서는 이런곳에 비용을 쓰기 싫어하는게 현실이죠 ㅜㅜ
제가 겪은 회사들중에서는 이런 관리를 잘한 회사는 한곳 정도였고, 나머지는 말로만 okr혹은 무슨 관리방법 어쩌고하지 실제로는 알아서 목표 세우고 알아서 지표도 세우고 알아서 평가도하고 그랬던거 같네요...
저 자신에게도 부끄러운 얘기지만 실무를 이해하고 일을 쪼개며 그에 따라 의사결정을 할 줄 아는 기술 매니저는 제가 일하면서 겪은 바로는 거의 보기 힘들었습니다. 보통은 경력과 연차때문에 매니징을 하게 되고 전혀 기술적인 배경이 없는 사람이 전체 개발자를 매니징하는 경우더라고요. 백엔드 개발자출신 매니저가 한 프로젝트에서 프론트엔드 개발자까지 매니징하게 되고, 적당히 자세한 수준의 설계와 지시사항은 없이 그냥 실무자에게(대부분 저연차 개발자에게) 기계적으로 이슈 생성하고 기능 이름만 던지는..
우리나라의 개발 조직문화는 바뀌긴 할런지 이젠 의문점만 남습니다.
물론 정량적으로는 어려울 것 같고요.
관리자마다 하시는 방식이 다르겠지만, 저라면 참여자들의 자신감으로 정성적 측정을 할 것 같습니다.
예를 들어, 참여자가 직접 본인 작업에 대한 자신감을 평가하게 하고
- 어느정도 시간이 주어지면 무조건 가능하다
- 불확실한 부분들이 어느정도 있긴 하지만, 예전에 해본 것과 유사한 면들이 있어서 할 수 있을 것 같다
- 시작은 어떻게든 해볼 수 있겠는데 마무리는 어떻게 할지 아직 모르겠다
- 어떻게 해야 할지 완전히 각이 안 보인다
2번으로 셀프 평가한 작업을 주고
1번이라면 더 어렵게 만들고 (시간제한 추가, 제약조건 추가 등)
3번이라면 더 쉽게 만들고 (코치 추가, 도구 추가, 스펙 줄이기 등)
이런 식으로 할 것 같네요.