실리콘 밸리의 엔지니어링 매니저(리더)들은 대체 무엇을 하는가? (2편)

안녕하세요. 1편에 이어서, 오늘은 엔지니어링 매니저의 장기적인 커리어 패스는 어떻게 되는지, 엔지니어링 매니저 vs 엔지니어가 고민될 때 어떻게 해야 하는지, 그리고 엔지니어링 매니저의 채용 프로세스 및 센드버드에서 찾고 있는 엔지니어링 매니저에 대한 저의 생각을 정리해보겠습니다. (1편 바로가기)

엔지니어링 매니저의 커리어는?

엔지니어링 매니저에게는 대체로 두 가지 길이 있습니다. 하나는 Tech Lead Manager (이하 TLM) 라고 해서, 5명 내외의 작은 팀을 이끌어가면서 기술적인 방향성에 대한 오너십(ownership)을 겸비하고 소규모의 팀을 매니징하는 경우가 있고요, 다른 하나는 팀의 규모가 점점 커짐에 따라 기술적인 방향성은 팀 내의 시니어들에게 위임하고, 본인은 People Manager 방면으로 스케일을 키우고 레이어를 구축해가면서 건강한 문화와 프로세스를 가진 더욱 큰 조직을 만들어나가는 방향입니다.

흔히 TLM은 엔지니어링 매니저로서의 트랜지션(Transition) 과정으로 활용되는 경우가 많습니다. 엔지니어에서 엔지니어링 매니저로의 트랜지션이 생각보다 어려운 결정이기도 하고, 많은 분들이 되돌리기 힘든 결정이라는 생각을 많이 하시기 때문에, 그 변화에 대한 A/B 테스팅의 기회로 많이 쓰입니다.

특히 실리콘 밸리의 회사들은 TLM 역할을 “엔지니어링 매니저가 장기적으로 나에게 맞는 길인가”를 시도해 보는 트랜지션의 시기로 보고, 이 과정을 위한 트레이닝 및 서포트 프로그램을 제공합니다. 많은 사람들이 이런 프로그램을 통해서 매니저로의 커리어 체인지를 결심하거나, 엔지니어로 되돌아가는 선택을 하게 됩니다. 센드버드에서는 엔지니어링 매니저로의 직무 변경(role change)이 승진이 아닌 수평적 이동인데, 많은 실리콘 밸리 회사들이 그러합니다.

여기서 중요한 것은 엔지니어로 되돌아가는 것을 “실패”로 보지 않으며, 실제로 이 과정을 거친 후에 엔지니어로 돌아간 사람들은 더욱 넓어진 시야로, 시니어 엔지니어로서 더 성공적인 성장을 이루어 내는 경우도 많이 있습니다. TLM으로서의 경험은, 궁극적으로는 CTO 또는 창업을 하고자 하는 장기적인 목표를 가진 분들에게 엔지니어로서는 놓치기 쉬운 people 적인 관점을 직접 경험해보면서 기술적인 리더십과 경쟁력을 계속 키울 수 있는 기회이기도 합니다.

저희가 전형적으로 생각하는 Engineering Manager, Engineering Director, VP of Engineering 또는 Head of Engineering 이런 커리어 패스는 people management 와 조직의 운영에 포커스가 맞추어진 경우가 많은데 그 path 에 대해서도 조금 더 이야기해보려고 합니다.

첫번째 단계는 하나의 팀을 직접 리딩하면서, 1편에서 이야기했던 achievement / people / collaboration 이 세 가지 지표에 집중하는 역할을 많이 하게 됩니다. 그러면서 팀의 스콥(scope) 이 점점 늘어나고, 또 사람이 늘어나면서, 그 하나의 팀을 여러 개의 팀으로 function / project / component 또는 location 을 기준으로 나누면서, 조직을 더 효율적으로 운영하는 것에 집중합니다. 이 단계에서 주로 어떤 기준으로 팀을 나누고, 어떠한 방식으로 프로젝트와 팀을 운영할지를 고민하면서 조직 개편을 해볼 수 있는 기회를 맞이하게 됩니다. 정답은 없으며, 다양한 고민, 그리고 팀 내의 리드들 및 엔지니어링 리더십 팀들과 의논해가며 방향성을 잡고 첫 조직 개편을 실행해 나갑니다.

