“모듈을 재사용이면 금방 끝나겠죠?” 그렇게 생각한 프론트 태스크가, 무려 ‘20일’의 일정으로 돌아왔습니다. 이유를 들어보니… 모듈을 새로 만들고 싶다는 것이었습니다. 그런데 단 5일 만에 끝났습니다. 무슨 일이 있었던 걸까요?
저는 오랜 기간을 개발조직을 리드하는 역할을 해 오고 있습니다. 주 업무는 소프트웨어를 만드는 개발자분들이 의미 있는 성과를 낼 수 있도록 매니징하는 역할입니다. 지난 시간 이 업무를 맡고 다양한 경험을 해오고 있는데 오늘은 그 중에서도 핵심적인 매니징 업무인 개발자 분들을 동기부여시키는 진행과정에 대해 기록을 남겨보고자 합니다.
개발조직을 리드하면서 늘 느끼는 건, “동기부여된 사람”과 “시켜서 하는 사람”은 완전히 다르다는 사실입니다. 이는 비단 개발자에 국한되는 얘기는 아니라고 생각합니다.
회사를 구성하는 한 명 한 명은 모두 회사의 성장에 기여하기 위해 맡은 역할이 있습니다. 매니저의 가장 중요한 역할은 그들이 제 역할을, 그리고 그 이상을 하도록 돕는 것입니다. 적합한 임무를 할당하고 그 임무를 잘했는지를 체크하고 평가하는 것이 기본적인 관리라고 한다면 동기부여를 시킨다는 것은 단순히 맡겨진 임무를 수행하는 것을 넘어서서 그 일을 정말 하고 싶기에 만드는 것입니다. 구성원이 동기부여가 되지 않으면, 일은 시켜서만 합니다. 그러나 스스로 하고 싶어지면, 예상을 뛰어넘는 성과가 나옵니다. 이 두가지는 큰 차이가 있습니다.
가장 큰 차이점은 사고방식이라고 생각합니다. 하고 싶은 일이 아닌 지시를 받고 하는 일이라도 어떻게든 해낼 수 있습니다. 이 프로세스가 굉장히 잘 짜여진 대기업같은 곳은 사실 구성원이 그렇게만 해주더라도 사업의 목적을 달성하기에 큰 어려움이 없습니다. 물론 큰 어려움이 없을 뿐이지 맡은 임무만 수행하는 과정에서 여러가지 문제는 생길 수 있습니다. 가령 맡은 일이 아니라면 굳이 더 하지 않기도 하구요, 그레이영역에 있는 업무들은 쉽게 방치되기도 합니다.
이는 시스템이 잘 짜여진 큰 기업보다 새로운 문제들이 시시각각 생겨나는 작은 기업들에서 더 문제인데요. 작은 기업들은 새롭게 시도하거나 몰랐던 것들을 해결해가는 가운데 정확히 할당이 어려운 그레이영역의 업무가 많기 때문입니다.
동기부여가 된 구성원, 그런 구성원들이 있는 조직은 그런 그레이영역에 대해 니것, 내것 구분을 가지지 않습니다. 일을 주도적으로 처리하기 때문에 누가 할지 모르겠다면 우리가 하자의 입장이 당연시되고 그렇게 하나하나 진행되는 과정에서 발생하는 문제를 더 빠르게 해결해 나갈 수 있습니다.
이 질문에 대한 답은 아마도 많은 유능한 관리자분들이 저마다 조금씩 다른 생각을 가지고 있을 거라고 생각합니다. 그 동안 여러가지 방법을 사용해보았습니다. 비즈니스의 맥락을 자세히 설명해주면서 이 일을 왜 해야 되는지 알려주기도 해보고, 실무를 같이 하면서 동기부여된 모습을 보여주면서 따라오기를 바라기도 했습니다. 칭찬과 격려를 해주기도 하고 일이 잘 진행되고 있지 않을 때는 기대하는 모습을 조목조목 알려주기도 했습니다.
그러다가 몇가지 결론이 서게 되었습니다.
첫 번째, 개개인의 성향을 잘 파악해야 합니다. 먼저 사람마다 동기부여될 수 있는 경우가 제각각 다릅니다. 어떤 사람은 인정욕구가 높아서 그 인정을 타이밍에 맞게 잘 해줄 때 동기부여가 잘 됩니다. 어떤 사람은 성장욕구가 높아서 그 사람이 스스로 성장할 수 있는 업무를 잘 줄 때 동기부여가 됩니다. 어떤 사람은 비즈니스에 대한 관심이 굉장히 높아서 그 비즈니스가 잘 되고 있고 자신이 기여하고 있다는 판단이 설 때 동기부여가 됩니다.
어떤 사람은 어떤 경우에도 동기부여가 되지 않습니다. 개발이라는 지금 하고 있는 업무 자체에 이미 큰 기대를 하지 않는 경우도 있고 회사에서 하는 일과 자신의 삶을 명확하게 분리해놓기도 합니다. 또 어떤 사람은 어떤 경우에도 동기부여가 됩니다. 이런 사람은 일을 주면 그 일을 해내기 위해 본인이 동기부여할 수 있는 계기를 스스로 만들어냅니다. 흔히 말하는 self-motivation이 되는 유형입니다.
따라서 사람마다 동기부여할 수 있는 포인트가 다르기 때문에 그 지점을 잘 찾아내어야 합니다. 1온1을 통해 직접적으로 물어볼 수도 있고, 그 사람이 하는 업무의 과정에서 파악할 수도 있습니다.
두 번째, 일단 그런 사람을 채용하고 회사에 남게 해야 합니다. 즉, 동기부여가 애초에 되지 않는 사람을 계속해서 힘들게 관리하기보다 동기부여 가능성이 높은 사람들이 조직에서 주요 역할을 할 수 있도록 힘을 실어줘야 합니다. 채용 전에는 이를 알아보기 어려울 수 있습니다. 하지만 3개월의 온보딩 과정을 통해 충분히 동기부여가 될 수 있는 사람인지를 파악할 수 있습니다.
이미 잘하고 있는 사람들에게 관심을 쏟지 않고, 못하고 있는 사람들에게 더 에너지를 쓰는 것은 회사 입장에서 효과적인 선택이 아닙니다. 잘하고 있는 사람들에게 더 관심을 주어야 하고 격려해주어야 합니다. 그들이 더 크게 성장해서 많은 기여를 할 수 있도록 도와줘야 합니다. 그렇다고 기대에 못 미치는 구성원에게 관심을 주지 않는다는 얘기는 아닙니다. 그들에게도 지속해서 기대하는 바를 얘기하는 시간을 할애하고 기대에 어울리는 업무를 주고 관리하는 것이 좋습니다.
세 번째, 조직적으로 동기부여가 되는 환경을 만들어야 합니다. 조직 문화라는 것에 일하는 방식이 포함된다고 생각합니다. 사람들은 자신의 주변의 행동에 대해 굉장히 크게 영향을 받고 전파됩니다. 이렇게까지 생각하고 행동하는구나라는 좋은 면이 전파될 수도 있는 반면에 이정도까지는 괜찮겠지라는 적정 하한선을 찾아보고 그렇게 따라하기도 합니다. 그렇기 때문에 동기부여된 사람이 만들어내는 아웃풋과 일하는 과정을 끊임없이 조직에 상기시키고 이렇게 일하는 것을 회사가 지지하는 것을 명확하게 알려주어야 합니다.
지금 있는 조직에서도 비즈니스 가치를 만들어내기 위해 많은 고민을 하고 방법들을 찾아 실행 중입니다. 가장 먼저 빠르게 원하는 개발 산출물이 나와주기를 기대하는 비개발조직의 기대사항과 올바르게, 제대로 개발을 하고 싶어하는 개발조직 사이의 갭을 메꾸기 위한 노력을 했습니다. 이를 위해 가장 중요한 것은 신뢰쌓기라고 생각합니다. 그 신뢰를 쌓기 위해서는 각 조직을 위한 행동을 실행해 결과를 만들고 오버커뮤니케이션을 통해 현재의 상호 갭 차이를 이해시키는 과정이 필요했습니다.
그리고 지속해서 개발조직이 할 수 있는 최고의 비즈니스 가치, 개발의 생산성을 높이기 위한 방안을 고민하고 있습니다. 결국 구성원들을 동기부여키시는 것이 다시 한번 중요하다는 것을 느낍니다. 지금 있는 조직은 과거 여러가지 문제로 인해 동기부여가 전반적으로 되고 있지 않은 상황입니다. 이 조직 전체에 열정을 넣고 동기부여시키는 과정에 있습니다.
한 때는 개발자들을 믿고 그들을 독려하는 것이 동기부여시키는 방법이고, 다그치고 푸쉬하면 동기부여가 떨어질 거라는 걱정을 많이 했습니다. 이제는 이것은 답이 아니라고 생각합니다. 상황에 따라 알맞은 방법을 취해야 합니다. 때로는 잘 설계된 ‘압박’이 오히려 사람을 더 움직입니다. 개개인과 상황에 맞는 동기부여 방법을 파악하고 독려하는 한편에 적절한 압박과 푸쉬도 밸런스 있게 해줄 필요가 있습니다. 다만 압박과 푸쉬의 기저에는 구성원이 성장하길 바라는 메시지가 반드시 포함되고 전달되어야 합니다.
현재 진행되는 일 중에 앱 페이지 하나를 추가로 만드는 태스크가 있었습니다. 기존에 만들어둔 모듈을 활용하는 업무라 시간이 많이 걸릴 거라 판단되지 않는 일이었습니다. 이 일에 대해 프론트엔드 주니어 개발자 2명이 최초 약 20일의 공수를 측정했습니다. 사유를 들어보니 기존에 있는 모듈을 활용하지 않고 새로 만드는 일정이었고 이는 기존 모듈을 활용하자는 최초의 취지와는 달랐습니다. 그 이유 또한 신규 추가되는 기능 하나 때문에 기존 모듈을 사용할 수 없는 문제였습니다.
먼저 기획단계에서 조율을 거쳐 다시 기존 모듈을 활용하는 방안으로 픽스했습니다. 그렇게 새로 나온 공수는 약 11일이었습니다. 파악해보니 백엔드에서 만들어주는 API를 기다리는 점, 애니메이션을 처음 만들어보는 과정에서 과도하게 측정된 공수들이 있었습니다. 이 분들에게 몇가지 기술과 협업 관점에서 조언을 해주었습니다. 그리고 무엇보다 스스로를 위해서 높은 도전 목표를 가지고 실행해보라고 해주었습니다. 물론 빠르게 개발하는 것이 전부가 아닌 개발코드의 퀄리티를 강조하는 것도 잊지 않습니다.
두분은 최종 공수로 7일을 얘기했고 그렇게 일은 시작되었습니다. 이들은 이틀을 앞당긴 5일만에 자체 QA까지 마무리지었습니다. 늘 하던대로 어느정도는 방어적인 일정을 얘기했으나 한번 해보자라는 의욕적인 마음이 두분에게 생겼던 것 같습니다.
이 사례는 곧 있을 위클리 얼라인미팅에서 두분에게 발표를 부탁할 예정입니다. 어떤 생각의 변화가 있었고 어떻게 일을 진행해서 높은 목표를 달성할 수 있었는지에 대해 공유하는 자리가 될 것 같습니다. 그리고 이러한 시도 역시 조직 전체가 높은 목표를 향해 동기부여되는 기회가 될 거라고 생각합니다.