[한글화 프로젝트] 개발자에서 관리자까지: 기술력을 유지해라
대표 번역가 : 백재영
나는 2년 전에 엔지니어링 관리자가 되었다. 관리자로 있는 동안 주된 과제 중 하나는 우리 팀에 대한 나의 리더십과 코딩을 하고 싶은 욕구 사이의 균형을 잡는 것이었다.
분명 이런 일로 고군분투 하는 것은 나만은 아닐 것이라 생각한다. 그래서 내 생각을 공유하고자 한다.
왜 엔지니어링 관리자가 기술적으로 뛰어나야 하는가
나는 실무 위주의 기술적으로 뛰어난 관리자가 엔지니어링 팀(그리고 대부분의 시간에 딜버트의 법칙을 벗어난 팀)의 최고의 리더라고 생각한다. 기술적으로 뛰어난 관리자로서 당신은,
팀원들이 수행해야 할 직무에 관련된 숨겨진 복잡성을 이해하고 팀원들과 더 쉽게 의사소통할 수 있으며 제품 또는 마케팅 같은 비 기술적인 관계자들의 메시지를 단순화 할 수 있을 것이다.
팀원들을 효율적으로 이끌고 기술영역에서 솔선수범할 수 있을 것이다.
팀이 쓸 수 있는 툴과 프레임워크를 숙지하고 더 나은 기술적 방향을 제시할 수 있을 것이다.
팀원들의 신뢰와 존경을 더욱 받기 쉬워질 것이다. 이것은 비기술적 관리자들은 그럴 수 없다는 뜻은 아니다.
향후 컨트리뷰터로 돌아갈 수 있도록 여지를 두어라.
기술력을 갈고 닦는 것은 정말 좋은 생각이라는 것에 다들 동의할 것이다. 그러나 이것들은 도전이 없이는 불가능하다.
코더 vs 멘토
당신이 직면하게 될 첫 번째 도전은 엔지니어로서 그리고 멘토로서의 갈등이다. 엔지니어로서는 팀이 직면한 모든 흥미로운 기술적 도전들을 해결하려 할 것이다. 반면, 멘토로서는 능력을 향상시키고 더 나은 개발자가 되고자 하는 팀원에게 (도움이 되는) 문제를 주고 싶어 할 것이다.
시니어 개발자가 부족하고 주니어 개발자가 많은 팀에서는 이 문제가 심각해질 수 있다. 그럴 경우, 엔지니어링 관리자는 자신의 역할에서 멘토십을 더욱 강조해야 한다.
당신의 팀을 성공적으로 만들어라
어떤 코딩보다도 팀과 팀원들이 우선이다. 당신이 코딩하는 데에 전념할 수 있는 필요조건은 팀이 성공했을 때이다.
관리자로서 당신은 제품을 만드는 것이 아니라, 제품을 만들 수 있는 팀을 꾸리는 것이다. 따라서 팀을 성공적으로 운영하는 것이 자신을 평가할 수 있는 주 목표 및 척도가 되어야 한다. 만약 당신이 행복한 엔지니어들로 구성된 성공적인 팀을 이끈다면 팀의 성공은 따라올 것이고, 팀원과 상사에게 성과를 설명하려는 일에 시간을 덜 보낼 수 있을 것이다.
의사 결정에 병목 현상이 없는 능력을 갖춘 실력있는 팀원들로 이루어진 자립심 있는 팀은 당신이 뭔가 다른 일을 할 수 있도록 해줄 것이다.
당신의 말에는 더 많은 무게가 있다
나에게 또다른 도전은 팀이 기술 문제를 해결하는 방법을 논의할 때 너무 강하게 내 의견을 표현하는 것이었다. 전 팀원과의 feedback session에서 팀원이 알려주기 전까지는 이 문제에 대해 알지 못했다. 그녀는 “우리가 기술 토론을 할 때 당신은 너무 독단적이에요… 팀원들에게 더 양보해야 해요.”라는 식으로 말했다.
일부 관리자는 정말 강경하고 권위있게 말을 하지만, 그것은 다른 이들이 가질 수 있는 의견차를 표현하지 못하게 방해할 수 있고 이는 좋지 못한 해결책으로 귀결될 수 있다는 것을 깨달았다.
그래서 내 조언은?
답을 하기보다는 항상 마지막으로 이야기하고 질문해라
이것은 아무리 강조해도 지나치지 않다. 관리자는 자신의 글이나 말하는 모든 단어가 어떤 식으로든 팀원의 아이디어나 제안을 잠재적으로 침묵시킬 수 있다는 것을 충분히 인지해야 한다.
더 나아가 James Everingham은 양자 역학 비유에서 관리자의 단지 관찰만으로도 프로젝트의 결과를 바꿀 수 있다고 이야기한다.
관찰자 효과는 직장에서 실제로 발생하며, 프로젝트의 관리자가 되는 것만으로도 프로젝트 결과에 영향을 끼칠 수 있다. 종종 관리자는 팀원들을 불러 칠판에 적기 시작하면서 “우리가 해야 할 것들” 또는 “내가 생각한 것들” 또는 “이것에 대해 생각해볼 수 있는 한 방법은...” 이라고 말할 것이다. 그들은 가치를 높이려 노력한다. 또한 우리도 항상 가치를 높이길 원한다. 그러나 여러분이 권위자의 자리에 있고 이런 식으로 한다면 당신은 제한된 결과를 초래한 것이며 성공의 길을 크게 제한한 것이다.
개발자 vs 관리자
내가 직면한 더 큰 도전은 개발자의 시간표와 관리자의 시간표를 조합하는 것이었다. Paul Graham의 말에 따르면,
대부분의 영향력 있는 사람들은 관리자의 시간표에 있다. 이건 지시의 시간표이다. 그러나 프로그래머나 작가같이 뭔가를 만드는 사람들에게는 시간을 사용하는 또다른 방법이 있다. 그들은 보통 적어도 반나절 단위로 시간을 사용하는 걸 선호한다. 글이나 프로그램을 한시간 단위로 쓸 수는 없다. 1시간은 간신히 시작할 시간이다.
간단히 말해서, 관리자의 단편적이고 수동적인 회의 중심의 일정은 코딩에 필요한 집중 요구 사항(일종의 Deep Work 같은)을 잘 나타내지 않는다. 관리자와 엔지니어의 일정은 서로 반대된다고 말할 수 있다. 엔지니어는 가능한 주의가 산만하지 않아야 하는 반면, 미팅에 참석하지 않거나 다른 팀과 소통하지 않는 관리자는 조직에서 충분히 눈에 띄지 않는다는 평을 받을 수 있다.
두 일정을 섞지 마라
http://dilbert.com/strip/2012-05-30
시도조차 하지 마라. 이건 좌절을 느끼게 해주고 비생산적인 방법이다. 물과 기름처럼, 이것들을 분리하고 독립시켜서 본연의 상태 그대로 유지하는 것이 가장 좋다.
나는 점심시간과 같은 자연스런 방해와 내 일정을 분리하려 노력한다. 오전 내내 회의를 계속하고, 지친 상태에서 엔지니어로 돌아와 오후를 보내며 어려운 프로그래밍 문제에 집중하려고 한다. 적어도 일주일에 두 번은 그렇게 하려고 노력한다.
나는 충분한 점심시간을 갖고 가급적이면 사무실 밖에서 산책하면 회의에 있었던 신경을 끊고 다시 돌아와 상쾌한 마음으로 생산적으로 코딩을 할 수 있다는 것을 알게 되었다.
엔지니어일 때는 가능한 집중을 방해하는 모든 것들을 피해야 한다. 우선 이메일을 꺼라. 그리고 브라우저에서 주의를 산만케 하는 모든 탭ㅡ가령 Facebookㅡ을 닫거나 새 브라우저를 열어 찾으려 하는 문서만 참조해라. 끝으로, HipChat/Slack도 꺼라. 물론 긴급 이슈가 생겼을 때 팀원이 당신을 찾을 수 있도록 몇몇의 커뮤니케이션 채널은 항상 열어 놓아야 한다.
생산적이고 집중력을 발휘할 수 있다는 것은 당신의 육체 그리고 정신에 크게 의존한다. 주위 환경을 바꾸거나 조정함으로써(다른 책상/장소에서 일하거나, 특정 유형의 음악을 듣거나 무엇이든 간에), 정신을 최대한 생산적으로 만들 수 있다.
Cal Newport의 책 Deep Work에서 심도깊은 작업을 처리하는 법에 대해 더 많은 요령을 얻을 수 있다.
코드 병목 현상
바쁜 일정을 감안할 때, 아마도 빠른 시일 내에 코딩을 마치기 힘들 것이고, 따라서 아마 일부 기능은 프로덕션에 병합되거나 배포되기 힘들 것이다. 더 나쁜 것은, 뭔가 잘못되기라도 한다면, 운영중인 사이트의 이슈나 파이프라인이 깨졌을 때와 같은 기술적 문제를 급하게 처리하지 못할 수도 있다.
팀의 리더로서 당신은 팀원들이 회의나 대화에 방해받지 않고 코딩에 집중할 수 있도록 분주히 움직여야 한다. 다시 말해서, 당신의 일은 코딩하는 것이 아니라 팀원들이 효율적으로 코딩할 수 있도록 하고 팀원의 성과를 부각시키는 것이다.
코드를 꼭 출시할 필요는 없다??
한 친구와 프로덕션 코드에 직접 참여하고 관여하는 매니저들에 관해 이야기 나눌 때 이런 조언을 해줬다.
팀의 병목이 되어선 안된다. 당신의 도움 없이 모든 기술적인 문제를 해결할 수 있도록 팀원들을 지도하고 멘토가 되어야 한다. 결코 프로덕션 코드를 작성할 필요가 없어야 한다. 코딩에 시간을 많이 할애하는 것은 비기능적인 궂은 일이다. 빌드를 더 빠르게 만들고, 공통된 코드들을 한 라이브러리로 추출해라. 팀의 일을 보다 생산적이고 재미있게 만들어 줄 수 있는 것들을 찾아라. 또한 사내에서 또는 개인적으로 개념 증명(Proofs Of Concepts) 코딩에 초점을 맞추거나 팀에서 사용할 신기술을 찾아본다거나 사이드 프로젝트를 진행함으로써 기술력을 유지시킬 수 있다.
나는 이 충고를 마음에 새겼고 그 결과에 더할 나위 없이 만족했다. 그 과정에서 내가 팀에서의 기술적 병목 현상이 아니란 사실을 알았을 뿐만 아니라, 팀원이 스스로 도전에 직면하고 배우면서 더 나은 개발자가 되어 스트레스를 덜 받게 되었다.
내 기술적 지식을 전달하기 위해 나는 흥미있는 주제에 관해 페어 코딩을 하고, 전 팀에 걸쳐 기술적 문제를 다같이 해결하거나 그저 기술적 지식과 의견을 공유하기 위한 “클린 코드 세션” 또한 운영한다.
요즘 내 코딩의 대부분은 Expedia(익스피디아 알렉사 스킬 같은), markpress 같은 사이드 프로젝트, 쓸모 없지만 쿨한 Rolex GMT 크롬 시작 탭 확장같은 사이드 프로젝트이다.
결 론
코딩까지 할 수 있는 관리자가 되는 것은 마치 투잡을 갖는 것과 같다. 매우 힘들고 또한 많은 헌신이 필요하다. 팀을 이끌고 성장시키는 것과 당신의 기술력 향상 사이에 균형이 잘 잡히지 않으면 벅차거나 지칠 것이다.
나는 리더십과 코딩을 모두 사랑해야 한다고 말하고 싶다. 관리자로서 또는 개발자로서 자신을 성장시키는 데에 더 많은 시간을 할애해야 하기 때문이다. 그러나 그만한 가치가 있다! 결국, 이런 게 삶 아니겠는가.
더 읽어볼 거리
Developer turned manager — Article by Stackoverflow’s David Haney
Average vs Great manager — Article by Facebook’s Julie Zhuo
Maker’s schedule, Manager’s schedule — Article by Paul Graham
Deep Work — Book by Cal Newport
Team of Teams: New Rules of Engagement for a Complex World — Book by General Stanley McChrystal
The Principles of Quantum Team Management — Article by James Everingham, Head of Engineering at Instagram.