어느 정도의 팀의 구조가 잡히고, 그 팀들의 규모가 점점 커져갈 때 즈음부터는 조직 내의 레이어를 구축해 나가는 일을 시작합니다. 팀 내의 엔지니어들 중에 엔지니어링 매니저로서의 잠재력 및 관심과 의지가 있는 분들이 계신다면 그 트랜지션을 진행하고, 없다면 외부에서 채용해오는 프로세스를 시작합니다. 조직개편, 그리고 팀 내의 매니저를 키우는 등의 레이어링 과정은 (1편에서 언급했듯이) 팀원들에 대한 이해도가 높을 수록 성공적으로 잘 이끌어낼 수 있는 기반이 됩니다. 그런데 팀 규모를 비롯해서 매니저 본인의 스콥을 확장해나가는 것은 어떤 방식으로 이루어질까요?

사실 매니저가 시니어 매니저를 거쳐 디렉터로 승진하는 이러한 과정 중에는 많은 요소와 변수들이 작용합니다. 일단 비즈니스 니즈가 존재해야 하며, 실질적으로 회사나 팀 또한 계속해서 성장해가는 궤도(trajectory)에 있어야 하죠. 팀 자체의 역량을 성장시키는 것도 중요하며, 본인의 매니저 그리고 조직 내의 엔지니어링 리더십의 신뢰를 받는 것 또한 중요합니다. 그 과정 중에 엔지니어링 매니저가 거쳐야 하는 큰 변화 중 하나는, 단순히 본인의 팀 안에서의 맥락(context)이 아닌 엔지니어링 조직 차원에서의 맥락, 그리고 비즈니스 레벨에서의 이해도와 인사이트를 키워나가야 합니다. 여기서 저희가 1편에서 다루었던 Collaboration 과 Organizational Impact 가 점점 더 중요해집니다.

위와 같은 일을 반복하면서 스콥을 키워나가다 보면 자연스럽게 VP of Engineering 으로의 path 가 계속됩니다. 그 과정 중에 엔지니어링 조직내의 개발 문화, 인터뷰 프로세스, 성과 평과의 철학 등과 같은 다양한 부분에 좋은 영향력을 끼치며, 회사 내의 엔지니어링 조직을 대표하며, Product, People & Culture, Sales 등 회사 내의 다른 조직들과 함께 회사의 전략적 방향성에 영향력을 미치고, 엔지니어링 조직이 하는 일에 대한 가시성(visibility)을 제공합니다. 점점 더 tactical 한 부분보다 strategic 한 부분에 영향을 미치는 경우가 많아지며, 그 과정 중에 단기적인 영향 보다는 장기적인 방향성과 비전을 책임지게 됩니다.

페이스북 내에서 수많은 엔지니어링 리더들의 승진과 몰락(?), 제 자신의 실패와 성공을 경험하면서 제가 느꼈던 엔지니어링 매니저 커리어에서 장기적인 성장에 중요한 요소 중에 하나는 결국 팀과 회사에게 맞는 선택을 추구하는 가치를 유지하는 것이었습니다. 결국 내가 팀과 조직 그리고 회사에 맞는 방향과 대의명분을 추구하고, 그 회사와 조직 문화 또한 건강하다면, 자연스럽게 성장할 수 있다고 생각합니다. 그리고 엔지니어링 리더로서 구조화 되어 있고 체계화 된 성장을 원하신다면 큰 회사도 괜찮지만, 위와 같은 경험들을 더 많이, 빠르게 경험하기에는 센드버드와 같이 현재 진행형으로 가파른 성장을 하고 있는 회사에서의 엔지니어링 리더가 더 좋은 기회가 될 수 있습니다.

