인상 깊은 문장들
알파 긱(Alpha Geek)에 대하여
알파 긱 성향은 대개 개발자가 처음 멘토 역할을 맡을 때 쯤에 드러나기 시작한다. 만약 기술적인 부분이 뛰어난 데도 사람이 다가와서 도움을 부탁하지 않는다면, 자신에게 알파 긱 성향이 없는지 스스로 물어보자. 자기 생각을 정확하게 말하고 어떤 것도 요청하지 않은가? 다른 사람의 좋은 아이디어나 좋은 코드를 인정하는 일이 못마땅하고 다른 사람의 실수를 열심히 찾지는 않는가? 정확함이 가장 중요하고 옳은 것이라 믿으며, 그 믿음을 위해 언제든 싸울 수 있는가? 그렇다면 자신에게 알파 긱 성향이 있다고 여기자.
자신이 알파 긱일 수도 있다는 생각이 들면, 멘토링은 이런 성향을 바꿀 좋을 기회가 된다. 스스로 멘티를 가르치고 이끌어야 할 사람으로 생각하고 멘티에게 가장 잘 맞는 방법으로 일하도록 돕는게 목표라면, 알파 긱 성향이 멘티의 성장을 더 어렵게 한다는 것을 직접 경험하게 될 것이다. 만약 멘티를 위해 자신의 스타일을 바꿀 생각이 없다면 멘토에 자원하지 말자. 알파 긱이 팀에서 가장 똑똑하고 기술적으로 뛰어난 사람이라는 정체성을 유지하는 한, 형편 없는 매니저가 될 가능성이 높다.
공대생이라면 흔히 은둔형 천재처럼 보이는 사람들, 외골수 성향과 함께 타협하지 않고 기술적으로 매우 똑똑한 사람을 동경하는 경향이 있다. 학계에 평생 몸담을 사람이라면 이같은 유형이 최적일지도 모르겠으나, 결코 같이 일하고 싶거나 매니저로 두고 싶은 사람은 아닐 수 있다. 대화가 전혀 통하지 않는 천재 개발자보다, 커뮤니케이션이 원활한 준수한 개발자가 프로젝트 성공 관점에서는 더 필요한 사람이라는 것을 알아야 한다.
상대방의 언어를 듣고 말하기
좋은 멘토링을 경험하고 나면 팀 리더에게 필요한 기술이 만들어지기 시작한다. 매니저가 될 생각이 없어도 멘토링 경험은 소통 기술을 익히는 데 도움이 된다. 멘토링은 경청을 연습할 좋은 기회다. 질문을 잘 듣지 않으면 좋은 대답을 할 수 없다.
이따금 시니어 개발자에게 나쁜 습관이 스며있기도 하다. 최악의 습관은 잘 이해되지 않거나, 자신의 의견에 동의하지 않는 사람과 논쟁하려는 경향이다. 신입 사원, 주니어 팀원과 업무를 잘 수행하려면, 몇 번이나 시간을 들여 노력을 쏟더라도 그들이 이해하는 방식으로 경청하고 소통해야 한다. 대부분의 회사에서 소프트웨어 개발은 팀으로 하는 스포츠 경기 같으며, 팀이 어떤 일을 하는데에는 효과적인 의사소통이 필요하다.
상대방이 논리적으로 틀린 이야기를 하더라도 일단 잘 듣고 이해하기. 요즘 유행하는 MBTI론에 따르면 T성향이 강한 사람은 의견이 다른 사람과의 논쟁을 즐기고, 상대방이 말하는 의도에 관계 없이 합리적인 논리를 맞추는데 집중하기 마련이다. 엔지니어들은 대개 T가 많다. 하지만 팀 경기에서 때때로 논리적으로 맞는 정답을 찾기보다 팀원을 이해하고 경청하는 것이 더 중요하기도 하다. 프로젝트를 함께 할 때 가장 중요한 것은 누구의 말이 더 맞는 말인가를 따지기 보다, 주어진 시간내에 목표로 한 성과를 달성하는 일이다.
과로와 위임
테크리드는 새 기능을 개발하기 위해 과로하기 십상인데, 이는 때로 팀이 실패하는 원인이 되곤 한다. 출시 일자가 임박한 큰 프로젝트라면 제품 기능을 절충하기 마련이다. 직접 빌드하고 싶은데 시간이 없다면 그 일을 다른 사람에게 위임할 줄도 알아야 한다.
위임에 대해서 많은 고민을 했다. 위임이라는 건 어떻게 보면 책임전가, 포기, 방임, 또는 목표 달성에 실패 했을 때 Blame을 하기 위한 도구가 되는 것은 아닐까 하는 생각을 했다. 하지만 조직을 관리하는 입장에서 위임은 필수불가결하다. 아무리 뛰어난 슈퍼맨이라 하더라도 모든 일을 관리할 수 없기 때문이다. 그렇기에 믿고 맡길 수 있는 사람을 알아보고 위임하는 것까지 조직을 관리하는 매니저가 갖춰야할 덕목이다.
긍정적으로 생각하기
처음 리드를 맡으면 바쁠 수밖에 없습니다. 그래도 축하합니다. 매니저가 당신에게 승자의 돌을 준 것이기 때문입니다. 다행히도 이런 부담감을 잘 짊어지고 나가면 결국 더 강해지고 더 나은 경력에 필요한 기술을 익힐 수 있습니다. 지금처럼 부담스럽지 않을 때가 언젠간 올 것입니다.
부담스럽더라도 나 자신 화이팅.
질문하고 설명하기
최근 회사의 시니어 비즈니스 매니저 한 분이 내게 아키텍처 질문을 했다. 그는 여기에 자금을 지원해야 한다는 것은 알았지만 그것이 왜 필요한지는 이해하지 못했다. 아마 부끄러움이 앞서 공개 석상에서는 질문하지 못했던 거 같다. 나는 요즘 시니어와 주니어 팀원에게 기초적인 개념과 동기를 설명하는 자리를 만드는 것을 주저하지 않는다. 왜냐하면 이런 자리는 팀원의 생각을 넓혀주고 팀원들이 내 판단과 충고를 신뢰하게 만들기 때문이다. 무엇보다 이런 경험이 노력이 결국 우리에게 좋은 변화를 가져온다. 시간을 들여 설명하는 건 매우 중요하다.
질문을 주저하지 말고, 부끄러워하지 말아야 함. 더불어 팀원이 모르는 것에 대해서 설명해주는 시간을 아까워하지 말아야 한다. 팀원이 내 고민의 깊이에 대해서 공감하는 만큼 신뢰는 깊어지고 팀의 시너지를 높인다.
도구 만능론을 맹신하지 말자
‘업무를 위한 적절한 도구’가 있다고 믿는 개발자가 테크리드가 되면 그들은 계획, 집중, 시간 관리, 우선순위 설정 등 모든 이슈를 해결할 도구를 찾는 과정에서 프로세스 독재자로 변해간다. 완벽한 프로세스를 찾는 동안 모든 업무를 중단시키고, 사람 사이의 상호작용 같은 복잡한 문제에 관한 해결책으로 새로운 도구와 프로세스를 계속 제시한다.
프로세스 독재자의 반대는 프로세스를 완전히 포기한 매니저가 아니라 프로세스가 팀과 업무의 요구 조건을 충족해야 한다는 것을 이해한 사람이다. 신임 테크리드라면 팀의 의사소통이나 리더십 차이로 인한 문제를 해결해야 할 때 프로세스에만 의존하는 것은 주의해야 한다. 프로세스 변경이 도움이 될 때도 많지만, 결코 만능은 아니다.
도구는 그저 도구일 뿐이다. 팀의 스타일, 프로젝트의 속성에 따라 알맞은 도구를 선택하고 도입하는 것도 매니저의 역량이다. 리더십 부재를 도구로 해결하려고 접근해서는 안 된다.
생산성 있는 거절
매니저가 상사에게 “아니요”라고 거절하는 건 단순히 “아니요”라고 하는 것과 다르다. “네. 그 프로젝트를 할 수 있어요. 현재 로드맵에 있는 다른 프로젝트들의 시작만 늦추면 돼요.” 현실적으로 안 되는 부분을 명확히 이야기하면서도 긍정적인 대답을 할 수 있다는 건 당신이 고위 리더십을 시작할 수 있다는 의미이다.
이런 ‘긍정적인 거절’은 개발자 대부분이 마스터하기 아주 어려워하는 기술이다. 개발자는 프로젝트의 잘못된 점을 이야기하는 것에 익숙하고, 반사적으로 “안 돼요, 그건 불가능해요” 라고 말하는 습관을 고치기가 힘들다. 특히 상사나 동료와 이야기 나누며 거절해야 할 때, “네, 그리고” 전략을 사용하면서 의견 충돌 때문에 현실적인 우선순위를 협상하게 되는 과정을 잘 관찰해보라.
엔지니어들, 특히 대기업에서 오래 일했던 엔지니어는 “안 돼요”라고 말하는 것이 습관이다. “아마 될 것 같은데요.”라고 말했을 때 보상 없이 주어질 막중한 업무와 책임이 두렵기 때문이며, “안 돼요.”라고 말해도 “그래도 결국 닥달하면 될거 잖아요.”라고 생각할 카운터파트의 마인드셋을 알기 때문이다. 하지만 리더십은 팀원들에게 주어질 의미없고 과도한 업무를 사전에 막아주면서도, 사업의 성공을 위해 현실적 대안을 제시할 수 있어야 한다.
총평
나는 ‘안해봐서 잘 모르나본데, 매니징이란게 원래 다 그래.’ 라거나, ‘쪼는게 불편한 거 아는데 성과내려면 어쩔 수 없어. 이런 식으로 해야지.’ 라고 말하는 동료/상사를 경계한다.
책에서 말하는 원론적인 이야기들이 실제 프로젝트를 진행하는데 부합하지 않을 수 있다. 일정이 급하다면 때때로 이상적으로 올바르지 않은 방법을 택하기도 하고, 예정되지 않았던 야근을 강행하기도 해야 한다. 하지만 그럼에도 불구하고, 이상적인 매니징 방법론과 일 잘하는 방법을 끊임없이 추구하는 자세를 가져야 한다고 생각한다.
7~8년간 일해오면서 실무자로서 다양한 리더십을 경험했다. Follower 입장에서 가장 업무 동기부여가 잘 되었던 리더십은 자발적으로 이 프로젝트를 성공시키고 싶다는 마음이 들게 만드는 매니저였다. 그 동기부여가 나 개인의 성장이든, 매니저에 대한 존경심이든, 경제적인 보상이든, 기술적 호기심이든지를 떠나서.
책을 읽고 다시 한 번 상기시키는 점이 있다. 어떠한 매니징을 하더라도 좋은 테크니컬 리드로 나아가기 위해서는 구성원의 신뢰를 얻을 수 있는 압도적인 기술력이 기반 되어야 한다.
댓글 (0)
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요.