책 "팀장의 탄생"을 읽고...

나도 어느덧 개발자의 길을 들어선지 8년 정도가 지났다. 나는 어떻게 하면 시니어다운 개발자가 될 수 있을지 계속 질문을 하고 있다. 나는 풍부한 개발 지식과 경험을 통해서 리더쉽을 발휘할 수 있는 시니어가 되고 싶다. 그렇게 되기 위해서 개발자 커리어 동안 항상 배움에 목말라 했고 성장에 집착했었다. 나의 개발자 커리어에서 잠깐동안 5명 정도 되는 팀을 이끄는 팀장 역할을 하기도 했지만, 나머지 기간은 팀원의 역할로 다양한 업무를 맡았다. 이렇게 나는 어떠한 조직을 이끄는 매니저 역할을 고민하기보다는, 팀원으로 회사에 어떻게 기여하고 성과를 낼 수 있는지 고민하는 시간을 주로 가졌다. 따라서 "팀장의 탄생" 책을 읽으면서 과거 나의 팀을 이끌던 팀장분들을 떠올려보았고, 앞으로 내가 팀장 같은 역할을 가지면 기억해야할 점을 남겨보았다.

나는 탁월한 관리자가 될 만한 사람일까

책의 첫번 째 장에서는 "나는 탁월한 관리자가 될 만한 사람일까"라는 질문이 등장한다. 저자는 내가 탁월한 관리자가 될 재목인지 판단하는 기준으로 아래의 세 가지 질문을 답해보라고 한다.

실무를 할 때보다 성과 달성에 더 매력을 느끼는가?
대화를 즐기는가?
감정적으로 힘든 상황에서 안정감 있게 처신할 수 있는가?

나는 아직도 다양한 기술에 대해서 호기심이 가득하고, 밑바닥에서 이것들이 어떻게 동작하는지 궁금하다. 그래서 OS나 Linux Kernel에 대해서도 계속해서 호기심이 있고, Compiler 같은 것도 관심이 있다. 실제로 Coursera, Edx 같은 곳에서 관련 강의들을 취미로 들어보곤 했다. 최근에 바람 쐴겸 서점에 가서 책들을 구경하다가, '밑바닥부터 만드는 컴파일러 in GO' 책을 보고 구매 충동을 느꼈다. 하지만 현재는 다른 것에 집중해야 될 시기라 생각하고, 나의 책 목록에만 추가해놨다. 이런 나의 성향을 봤을 때는 실제로 실무를 하면서 거기에서 변화를 만들어내고, 결과물을 내는 것에 더 매력을 느끼는 것 같다. 그래서 첫번째 질문에 대해서는 '아니오'라고 대답할 수 있다.

나는 사람들과 토론하고 의견을 나누는 것을 좋아한다. 같은 책들을 읽고 다른 사람들이 어떤 생각을 가지는지 듣는 것도 좋아한다. 그래서 다양한 독서 모임에 참가하기도 했고, 현재도 회사 내에 존재하는 독서모임에서 활동 중이다. 그래서 두번째 질문에 대해서는 '예'라고 대답할 수 있다.

마지막 질문에도 '예'라고 답할 수 있다. 과거에는 감정 기복이 좀 있는 편이었다. 하지만 지금은 나의 감정들을 다룰 수 있는 능력이 있다. 당연히 어떤 날은 조금 의욕이 떨어지는 날도 있지만, 다시 그런 마음들을 다잡고 다시 또 열심히 할 것들을 하는 힘이 있다.

세 가지 질문을 답하면서 내가 관리자 역할을 맡으면 잘 할 수 있을지 고민을 했다. 현재 나는 실무를 통해서 성장하고 싶은 욕구가 강하지만, 조직의 비전과 미션이 내가 추구하는 가치관과 일치할 때는 관리자 역할을 해도 만족할 것 같다. 조직 문화, 프로세스에도 관심이 많고, 이러한 것들을 개선하는 것을 고민하는 것에도 흥미를 가진다. 따라서 관리자 역할을 맡게 되더라도 그안에서 또 다른 매력들을 찾을 것 같다. 그렇기 때문에 "팀장의 탄생"도 흥미롭게 읽지 않았을까? 자질에 대해서는 모르겠지만, 적어도 관리자 역할에서도 다양한 흥미를 느끼고 그안에서 내가 발전할 수 있는 방법들을 찾으며 능동적으로 일을 할 것이다.

리더의 자격은 스스로 획득해야 한다.