엔지니어링 매니저 vs 엔지니어가 고민될 때?

페이스북에서 엔지니어 / 엔지니어링 매니저로 성장해가는 과정에서 저는 회사 내 멘토들과 제 매니저에게 많은 도움과 조언을 받았습니다. 그 중에서도 제 나름대로 정리해 본, 엔지니어 vs 엔지니어링 매니저가 고민될 때 도움이 될 만한 부분들에 대해서 이야기해보려고 합니다.

제가 받은 첫번째 질문은 “왜 엔지니어링 매니저가 되고 싶은가?” 입니다. 그런데 이에 대한 답이 “더 많은 영향력을 가지고, 의사 결정을 내릴 수 있는 권한을 위해서”라면 적합한 판단이 아닙니다. 센드버드를 비롯한 미국의 많은 회사에서 엔지니어에서 엔지니어링 매니저로서의 트랜지션은 수평적 이동, 즉 Role 의 변화이기 때문입니다. 연봉과 주식, 그 어떠한 것도 늘어나지 않습니다. 매니저 역할에 도전해보았지만 적성에 맞지 아니하여 다시 엔지니어로 돌아갈 때도 마찬가지이며, 회사 내에서 그런 트랜지션 및 trial period를 적극 지원해주는 경우가 굉장히 많습니다. 반면에 본인이 직접 문제를 해결하는 것도 좋지만, 남들이 문제 해결을 할 수 있도록 도와주고 멘토링해주면서 그 성장을 도와주는 과정에서 얻는 즐거움과 성취감이 큰 것이 이유라면, 매니저로서 해야 하는 (조금은 피곤하고 지칠 수 있는) “사람”에 관련된 일들을 더 잘 해결할 수 있을 가능성이 높습니다.

두 번째 질문은 “하루 종일 미팅만 하는 모습을 상상해보아라” 입니다. 1편에서 언급했듯이, 효율적인 커뮤니케이션은 매니저의 역할을 잘해내기 위해 매우 중요한 역량입니다. 수많은 상황 변동(context switching)이 일어나며, 팀원들 간 또는 타 팀과의 의견을 조율하고, 본인의 매니저 및 여러 구성원들과의 1:1 대화 등… 엔지니어링 매니저 (리더) 들은 무수한 회의와 커뮤니케이션을 통해 팀원의 성장을 끌어내고, 혼란스러운 문제의 핵심을 짚어내어 교통정리를 하고, 중요한 stakeholder 들과의 대화를 통해 좋은 의사결정을 이끌어내는 등의 역할을 수행합니다. 그런 모습을 상상만 해도 피곤하고, 그 역할을 통해 일어내는 성과와 임팩트에 대한 열정이 없다면 엔지니어링 매니저가 되어 매우 불행할 수 있습니다.

그 외에도 멘토링 및 피드백을 준 경험, 미팅 중의 감정 조절, 의사 결정을 위임하고 팀원들을 empower 하는 역량 등에 대해 이야기하고 함께 고민했습니다. 그 당시 제가 인턴 매니저로서 어떻게 피드백을 제공했고, 그 과정에서 상대방의 입장에서 공감하려는 어떤 고민들을 했는지, 그리고 긍정적이고 부정적인 상황에서 격해진 감정을 표현하는 방법 등… 리더가 되는 순간부터 나의 말 한 마디가 갖는 영향력과 의미가 커지기 때문에, 특히 Intention ≠ Perception(내 의도가 항상 그대로 전달되지는 않는다) 에 대한 이야기부터 시작해서 다양한 이야기를 나누면서 매니저로서의 path 가 맞는지에 대한 많은 생각을 한 후에 트랜지션을 시도해보기로 결심할 수 있었습니다.

