Introduction
많은 개발자들이 한번쯤은 서게 되는 커리어 갈림길이 있죠.
이 질문은 단순해 보이지만, 그 답은 결코 쉽지 않습니다.
메타(구 페이스북)의 스태프 엔지니어 Ryan Peterman은 이 질문에 대해 자신만의 답을 찾아 나섰는데요. 그는 매니저로 전환했다가 다시 개발자로 돌아온 경험을 바탕으로, 아래와 같이 고백합니다.
그런데 더 놀라운 점은, Ryan이 이 경험을 후회하지 않는다는 것입니다. 오히려 이 경험이 자신의 경력에 큰 도움이 되었다고 말합니다. 과연 그 이유는 무엇일까요?
이 글에서는 Ryan의 경험을 통해, 엔지니어링 매니저로의 전환이 가져올 수 있는 장단점을 솔직히 파헤치고 있어요. 여러분이 개발자 커리어에서 중요한 결정을 앞두고 있다면, 아래 내용이 그 해답의 실마리가 되어줄 것이라 믿습니다 :)
엔지니어링 매니저가 되어야 할까요?
엔지니어링 매니저로 커리어를 설정할 때 고려해야 할 사항들
어느 시점에서, 여러분은 사람을 관리하는 매니저가 될 것인지 아니면 개별 기여자(Individual Contributor, IC)로 남을 것인지 결정해야 합니다. 물론, 어느 길이 객관적으로 더 낫다고 할 수는 없죠.
제가 메타(Meta)에서 스태프 엔지니어(IC6)(역: 스태프 엔지니어에 대해 보다 자세히 알고 싶다면 <스태프 엔지니어>를 읽어보시길 권해드립니다.)가 되었을 때 이는 즉각적인 질문이 되었습니다. 저는 전환을 결정하기 전에 여러 시니어 매니저와 IC들로부터 많은 정보를 수집했습니다.
이 글에서는 제가 수집한 모든 내용을 공유하여 여러분이 정보에 기반한 결정을 내리는 데 필요한 가장 중요한 정보를 제공하고자 합니다.
경력 성장
매니저의 경력 성장은 팀의 규모에 따라 결정됩니다. 예외는 있지만 대부분의 경우, 승진은 더 큰 팀에서 지속적으로 영향력을 발휘했을 때 따라오게 되죠. 문제는 비즈니스 영역에서 해당 팀을 필요로 할 때만 팀이 성장한다는 점입니다. 팀이 성장할 이유가 없다면, 여러분이 매니저로서 일을 얼마나 잘 하는지와 관계없이 경력이 정체될 수 있습니다. 따라서, 매니저는 IC에 비해 자신의 경력 성장을 통제할 수 있는 여지가 훨씬 적습니다. 커리어 의존성이 개인보다 팀의 퍼포먼스에 훨씬 강하게 커플링되어있죠.
하지만 운이 좋다면 이는 특별한 경력 성장으로 이어질 수 있습니다. 페이스북 초창기에 입사한 많은 사람들이 회사가 빠르게 성장하면서 불과 1-2년 만에 디렉터로 승진하는 것을 보았는데요("태풍이 불면 돼지도 날아오른다고 하죠😀"). IC였다면 어떨까요? 이와 같은 환경에서라면 매니저와 같은 수준의 성장을 만드는데 훨씬 더 오랜 시간이 걸릴 것입니다.
또한, 매니저는 IC에 비해 경력 이동성이 떨어집니다. 이는 일반적으로 회사에서 매니저 역할이 더 적기 때문입니다. 반면에 우수한 시니어 IC는 거의 어디든 갈 수 있습니다. 앞서 말했듯, 이들은 스스로 영향력의 범위를 만들어내고 팀에 의존하지 않기 때문입니다.
업무 스타일
매니저는 거의 전적으로 위임과 영향력을 통해 일합니다. 이는 대부분의 시간을 사람들과 회의를 다루는 데 보낸다는 뜻이죠. 이는 다음과 같은 단점이 있는데요:
- 일정이 파편화되어 깊이 있는 작업을 할 시간이 거의 없음
- 일정에 대한 통제력이 떨어짐. 회의가 업무 시간을 좌우함
- 정치와 갈등이 불가피하게 발생함
많은 엔지니어들에게 이는 지옥처럼 들릴 수 있습니다만😅, 이러한 업무 스타일에는 장점도 있습니다:
- 보통 업무 시간 이후에는 일이 끝남
- 일을 완수하는 주요 도구가 대인 관계 능력이기 때문에 이 기술이 향상됨. 이는 개인 생활에도 도움이 됨
가장 큰 트레이드오프는 근무시간이 줄어드는 대신 시간에 대한 통제력이 떨어진다는 것입니다. 제가 매니저들에게 설문조사를 했을 때 모두가 이와 비슷한 말을 했는데요. 매니저가 자신의 시간을 영향력과 맞바꾸지 않는다는 점을 고려하면 이는 당연한 일입니다. 이렇듯 매니저 포지션은 위임과 영향력을 통해 판단력을 확장합니다.
왜 엔지니어링 매니저가 되어야 할까요?
이쯤 되면 일부 엔지니어들은 왜 누군가가 매니저가 되고 싶어 하는지 의아해할 수 있는데요. 누군가에게는 아래와 같은 이유로 관리직이 적합할 수 있습니다:
- 여러분의 강점과 관심사 - 몇몇 매니저를 만난 적이 있습니다. 이들은 자신이 IC로 일할 때부터 언젠가 매니저로 포지션을 옮길 것이라는 것을 스스로 알고 있었다고 말했습니다. 왜냐면 그들이 가진 스킬셋이 매니저에 더 적합했기 때문이라고 하는데요. 그들은 엔지니어링에는 그저 괜찮은 수준이었지만, 다른 사람들을 성장시키고 대인 관계 기술을 사용하는 데 특히 뛰어났습니다.
- 장기적인 경력 목표 - 언젠가 임원이 되거나 자신의 회사를 만들고 싶다면, 매니저가 되는 것이 더 관련성 있는 경험을 제공할 것입니다.
- 원하는 기술 성장 - 일부 엔지니어들은 IC로 충분히 오래 일해서 지루함을 느끼고 새로운 것을 배우고 싶어 합니다. 매니저가 되면 새로운 기술을 배울 수 있습니다.
이때, 단순히 경력을 빠르게 성장시키는 가장 좋은 방법이라고 생각해서 엔지니어링 매니저가 되어서는 안 됩니다. 항상 그렇듯이, 상황에 따라 다릅니다. 과거에는 고위 직급(IC7+)에서 IC보다 매니저가 더 많았기 때문에 관리직이 경력 성장에 더 유리하다고 주장하는 사람들이 있었습니다. 하지만 2023년, 테크 업계 전반에서 일어났던 매니저 해고 이후부터는 더 이상 사실이 아닙니다. 설사 그렇다 하더라도, 두 역할 모두에서의 경력 성장은 여러분들이 어떤 상황에 놓여져있냐에 따라 다릅니다.
제가 관리직으로 전환을 고려할 때, 저의 매니저는 경력 성장에 대한 통제력이 줄어들 것이라고 경고했습니다. 그말이 맞았습니다. 저는 관리직으로 전환하면서 많은 것을 배웠고 즐겼지만, 다음 레벨에 더 가까워지지는 않았습니다. 제 조직에서는 IC로 다음 레벨을 가는 길이 훨씬 더 빠르고 명료했죠.
그럼에도 엔지니어링 매니저가 되고 싶다면, 다음과 같이 하시기 바랍니다:
- 스태프(IC6) 레벨로 승진하세요 - 대부분의 회사에서는 그 이전에는 전환을 허용하지 않습니다(예외는 있습니다).
- 시도해 보고 준비되었음을 보여주세요 - 인턴을 관리해 보세요. 전체 팀을 맡지 않고도 관리를 경험해 볼 수 있는 가장 좋은 방법 중 하나입니다. 또한 테크 리드 역할을 더 많이 맡아볼 수 있습니다. 이는 성과 평가를 하지 않는다는 점만 제외하면 엔지니어링 매니저와 비슷합니다.
- 매니저에게 관심을 표현하세요 - 엔지니어링 매니저 역할은 제한적입니다. 기회가 올 때 여러분이 필요한 기술을 갖추고 있고 그 역할에 관심이 있는 사람으로 매니저의 마음속에 있어야 합니다.
관리직으로 전환할 기회는 상황에 따라 다릅니다. 많은 채용이 이루어지는 성장하는 영역에서 필요에 따라 관리직 기회가 가장 많을 것입니다. 관리직을 고민하는 친구가 있다면 이 글을 공유해 보세요.
Top 1% 개발자로 거듭나는 확실한 처방전, 데브필입니다.
댓글
의견을 남겨주세요