brunch

You can make anything
by writing

C.S.Lewis

by YL Jan 14. 2018

개발팀장들의 공통점

실리콘밸리와 캐나다 테크 회사에서 같이 일해본 개발 매니저들과의 경험

지금까지 소프트웨어 엔지니어로 (혹은 개발자) 일하면서 많은 매니저들과 같이 일을 했다. 제품이나 서비스 관리를 책임지는 프로덕트 매니저 (Product Manager), 그리고 대개 엔지니어들과 같은 팀에 속해서 팀을 이끄는 소프트웨어 엔지니어링/개발 매니저 (Software Engineering/Development Manager). 간단한 검색으로 알게 된 건 한국에서는 개발팀장이라는 직책이 더 보편적으로 사용되는 것 같다.


개인적으론 개발팀장이 되는 것을 목표로 하고 있고 더 관심이 있기 때문에 이에 대해서 글을 적어보려 한다. 그중에서도 지금까지 같이 일한 개발팀장들의 공통점들을 공유하고 싶다.


개발 매니저와 주기적인 1:1 미팅 (1-on-1)


소프트웨어 엔지니어로 일한 모든 회사에선 개발팀장과 1-on-1이 있었다. 1-on-1이란 개발팀장과 단 둘이 30분에서 1시간 정도 다양한 주제에 대해서 자유롭게 얘기를 나눌 수 있는 미팅이다. 대부분 1주 혹은 2주에 한 번씩 시간이 정해져 있다. 개발팀장은 팀 내 인턴을 포함한 모든 인원과 1-on-1을 진행한다. 내 첫 1-on-1도 샌프란시스코에서 인턴으로 일할 때였다. 시작 전엔 막연히 내가 참여하는 프로젝트에 대해서만 얘기할 줄 알았지만 사내 문화, 업무 피드백, 내 커리어 등 주제에 제한이 없었다. 심지어 샌프란시스코에 처음 와본 나에게 가볼만한 식당이나 카페 얘기로 30분을 채운적이 있었다.


내가 생각하는 1-on-1의 목적은 개발팀장과 팀원이 서로를 알아가고 자유롭게 피드백을 주고받는 것 같다. 외국에서 꽤 살았지만 아직도 한국적인 조직 문화가 좀 더 익숙한 나에겐 내 상사에게 피드백을 준다는 것이 무척이나 생소했다. 무기명으로 어디에 적는 것도 아니고 작은 방 안 소파에 앉아 서로를 마주 본 상태에서 내 매니저를 평가해야 한다는 것이 쉽지 않았다. 그래서 미팅 중에 이 어색함에 대해서 솔직하게 말을 꺼낸 적이 있었다. 정확히 말하자면 나와 같이 일하는 사람에게 편하게 피드백을 주는 방법을 잘 모르겠다고 했었다. 내 매니저는 (내게 맛집 추천을 해준 그 매니저) 커리어 초반에는 그럴 수 있는 게 당연하다면서 다음 1-on-1에는 한 주동안 일하면서 이 팀의 좋았던 점과 개선이 가능한 점을 아주 간단히 적어오는 게 어떻냐고 했다. 내가 인턴이었음에도 내 의견이 다른 팀원들이 의견과 똑같이 중요하다고 생각하는 것 같았다. 이 회사뿐만 아니라 다음에 가게 된 회사에서도 같은 느낌을 받았고 지속적인 양방향 피드백을 통해 현 상황을 끊임없이 개선하려는 문화가 지배적이었다. 물론 지금 풀타임으로 일하는 곳도 똑같다.


"지금 여기서 행복한가요?"라는 질문


이 질문은 앞서 말한 1-on-1에서 자주 들었던 질문이다. 같이 일했던 모든 개발팀장들로부터 이 질문을 똑같이 받았다. 4개월짜리 인턴일 때도 물론이고 정직원으로 일하고 있는 현 직장에서도 주기적으로 물어봤다. 처음에는 형식적인 질문이겠거니 생각해서 무조건 그렇다고 했다. 이 회사에서 일하는 것이 마음에 든다 라고. 몇 번의 1-on-1에서 똑같은 대답을 하고 나니까 나에게 좀 더 자세하게 질문을 던지기 시작했다. 팀에서 한 가지를 바꾸고 싶다면 그게 무엇인지, 내 업무 중 마음에 안 드는 것이 있는지, 관심이 가는 다른 팀이 있다면 그 이유가 무엇인지 등 여러 가지 추가 질문이 있었다. 전부 다 회사에서의 내 만족도를 가늠하기 위한 질문들이었다. 이 질문들을 듣고 나서야 내가 회사에서 행복하냐는 질문이 형식적인 것이 아니라는 걸 깨달았다. 팀원들의 만족도에 많은 신경을 쓰는 문화가 존재하고 이를 파악하기 위한 방식이었다. 그 개발팀장이 내 답변을 듣고 더 자세히 물어보지 않았다면 나도 "지금 여기서 행복한가요?"라는 질문의 의도를 몰랐을 것이다.


여기서 중요한 건 이 질문에 대한 내 대답이 그저 대답으로만 끝나지 않았다는 것이다. 내가 속한 팀과 많이 다른 업무를 맡은 팀에 관심이 간다고 했을 때 개발팀장은 주저 없이 그 다른 팀의 매니저와 미팅을 잡아줬다. 모든 직원이 자신이 하고 싶은 일만 할 수 없지만 가능한 선에서 최대한 팀원의 관심사를 맞춰주려는 분위기였다. 개개인의 업무 만족도가 높아야 업무의 효율이 좋아진다라는 사내 문화를 가지고 있었다. 그렇기 때문에 모든 개발팀장이 회사에의 생활이 행복한지 항상 물어본 것 같다.