저자는 관리자와 리더의 차이점을 아래와 같이 설명한다.

관리자의 자격은 조직이 누군가에게 부여할 수 있지만 리더의 자격은 그렇지 않다. 리더의 자격은 스스로 획득해야 한다.

나는 회사에서 관리자라는 직책을 정식적으로 부여 받은 적은 없지만, 다양한 상황에서 리더의 역할을 하고 있었다. 회사에서 팀원으로서도 리더쉽을 발휘해서 다른 팀원들을 설득하고 변화를 가져와야 하는 경우들이 많았다. 팀장이라는 역할이 아니더라도 리더쉽을 발휘해야 하는 상황들은 많다. 이러한 관점에서 나는 충분한 리더쉽들을 발휘하고 있었을까? 업무 프로세스 개선을 위해서 다른 팀원들을 설득해야 하는 과정도 리더쉽을 발휘할 수 있는 기회이다. 먼저 이러한 작은 상황에서 리더쉽을 발휘할 수 있도록 고민하고 학습해야겠다.

사람의 재능을 성과로 직결시키는 능력

대학교에서는 늦게 복학해서 팀 프로젝트를 하면 항상 팀장이 되었다. 팀 프로젝트에서 나는 더 많은 시간을 들여 자료를 조사하거나, 대표로 보고서를 작성하거나 아니면 프리젠테이션 발표를 하는 등 팀원들보다 더 많은 역할을 맡아서 했다. 참여도가 저조한 팀원들을 대신해서 그 업무들을 맡아서 하는 경우도 많았다. 자료를 조사해서 보고서를 제출하거나 발표하는 팀 프로젝트 경우에는 좋은 점수를 받았다. 하지만 팀원들의 역할을 잘 분배해서 정해진 시간안에서 다른 팀들과 경쟁해야 되는 프로젝트에서는 좋은 결과를 내지 못하는 경우가 많았다. 책에서 아래의 내용을 읽을 때, 사람의 재능을 파악하고 그것을 활용해서 성과를 내는 것에는 부족했었던 것 같다는 생각을 했다. 팀원들이 잘할 수 있는 것들을 파악하고, 그들에게 위임하여 정해진 시간안에 성과를 낼 수 있는 것을 더 많이 고민했어야 했었다.

저명한 경영 컨설턴트로서 수많은 조직과 리더를 연구한 버킹업은 "탁원할 관리자들에게만 있는 능력이 하나 있다. 각 사람의 특장점을 파악하고 활용하는 능력이다. 관리자의 임무는 각 사람의 재능을 성과로 직결시키는 것이다."라고 말했다.

피드백

최상의 피드백은 받는 사람에게 뿌듯한 변화를 일으킨다.

난 아직도 주니어 개발자로 바둥바둥 열심히 일하던 시절에 받은 Peer Review 문서를 가지고 있다. 내가 잘하는 점들도 많이 적혀 있었고, 고맙게도 내가 발전하고 싶은 점을 정확하게 짚어주는 피드백도 있었다.

If given enough time, is able to understand the technology. But seems a little slow in doing so.

그 당시에 다양한 오픈소스 툴들을 사용하여 빠르게 프로토타입을 만들거나 문제를 해결하는 동료가 있었다. 나는 해당 기술에 대해서 더 깊이 이해하고 사용하고 싶은 경향이 있었는데, 그래서 실질적으로 그것들을 도입하여 문제를 해결하는 시간이 상대적으로 오래 걸렸다. 그래서 그 동료를 롤 모델로 삼아서 핵심만 이해하고 빠르게 적용할 수 있는 능력도 같이 기르고자 노력했다. 사용하는 기술에 대해서 깊이 이해하면 운영하는 과정에서 발생하는 이슈에 대해서 빠르게 대처할 수 있다. 따라서 현재 문제를 해결할 수 있는지 빠르게 파악하고, 도입된 기술에 대해서 깊이 이해하는 방식으로 진행했다.

그리고 그 당시에는 나에게 많은 요청과 업무가 몰리는 것이 뿌듯했다. 내가 그만큼 중요한 역할을 한다는 생각이 들었고, 그러한 요청들을 처리해주면서 뿌듯함을 느꼈다. 2주동안 출장 및 휴가를 가는 동안 엔지니어 팀장님이 나의 업무를 대신 맡아서 진행했다. 내가 휴가에서 돌아 왔을 때, 뼈를 때리는 피드백을 주었다. 생각보다 자동화가 되어 있지 않았다는 피드백이었는데, 나에게 오는 많은 요청중에 자동화할 수 있는 점들을 다시 고민했다. 내가 일을 잘하고 있는지 판단하는 기준이 얼마나 바쁘게 일하느냐가 아니라, 얼마나 효율적으로 일하고 있느냐가 되었어야 했다.