조금은 두서없는 글이지만, 좋은 엔지니어링 매니저가 될 수 있을까, 내가 열정을 갖고 성장해가면서 그 역할을 할 수 있을까를 고민하고 계신 분들에게 도움이 되면 좋겠습니다.

센드버드의 엔지니어링 매니저 채용 프로세스는?

엔지니어링 매니저를 채용하는 프로세스는 회사 및 조직마다 조금씩 차이가 있을 수 있지만, 오늘은 센드버드의 엔지니어링 매니저의 면접 프로세스에 대해 이야기 해 보겠습니다.

일단 이력서 등을 기반으로 일반적인 서류 심사를 거친 후 하이어링 매니저와 1차 인터뷰를 진행합니다. 이 때 첫 25분은 엔지니어링 매니저로서 팀에 어떤 방식으로 기여하는지를 알아보는 시간입니다. 회사와 조직 마다 엔지니어링 매니저에게 기대하는 역할이 다르기 때문에 정답이 있는 것은 아니므로, 후보자가 주어진 환경 및 맥락에서 어떤 방식으로 매니저의 역할을 수행하는지에 집중합니다. 그 다음 25분 가량은 기존에 프로젝트를 진행하면서 내린 기술적인 의사 결정과 그 과정들을 회고(retrospective) 하고, 함께 시스템 디자인 문제를 풀기도 합니다. 마지막 10분 동안은 후보자가 센드버드라는 회사, 혹은 해당 팀에 대해 궁금한 점을 물어보는 질의응답 시간을 갖습니다. 인터뷰라는 것이 회사가 후보자를, 그리고 후보자가 회사를 평가하는 상호보완적인 프로세스이기 때문입니다.

이 단계를 통과한 후보자는 현장에서 약 45분 동안 총 5 개의 추가 인터뷰를 진행하게 됩니다. 첫번째로 기술적인 검증으로는 코딩 알고리즘과 시스템 아키텍쳐 인터뷰가 각각 하나씩, 문제 해결 능력을 평가하는 방식으로 진행됩니다. 이후에 하이어링 매니저와 People Management 에 대한 면접을 하나, 그리고 엔지니어링 리더 중 한분과 Cross functional 한 협력(collaboration) 및 리더십에 대한 면접을 하나 진행합니다. 마지막으로는 센드버드의 코어밸류와 관련해서, 회사와 후보자 간의 Fit 을 검증하는 면접이 진행됩니다. 포지션에 따라서는 이러한 인터뷰 중 하나 정도는 절반이 영어로 진행되기도 합니다.

이런 인터뷰 과정이 끝나면 면접관 피드백을 모두 취합한 후, 하이어링 매니저의 주도 하에 합격 여부 또는 추가 인터뷰의 필요성에 대한 논의가 이루어집니다. 합격이 결정되었다면 본격적으로 레벨링 및 오퍼 패키지에 대한 의논이 이루어지고, 이러한 부분은 Head of People and Culture 및 CEO의 검토를 거쳐 확정이 됩니다.

무척 길고 힘든 과정이라고 생각하실 수 있겠지만, 엔지니어링 매니저 (리더)를 잘못 뽑았을 때 감수해야 할 타격을 고려한 프로세스입니다. 그리고 이러한 과정은 후보자에게도 회사, 그리고 같이 일할 팀원들에 대해 평가할 수 있는 좋은 기회가 되기도 합니다.

센드버드가 엔지니어링 매니저를 구합니다

지금 센드버드는 엔지니어링 매니저 분들을 모시고 있습니다. 부문 별로는 Messaging Server 팀에서 엔지니어링 매니저 2분을, 그리고 Messaging SDK 팀에서도 iOS팀을 이끌어주실 매니저 1분을 구합니다. 관심있으실 분들을 위해 각 포지션에 대한 소개 및 어떤 일을 하시게 될지에 대해서 간단하게 공유해보고자 합니다.