모든 팀원의 업무 진행 상황 파악


개발팀장이 팀원들의 업무를 파악하는 건 당연하게 들리지만 쉬운 것이 아니기 때문에 적게 되었다. 특히 직접적인 코딩을 할 시간이 없는 개발팀장에게 프로젝트의 진행 상황을 자세히 아는 건 어렵다고 생각된다. 더욱이 테크 회사에서의 팀은 다양한 프로젝트를 진행한다. 예를 들어 시애틀에서 인턴으로 일할 때 내 팀에 8명의 엔지니어가 있었고 두 명을 제외하고 전부 다 개인 프로젝트가 있었다. 각자가 관여하는 코드 베이스와 프로젝트의 진행 상황이 저마다 다른 상황이었다. 개발팀장은 매일 아침 스탠드업을 (stand-up, 개인의 업무 진행 상황과 프로젝트에 방해가 되는 부분을 짤막하게 팀과 공유하는 미팅) 통해서 팀원들의 업무를 파악했고 애매한 부분이 있다면 해당 팀원과의 개별적 대화로 진행 상황을 들었다. 또한 프로젝트 관리 툴에 수정이 안 된 부분이 보이면 현 상황이 무엇인지 물어봤다. 여기서 중요한 점은 팀장과 팀원 사이의 보고의 빈도를 최소한으로 하되 정확한 상황을 파악하려 하는 것이다. 내가 일한 다른 회사의 개발팀장들 동일한 생각을 가지고 있었다.


업무 진행 상황에 관해서 개발팀장들이 항상 주시하는 내용은 이 정도로 추려지는 것 같다:

    - 팀원들에게 배정된 프로젝트들이 무엇인지

    - 설계적인 관점에서 각각의 프로젝트가 어떻게 구현되는지

    - 프로젝트가 어느 단계에 있는지


물론 팀장이 알고 있어야 할 것은 팀원의 업무 진행 상황만 있는 것은 아니다. 하지만 회사의 종류와 개발 팀의 규모와 상관없이 모든 개발팀장들이 이 부분에 집중하는 것을 느꼈다.


팀 내 생산성 향상을 위한 노력


개발자에게 있어서 생산성을 올려주는 것은 여러 가지가 있다. 몇 가지만 나열하자면 더 편한 개발 툴, 직관적인 사내 커뮤니케이션 툴, 개발 시간을 위한 최소한의 회의, 타 팀 혹은 다른 팀원에 대한 의존도 제거가 있다. 생산성이 중요하다는 것인 누구나 다 알기 때문에 같이 일한 개발팀장들도 역시 팀 내 생산성 향상에 많은 신경을 썼다. 회의 또는 회사에서의 일상 대화에서 업무 방식의 개선점에 대해 항상 물어봤다. 다들 팀원의 경력에 상관없이 불편하다고 느끼는 점이나 더 나아질 수 있는 부분을 찾으려 했다. 지금까지 일한 회사들이 조금씩은 다른 분위기였어도 현 상황에서 안주하지 않으려 하는 점은 똑같았다.


학교 졸업 후 첫 직장인 지금 회사에서 같이 일하고 있는 개발팀장도 이 점을 상당히 중요시한다. 특히 내가 입사한 지 얼마 안 되었을 때 필요한 개발 툴이 있으면 알려달라고 했던 적이 있다. 내가 생각하기에 더 편하게 쓸 수 있는 툴과 왜 더 편한지에 대해 전달했고 며칠 지나지 않아서 해당 툴의 라이센스를 받았다. 시간이 더 지나고 업무에 익숙해지고 난 뒤에는 개발에 방해가 되는 요소가 있는지 물어봤다. 내가 있는 팀의 특성상 다른 팀에서 질문이나 검토 요청이 많이 들어오는데 대부분이 사내 커뮤니케이션 툴로 전달되었다. 코드 작성 중간에 알림이 오면 질문을 이해하고 답변을 해주는데 시간이 걸린다. 뿐만 아니라 필요한 답을 위해 정보를 찾거나 조사하는 시간도 필요하다. 답변을 끝나고 적고 있던 코드로 돌아와서 다시 이어가는 때까지도 어느 정도 시간이 소요된다. 이런 일이 빈번해지자 팀장에게 이러한 이유로 개발 시간이 줄어든다고 얘기를 꺼냈다. 개발팀장도 이 점이 생산성을 떨어트린다고 생각을 했고 바로 다른 팀의 개발팀장들과 얘기를 해보겠다고 했다. 결과적으로 급하지 않은 질문이나 검토는 프로젝트 관리 툴에 티켓을 만들고 해당 팀에게 할당하는 것으로 정해졌다. 개인적으로 당장 해결책이 필요한 것이 아니라고 생각했지만 내 개발팀장의 입장에선 달랐다. 팀원의 생산성을 중요하게 생각한다는 것을 너무나 잘 느낄 수 있는 날이었다.


이 글에 적은 네 개의 공통점 말고도 개발팀장에게 요구되는 점은 더 있을 것이다. 개발자의 입장으로서 내가 직접 느낀 공통점을 적어 보려고 했고 내가 이 직책을 가지게 된다면 개인적으로 중요시하고 싶은 것들과 겹치는 것을 소개하고 싶었다. 경험이 더 있었다면 더 많은 게 보였겠지만 지금까지 봐온 것들을 솔직하게 적었다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari