Microsoft에서 누가 승진하지?
소프트웨어 개발자로서 경험
난 승진이 하고 싶었다. 내 일에 대한 확실한 인정은 승진을 통해서 이루어진다고 생각했기 때문이다. 4년 전 현재 팀에서 인턴쉽을 끝내고 정직원으로 일을 시작했다. 그때 생각했던 시나리오가 있었다. 1년 혹은 1년 반 뒤에 첫 승진을 하고 (level 60 -> 61), 그다음 1년 뒤에 승진 (level 61 -> 62), 그다음 1년 혹은 1년 반 뒤에 승진 (level 62 -> 63). 만약 마지막 1년에 승진할 기미가 보이지 않는다면 다른 회사로 이직을 할 계획이었다.
마이크로스프트는 각 밴드마다 두 레벨이 있다. Software Development Engineer (이하, SDE)는 59-60, SDE II는 61-62, Senior SDE는 63-64, Principal SDE는 65-67, 그리고 Partner는 68+. 학부를 졸업하고 들어오면 보통 59 (SDE)로 시작해서 SDE II 가 되려면 2번의 승진이 필요하다. 평균 1.5년에 한 번씩 승진을 한다면 긍정적인 성장 곡선을 걷고 있다고 들었다. 해당 밴드 안에서는 승진이 쉬운 편이고, cross-band (e.g., SDE -> SDE II or SDE II -> Senior SDE)는 조금 더 시간이 걸리는 경우가 있다. 큰 회사이므로 어느 조직에 속하느냐에 따라 완전 다른 회사처럼 다르기도 하다. 나는 석사를 졸업하고 와서 60으로 시작했다.
지난 글에서 언급한 것처럼 처음 1년은 열심히 일했다. 새로운 것을 배운다는 것이 즐겁기도 했고 인정을 받고 싶었다. 그리고 실제로 많은 사람들이 쓰는 제품에 기여한다는 것에 마냥 기뻤다. 지금 돌이켜 보면 이때의 성실함은 나에게 많은 기회를 가져다주었다. 처음 팀에서 일을 시작하는 1년 동안 나에 대한 팀원들의 평가가 이뤄지기 때문이다.
처음에 맡은 프로젝트를 잘하면, 매니저가 다음에 더 중요하고 임팩트가 더 큰 프로젝트를 맡기고, 그걸 더 잘하면 다음에 더 중요한 프로젝트를 맡기는 선순환이 반복된다. 이 선순환에 들어서면 당연히 다음 인사 평가 때에도 좋은 결과를 받는다. 너무나 당연한 이야기 같은데 나의 매니저가 이야기해 주기 전까지는 대체 어떻게 해야 좀 더 visibility가 높은 프로젝트에서 일할 수 있는지 몰랐다.
열심히 일하는 건 중요하지 않다. 프로젝트를 성공으로 이끄는 것이 중요하다. 일을 시작한 지 얼마 안 된 개발자라면 기존의 어떤 기술들을 이용할 수 있는지 모르니 전부 다 만들기 시작할 것이다. 하지만 만약 경험이 있는 개발자라면 회사 내에 어떤 기술들을 재사용할지 혹은 변경해서 개발 시간을 단축할 수 있을지 고민해볼 것이다. 후자가 더 적은 노력으로 프로젝트를 완성시킬 수 있을 것이고, 전자가 더 많은 노력을 쏟았을 것이다.
좋은 매니저를 만났다면 어떤 재사용 가능한 부품들이 있는지 적극적으로 알려줄 것이다. 물론 그 조언을 듣고 안 듣고는 본인이 정하는 것이다. 매니저는 여러 가지 프로젝트를 담당하고 있고 나의 프로젝트에 나만큼 깊은 고민을 할 시간이 없다. 그러므로 매니저가 프로젝트에 적절하다고 생각하는 툴들을 알려주어도, 이 범용 툴이 어떻게 작동하는지 배우는 것보다 내 프로젝트에 딱 맞는 툴을 직접 만들어서 쓰는 게 빠를 때도 있다. 이 판단은 본인의 몫이다.
처음에 이것저것 배워야 하지만 누구도 필요한 모든 지식을 나눠줄 만큼 시간이 있지도 않고 회사 내의 문서들을 완벽하지도 않다. 완벽하지 않은 문서들에 처음에는 막막하고 짜증도 났었지만, 어차피 내가 컨트롤할 수 없는 환경이므로 나중에는 받아들였다. 대신, 매니저와 팀원들에게 우리 팀에서 사용하는 플랫폼과 툴들에 대한 high-level의 설명을 듣고, 관련 문서를 찾아보고, 직접 사용해보고, 내가 생각하는 것과 다르게 작동할 땐 코드를 직접 들여다보았다. 어떻게 작동하는지 코드까지 들여다보고 나면 일반적으로 팀 내에 동료들만큼 혹은 그보다 더 나은 이해를 가지게 된다. 그리고 다음 팀원을 위해 문서를 업데이트하고 다음 팀원에게 친절히 설명해주었다. 그러면 그다음 팀원이 같은 일을 반복하여 팀내에 지식이 빠르게 퍼진다.
나의 승진에는 동료들의 평가도 (peer review) 포함되는데 얼마만큼 동료들의 요청을 도와주어야 하는지, 얼마나 옆 팀에서의 부탁을 들어주어야 하는지 불명확했었다. 내게 맡겨진 일들도 해야 하고, 동료들의 요청도 다 들어주려고 처음에는 노력했으나 금방 그건 불가능하다는 걸 깨달았다. 처음에는 어떤 일이 중요한 것인지 몰라서 매니저에게 꽤 자주 물어봤었다. 사람마다 우선순위가 다르겠지만 내가 정리한 우선순위는 내 프로젝트의 성과가 1순위, 만약 해당 프로젝트를 협업하고 있다면 그와 관련된 동료들의 요청도 같은 우선순위를 가진다. 그리고 내 프로젝트와 관련이 없는 같은 팀원들의 요청이 2순위. 그리고 만약 내가 새로운 프로젝트에 발을 들일 기회가 있다면 3순위로 일을 진행한다. 나머지는 시간이 있다면 답장을 한다. 우선순위에서 밀린 일들은 매니저와 요청자에게 알려주고 다른 사람의 도움을 요청한다. 다음 나의 승진을 위해서도 내가 맡은 일의 성과가 더 중요하고, 내 프로젝트가 성공하면 더 많은 사람들이 도움을 받을 수 있다. 내가 무언가를 잘 만들어 놓으면 누군가는 듣고 와서 가져다 쓴다. 그리고 이것이 다른 협업의 기회로 발전할 때가 많이 있었다.
만약 내가 3년 전으로 돌아간다면 처음 1년의 프로젝트의 성과에 집중할 것이고, 가능하다면 다른 사람들이 만들어놓은 툴들을 leverage하려고 노력할 것이다. 이를 해당 툴의 owner와도 좋은 관계를 만드는 기회로 삼을 것이며, 내가 무언가 쓸모있는 것을 만들었다면 다른 사람들이 가져다 쓰기 쉽게 도와줄 것이다. 기존의 문서나 시스템이 엉망이라면 불만을 가지기보다 적극적으로 개선하여 나와 다른 사람들의 삶을 편하게 만들어주려고 노력할 것이다.