이러한 피드백은 내가 성장하는데 좋은 밑거름이 되었다. 아직도 이때의 피드백을 잊지 않을려고 노력한다. 물론 가시적인 변화도 있었다. 필요한 시스템 구성을 빠르게 한다는 피드백을 동료로부터 받은 것이다.

매니저가 되면 구성원들에게 도움이 될 수 있는 피드백을 수시로 줄 수 있는 사람이 되어야겠다. 잘하는 점에 대한 피드백을 통해서 구성원이 어떤 것을 잘하는지 파악할 수 있도록 하자. 그리고 개선이 필요한 점은 피드백을 통해서 구성원이 성장할 수 있도록 도우자. 개선을 위한 피드백이 대상자에게 비난으로 느껴지지 않도록 조심하고, 대상자와 충분한 신뢰 관계를 만들어서 그러한 피드백이 진정으로 대상자의 발전을 위함인 것을 알도록 하자.

비전, 미션, 목표

책에서 성과를 내는 팀을 만들기 위해서 팀원들이 공통된 목표를 가지는 것이 중요하다고 말한다. 대부분 알고 있는 내용이면서 실제로 적용하는게 어려운 문제이다. OKR도 결국은 비전과 미션 아래에서 구체적인 목표를 정하고, 구성원들이 공통된 목표를 바라볼 수 있도록 하는 것이다. 팀원들은 구체적인 공통된 목표를 바탕으로 어떤 업무들을 우선순위로 정할지 의사결정을 할 수 있다. 그리고 이러한 의사결정을 할 수 있는 기준이 있기 때문에, 권한을 위임할 수 있을 것이다. 또한 구체적인 목표가 있기 때문에 얼마나 목표에 다가가고 있는지 상시적으로 평가할 수 있을 것이다.

그리고 Domain Driven Design에서는 Core Domain이 무엇인지 고민하는 부분이 있다. 우리 제품의 차별성이 Core Domain에서 나오고, 그 이외 Sub Domain들은 SaaS와 같이 이미 그 Domain에 대해서 문제를 해결하고 있는 솔루션을 사용하거나, 외주로 맡기는 것들을 고민해볼 수 있다. 우리의 강점이 무엇인지 인지하고 Core Domain에 집중하는 것이다.

하지만 실제로 업무를 하면서 비전과 미션을 바탕으로 구체적인 목표가 세워지고, 그것을 바탕으로 팀원들에게 충분히 설명하고 공감을 만들어내는 과정이 생략되는 경우가 많은 것 같다. 내가 매니저가 된다면 구체적인 목표을 팀원들이 공감할 수 있도록 충분히 설명하는 시간을 가지자. 나 스스로부터 어떠한 것이 우리의 조직에서 중요한 과제인지 인지하고 있어야 하고, 그걸 바탕으로 우리의 팀이 어떻게 기여할 수 있는지 알아야 공감 가는 구체적인 목표를 제시할 수 있을 것이다.

책에서 아래와 같은 예시가 나온다. 매니저가 된다면 우리의 팀이 좋은 예처럼 할 수 있도록 고민하자.

나쁜 예

A: "그쪽 팀은 X, Y, Z를 하세요"
B: "네"

좋은 예

A: "지금 A, B, C가 문제에요"
B: "그럼 우리 팀은 X, Y, Z를 할게요"

평가 / 피드백

이 책을 읽고 난 후, 나와 팀이 성장할 수 있도록 어떻게 피드백을 자주 교환할 수 있을지 고민하였다. 그런데 이때 평가보다 피드백 저자의 강연이 광고로 나오게 되었고, 궁금해서 책 평가보다 피드백을 빠르게 읽어 보았다. 이 책에서는 평가는 결과물에 대한 판단이고, 피드백은 과정에서 그 사람에게 어떤 변화가 있었는지 판단하는 것으로 두 개를 구분해야 한다고 말한다. 그리고 평가는 짧게 하고, 피드백은 자주하라고 조언한다. 피드백은 불편한 과정이지만, 나와 조직이 성장하는데 중요한 요소이다.