저는 개발자들의 응석을 다 받아줘야 한다고 생각하지 않습니다. 개발자든, 최고 경영 책임자든 누군가에게 특권을 부여하는 문화에 동조하지도 않습니다. 우리 모두는 현실을 살아가는 성인이고 전문가입니다. 직책에 관계없이 서로를 동등한 성인으로 대해야 합니다. 컴퓨터 프로그래머부터 금융 분석가, 영업 담당자에 이르는 모두가 회사에 고유한 가치를 제공하고 있습니다.
저 같은 경영자는 모든 팀원들이 보유하고 있는 중요한 역량들을 이해하고, 인정하고, 후원하려고 노력해야 합니다.
개발자부터 시작해보겠습니다. 제가 가장 아끼는 구성원 중 하나죠. 디지털 시대로 접어들면서 귀에 못이 박히게 듣고 있는 말이 있습니다. “모든 회사가 소프트웨어 회사로 변모하고 있다"는 말입니다. 디지털 분야, 특히 애플리케이션 개발에서의 혁신이 새로운 비즈니스 창출 및 경쟁 우위에 중요한 역할을 한다는 것을 강조하기 위한 표현이라 하겠습니다. 새로운 애플리케이션을 신속하게 배포하고 다양한 혁신 기술을 함께 제공할 수 있는 능력이 비즈니스 성공의 직접적인 동인으로 자리 잡았습니다.
애플리케이션이 새로운 경제의 통화라면 개발 팀은 시장 조성자입니다. 하지만 제 경험에 따르면 디지털 경제에서 속도와 혁신을 부단히 그리고 전략적으로 강조하고 있음에도 불구하고, 개발 팀은 오해를 받고 제대로 관리되지 않아 방치되기 일쑤입니다. 이러한 현상은 기업의 규모와는 관계가 없습니다.
뭔가 앞뒤가 맞지 않습니다. 게다가 엄청난 비용이 발생하고 있습니다. 저는 이것을 혁신하는 회사가 대가로 치르는 세금이라고 생각합니다. 개발자가 수행하는 업무의 속성을 이해하지 못하거나 개발자에게 안전하고 생산적인 환경을 제공하지 못하는 기업은 이 세금을 치르게 됩니다. 그리고 이 문제를 제대로 해결하지 못하면 장기적으로 시장에서 살아남을 수 없습니다.
요즘에는 프로덕션 코드를 작성하고 있지 않지만, 그럼에도 불구하고 저는 여전히 개발자입니다. MongoDB는 수십 개 팀에 소속된 수백 명의 개발자들을 이끌고 있기 때문에 저는 항상 개발자 문제에 부딪히게 됩니다. 개발자를 위해 생산적인 문화를 조성하려면 해야 할 일과 하지 말아야 할 일이 몇 가지 있습니다. 이 업계에서 경력을 쌓으면서 터득한 것이죠. 물론 앞으로도 계속해서 논의가 필요한 문제겠지만, 일단 소개해보겠습니다. 현재 지불하고 있는 "혁신세"를 줄이고 싶다면 꼭 생각해 봐야 할 몇 가지가 있습니다.
- 개발자에게 비즈니스 맥락을 제공하라
개발자의 지능이나 성숙도를 우습게 보지 마십시오. 개발자는 자신이 일하는 이유와 근거를 이해할 수 있고 또 이해해야 합니다. 실제로 개발자가 전략적 목표를 그려놓으면 소프트웨어의 아키텍처 및 설계 경험과 조율해 중요한 의사 결정을 내리게 되면서 더 나은 결과물이 나옵니다. 비즈니스 맥락을 이해하는 개발자는 최고 책임자, 심지어 저 같은 CTO 보다 훨씬 현명하게 상향식 관점에서 성과를 내는 방법을 찾을 수 있습니다.
- '기술 부채'를 인정하고 원금을 갚아라
제 경험으로 볼 때, 개발자들의 사기를 떨어뜨리는 가장 큰 원인은 과도한 기술 부채와 이를 해결하려는 경영진의 의지 부족입니다. 탈출구를 마련하기 위해 약간의 부채를 지는 것도 나쁘지는 않습니다. 부채라는 것을 알고 나중에 원금을 갚기만 한다면 말입니다. 그러나 개발자들은 리더가 기술 부채 증가에 관심을 기울이지 않고 있다는 사실을 본능적으로 눈치 챕니다. 기술 부채 증가에 관심을 기울이지 않는 리더들은 프로젝트 일정에만 집착하고 엔지니어링 정신을 잃어가기 때문입니다. 그러면 개발자들은 인지 부조화에 빠지게 됩니다. 상황은 재앙에 가까운데도 개발자에게 차기 혁신을 내놓으라고 요구하는 리더는 신뢰를 잃게 되고, 개발자들은 인내심을 잃게 됩니다. 회사는 혁신 속도가 지체되면서 비용 손실을 입게 됩니다.
- 개발자가 실제로 어떤 일을 하는지 파악하라
여기에 대해서는 며칠이고 얘기할 수 있을 정도로 할 말이 많지만, 결론은 이렇습니다. 개발자가 업무 시간을 어떻게 쓰고 있는지 이해하지 못하는 리더는 팀을 이끌 자격이 없습니다. 새로운 기능에 초점을 맞추기는 쉽습니다. 하지만 리더라면 개발에 관련된 부수적인 작업(데이터베이스나 레거시 스테이징 환경의 유지관리 등)이 지루하고 고된 단순 반복작업이라는 점을 인정하고 문제를 해결하기 위해 애써야 합니다. 그러지 않으면 혁신 가치도 제공하지 않으면서 개발자의 시간만 많이 잡아먹게 되어 개발자의 사기만 떨어지고 말 것입니다. 개발과 관련된 부수적인 시스템을 쇄신해야 한다는 개발자의 목소리에 귀를 기울여 그 중요성을 이해해야 합니다.
- OKR과 허영 지표를 제거하라
하향식 혁신이라는 말에는 모순이 있습니다. 개발자가 원하는 것은 오직 자신이 개발한 기술을 실현하는 것이라는 사실을 믿어야 합니다. 목표, 주요 성과 또는 기타 KPI를 통해 개발자를 압박할수록 개발자는 스스로 혁신의 범위를 제한하게 됩니다. 목표를 설정했다면, 개입하지 말고 빠져줘야 합니다.
- 목표를 조정하라
이는 비즈니스 맥락을 제공하라는 말과 같습니다. 리더와 개발자는 같은 목표를 달성하기 위해 협력하고 있다는 사실을 믿어야 합니다. 대립 관계가 되면 개발자의 업무에 차질이 생기고, 리더는 단 한 번의 마찰로 인해 하루라는 귀중한 시간을 낭비하게 됩니다. 다시 말하지만, 응석을 받아주라는 말이 아닙니다. 개발자는 다른 모든 직원들과 마찬가지로 회사의 성공을 위해 맡은 바 역할을 수행해야 합니다. 제 말은 비즈니스 목표와 기술 목표, 조직 목표를 조율해서 개발자들과 솔직하면서도 투명한 관계를 구축해야 한다는 것입니다.
앞서 말했듯이 이 주제에 대해서는 며칠이고 말할 수 있을 정도로 할 말이 많습니다. 개발자에 대한 관리 미흡은 혁신세의 한 형태라는 것을 기억하시기 바랍니다. 앞으로 몇 달에 걸쳐 여기에 숨겨진 다른 세금은 없는지 살펴볼 것입니다. 지금까지 초보 리더들이 해야 할 일과 하지 말아야 할 일에 대해 알아봤습니다. 이에 대한 논의가 앞으로도 계속되었으면 합니다. 덧붙이고 싶거나 빼야 한다고 생각하는 내용이 있으시면 언제든 자유롭게 Twitter(@MarkLovesTech)에 올려주시기 바랍니다.