전직 미국 대통령으로부터 배우는 Leadership Principles
2017년부터 소프트웨어 엔지니어로 일을 시작했으니, 벌써 만 7년 이상을 개발자로 밥 벌어 먹고살고 있는 시니어 엔지니어라고 할 수 있겠다. 마음만은 여전히 주니어 엔지니어지만 짧지 않은 시간 동안 일에 대한 요령도 많이 늘었고 체력적으로도 20대와는 달라졌으며 가장 중요한 것은 고용주인 회사가 나에게 기대하는 능력치는 이제 더 이상 하드 스킬, 즉 개발 업무에만 국한되지 않는다는 것이다. 경력이 더해지면서 회사는 피플 매니징이라는 또 다른 업무 능력치를 기대하고 있고, 다행히도 작년부터 조금씩 Entry/Junior 엔지니어에 대해서 피플 매니징을 할 수 있는 기회가 생겼다. 그리고 새로운 회계 연도가 시작되는 11월부터는 공식적으로 작은 규모의 팀을 리딩하고 매니징하는 역할이 부여될 것이라는 얘기를 조직장에게 전달받았기 때문에 늦게라도 부랴부랴 여러 가지 피플 매니징, 소프트 스킬에 관련된 책들과 기사를 찾아보기 시작했다.
요즘은 한국 회사에서도 IC (Individual Contributor)와 Manager 트랙을 분리해서 운영하는 곳이 늘어나고 있고, 실제로 IC로 좋은 성과를 냈던 엔지니어들이 매니저 역할을 맡으면서 잘 맞지 않은 옷을 입은 것처럼 힘들어하는 얘기는 심심찮게 들을 수 있다. 아마도 그런 경우 때문에 여러 선배 엔지니어가 자신의 경험을 공유하는 책들이 있으며, 성윤 님이 작성하신 리스트가 꽤 괜찮은 시작점이라고 생각된다. 아마도 실리콘밸리의 팀장들이나 Leading Effective Engineering Teams와 같은 책들은 실제 Engineering Manager 또는 Tech Lead Manager들이 제안하는 내용들이기 때문에 일종의 쿡북처럼 빠르게 우리 팀 상황에 맞는 여러 가지 팁들을 시도해 보고 활용해 볼 수 있을 것이다.
그러면 큰 고민 없이 개발 도메인에서 나온 리더십 책들을 보면 될 것이지, 왜 이렇게 사설이 기냐는 생각이 들 수 있다. 틀린 말은 아니지만 좋은 매니저가 되려면 결국 좋은 사람이 돼야 한다는 것이 일차적인 내 생각이다. 그래서 개발 도메인이 아니더라도 델 카네기의 인간 관계론이나 소프트 스킬과 같은 범용적인 리더십 책 역시 많이 찾아보고 읽어보려고 노력하고 있다. 운이 좋게도 이런 고민에 대해서 멘토에게 얘기할 기회가 있었고, 개발 도메인에 국한되지 않으면서 여러 가지로 생각해 볼 수 있는 리더십 도서를 선물 받아 열심히 읽고 서평을 남겨보려고 한다. 선물 받은 책은 <혼돈의 시대 리더의 탄생>이며 4명의 전직 미국 대통령 (에이브러햄 링컨, 시어도어 루스벨트, 프랭클린 루스벨트 그리고 린든 존슨)이 어떤 과정과 고난을 겪으면서 지도자가 될 수 있었는지에 대한 책이다. 레퍼런스 내용을 제외하면 600p 상당의 꽤 두꺼운 책이었지만, 소설 읽듯이 몰입하며 재밌게 읽을 수 있었다. 책에서 얘기하는 내용 중 엔지니어링 매니저에게도 적용할 수 있는 여러 가지 인상 깊은 내용들이나 개발 조직을 관리할 때 비슷한 상황이 생긴다면 어떻게 해볼 수 있을까에 대한 내용을 아래에서 정리해 보려고 한다.
어떤 열쇠도 완전히 똑같지 않다. 홈이 파인 모양은 제각각이다. 리더십의 만능열쇠도 없고, 역사적 상황을 포괄하는 자물쇠도 없다.
책을 관통하는 메시지이자 4명의 전직 대통령 사례를 가져온 이유가 아닐지 생각이 든다. 4명의 리더는 서로 다른 성장 환경, 좌절과 극복 과정을 거쳐 백악관에 입성하는데, 아마 해당 문장에 대한 저자의 원래 의도는 서로 다른 리더십에 대해서 말하고 싶었던 것이 아닐까 싶다. 반대로 한 명의 리더이자 엔지니어링 매니저로서 구성원들과 신뢰 자본을 쌓는 것 역시 다른 의미로 서로 다른 모양의 자물쇠 맞추기라고 생각된다. 가령 어떤 구성원은 피드백을 전달할 때 돌려 말하기보다는 직설적으로 말해주길 바라지만, 누군가는 충격에 대비해 앞뒤 쿠션어를 붙여주길 원할 수 있다. 또 다른 예시로는 온전히 권한을 위임해서 본인에게 업무를 맡겨주길 바라는 경우와 필요에 따라 마이크로 매니징을 통해 로드 블록을 치워주길 바라는 경우가 있을 수 있겠다. 다시 말해서 각 구성원에 대해서도 리더십은 만능열쇠가 없으며, 심지어 같은 구성원에 대해서도 업무에 따라 유연성을 가질 필요가 있다는 생각이 든다.
지금은 대담하고 끈질긴 실험이 필요하고 또 요구됩니다. 어떤 방법이든 취해서 시도해봐야 합니다. 그 방법이 실패하면 솔직히 인정하고 다른 방법을 시도해봐야 합니다. 그것이 상식입니다. 여하튼 무엇이든 시도해봅시다.
한 단락 안에 너무나 좋은 내용이 많이 들어있어 가져왔다. 우리는 엔지니어로서 제일 나은 선택을 위해 끈질긴 실험이 필요하며, 완벽하진 않더라도 주어진 시간 내에 일이 되는 방향으로 업무를 수행해야 한다. 단순히 시간을 태우는 것이 아니라 가설을 세우고 근거를 찾아서 논리적으로 얘기할 수 있는 실험이라면 더할 나위 없겠다. 많은 주니어 엔지니어가 자주 겪는 함정 중 하나는 완벽한 코드 또는 솔루션을 가져오려는 점인데, 처음부터 완벽한 답안을 가져오면 좋겠지만 그게 힘들다면 차선책이나 최소한 실행 가능한 형태의 코드를 가져오는 것이 중요하다고 생각한다. 최소한의 실행 가능한 코드는 책에서 얘기하는 실패한 방법이라고 생각하지 않지만, 우리는 회고를 통해서 그것을 더 나은 방향으로 언제든지 개선할 수 있는 소프트웨어 엔지니어이기 때문이다. 단 이때, 피드백과 회고는 감정을 배제하고 사실을 기반으로 담백하게 할 것. 여하튼 무엇이든 시도해 보는 것이 중요하다, 시도가 있어야 실패가 있고 개선이 있을 수 있기 때문에 :)
다른 사람들이 황금처럼 순수하지 않더라도 그들과 협력하는 게 반드시 필요하다는 것, 또 원하는 걸 모두 얻을 수 없다면 취할 수 있는 것 만이라도 취해야 한다는 것
작은 단위의 개발 조직이라면 서로 다른 엔지니어들끼리, 조금 규모가 있다면 그에 더해서 기획자 그리고 큰 규모의 조직에서는 엔지니어, 기획자, 데이터 분석가와 같이 서로 다른 이해관계를 가진 인원과 협업하게 된다. 기본적으로 모든 사람은 개인의 이익을 우선시할 수밖에 없다고 생각하며 그로 인해 오해와 갈등이 쌓이면서 불화가 생기는 경우를 직간접적으로 많이 볼 수 있었다. 현대 소프트웨어 개발은 아주 예외적인 경우를 제외하면 더 이상 혼자서는 할 수 없는 업무이기 때문에 우리는 반드시 협력이 필요하며 그에 맞는 능력치도 필요하다면 개발해야 한다. 조금 더 직설적으로 얘기하면 각 구성원을 수단으로 보지 말고, 기저에 나쁜 감정을 배제하여 진심으로 대하면 상대방도 반드시 그 진심을 알아주는 날이 올 것이라는 게 내 생각이다. 이번에 내가 원하는 만큼을 얻지 못하더라도 신뢰 자본이 쌓인 상대방은 나중에라도 반드시 그것의 두 배 이상 보상해 줄 수 있다고 생각하면 마음이 좀 편하지 않을까?
요약
비록 정치 지도자로서의 리더십을 다룬 책이었지만, 개발 업계 용어로 비유하자면 결국 도메인만 다를 뿐 엔지니어링 매니저에게도 똑같이 적용할 수 있는 금과옥조와 같은 내용들이 많은 책이었다. 링컨과 프랭클린 루스벨트를 제외하고는 (심지어 이 두 전직 대통령도 아주 잘 아는 것은 아니지만) 잘 모르는 사람들이었지만, 책을 다 읽고 나서는 네 명의 대통령 각각에 대해서도 조금 더 자세히 알고 싶어질 정도였다. 나처럼 피플 매니징이나 리더십에 대해서 고민이 많은 리더라면 적극 읽어보길 추천하며, 학생이나 사회 초년생이라도 충분히 얻어갈 내용이 많을 것이라고 확신한다.