Messaging Server 팀에서는 reliability, latency, alerting 및 operation cost 에 대한 투자를 하는 5 명 안팎의 팀과 (SRE Squad 라고 부릅니다), features, customer requests 및 developer efficiency (DEV Squad 라고 부릅니다) 분야를 맡고 있는 6-7명 규모의 팀을 각각 hands-on 하게 이끌어주실 분들을 찾고 있습니다. (포지션 공고 링크)

SRE Squad는 저희가 다루는 트래픽과 scale 에서 안정성을 유지하면서 장애들에 대한 post-mortem 들의 action item 들을 팔로업하고, oncall 의 operation efficiency 를 위한 툴링 등에 대한 프로젝트들이 다양하게 진행 중입니다. low-level debugging 및 profiling 까지, 다양한 인프라에 걸쳐, 해결하기 까다로운 다양한 장애 현상들을 root-causing 하는 등의 기술적인 챌린지들을 함께 풀어가고 싶으신 분들을 찾고 있습니다.

DEV Squad 같은 경우는 저희의 수많은 고객들이 사용하게 될 Feature 들을 저희가 받고 있는 트래픽에서 scalable 하게 작동할 수 있도록 설계하는 일부터 시작해서, 고객들의 비지니스에 대한 이해도를 키워가며 가장 큰 임팩트를 주는 요청들을 다양한 방법으로 address 하며 해결해나가는 일을 합니다. 그 외에도 developer efficiency 에 대한 투자로 배포의 효율화를 위한 툴링이나 DB sharding 과 같은 프로젝트를 진행하고 있습니다.

그 외에도, 미국에 있는 서버 팀 및 회사 내의 cloud / data 인프라 팀들과 함께 현재 아키텍쳐가 가지고 있는 cost, scale 및 iteration speed 에서의 챌린지들을 해결하고 확장성을 갖추기 위해 시스템의 일부를 microservice architecture 로 리팩토링하고 language transition 를 진행하는 initiative 가 킥오프 중에 있습니다.

iOS 팀 또한 5명 이하의 팀으로, 저희 메인 SDK 인 Core SDK 와 UIKit 을 구축하는 과정에서 hands-on 하게 이끌어주실 분을 찾고 있습니다. 고객들이 확장성을 가지면서도 사용하기 편리한 SDK 를 만들기 위해 많은 고민이 필요하며, 최근에는 Core SDK를 사용하는 앱의 메시지 로딩 성능 개선과 약전계/오프라인 대응을 위한 local caching 개발 등의 메시징 서비스 고도화 프로젝트 및 기존의 Obj-C 기반 코드를 Swift로 점진적으로 전환하는 등의 기술 과제를 진행중입니다. (포지션 공고 링크)

기승전 채용 홍보… 로 글을 마치게 되었는데요, 부족한 부분이 많지만 제가 경험하고 느꼈던 부분들을, 회사 안팎에서 많은 분들이 피드백과 도움을 주셔서 이 글을 완성하게 되었습니다. 센드버드는 많은 시행 착오와 업앤다운을 거치면서 지금까지 왔습니다. 그 과정 속에서 회사와 함께 임직원들도 많이 성장했지만, 앞으로도 계속해서 성장하고 해나가야할 일들이 많이 있습니다.

이 글을 읽으시면서 조금이라도 설레이셨거나, 이런 글로벌한 회사에서 엔지니어링 매니저 및 리더로서 함께 성장하시고 싶으신 분들은 꼭 지원 부탁드리겠습니다. 감사합니다.

센드버드는 지속적인 블로그 공유 및 개발자 분들을 위한 이벤트와 교류 기회들을 준비하고 있습니다. 관련 정보를 수신하고자 하시는 분들께서는 링크에서 메일링 신청을 부탁드립니다.

채용 및 포지션에 대한 문의는 talent.kr@sendbird.com으로 연락 주시기 바랍니다.