어제 회사 Summer Party에서 동료와 승진 과정 및 조건에 대한 주제가 나와서 간단히 글을 적어보고자 한다. 지금 기준인 지금 필자가 있는 회사기준이고 모든 독일회사가 동일하지는 않다. 그리고 Staff, Principal 엔지니어에게 요구되는 덕목(?)도 요즘에 많은 고민을 하고 있고 관련된 서적도 읽고 있어서 그 책을 다 읽고 이와 비슷한 이야기를 다시 적고자 한다.
위의 그림은 일반적인 커리어 패스에 대해서 개발 패스와 매니저 패스로 나눠서 체계를 잘 적어놓았고 필자의 회사와 완벽하게 포지션 명까지는 일치하지 않지만 대략 비슷하다. 대부분 경력 10-15년차정도 되는 개발자들은 위의 그림 기준으로 시니어 소프트웨어 엔지니어가 된다. 필자의 회사에서도 시니어 소프트웨어 엔지니어는 엔니지어링 매니저가 개발 전문성과 경력이 맞으면 어느정도 승진(100% 아님)을 시켜줄 수 있다.
이제 고비는 스태프 엔지니어로 승진하려고 할 때 많은 장벽과 추가적으로 필요한 능력등에 대한 증명이 필요하다. 많은 매니저들이 이때 Visualibility를 이야기한다. 한국 대기업 같은 경우 매년 평가와 연차가 맞으면 승진 대상이 되지만 해외에 있는 많은 기업들은 우선 자기의 직속 매니저와 이야기를 하고 준비를 하려고 한다. 여기서 많이들 Visualibility 이야기를 한다. 왜냐하면 그만큼 경쟁이 치열하기 때문이다. 그리고 Director 이상 급의 매니저들로 부터 정해진 TO 안에서 최종 승인을 받아서 이루어지기 때문이다.
그러면 어떤 식으로 Visualibility 를 보여주어야 하는가.. 참 어렵고 딱히 정해진 답은 없다. 쉽게 이야기하면 나를, 그리고 내가하는 일들에 대해서 우리팀 내부만이 아닌 여러 관련 팀 개발자, 다른 팀 매니저, Director 이상급의 매니저가 알게 하는 것이다. 하루 이틀 사이에 되는 것도 아니고 꾸준히 성과를 보여주는 것도 필요하다. 개발만 잘하면 되는것도 아니다. 개발과 나의 성과를 포장하고 알리는 과정도 정말 중요하다. 그래서 개발자로써의 능력에 추가적으로 Personal Skill (발표, 의사소통, 문제해결, 협업 등)이 스태프 엔지니어 이상에서는 요구된다. 물론 필자도 모든 것을 완벽하게 잘 하지 않고 엄청 많이 부족하다.
최근에 Amazon에서 HR 담당자에게 받은 메시지 중에 하나이다. 물론 여러 개발자들에게 뿌려 큰 의미를 두진 않지만 프린스플 엔지니어에 대한 것을 이야기하고 있어서 붙여 본다.
I support hiring for Amazon’s Principal Engineering Community – our senior-most technical contributors. The Community is still really quite small (~2% of our engineering population). Principals here provide technical leadership, establish technical standards, and drive Amazon’s overall technical architecture, engineering practices, and methodologies across multiple teams.
그만큼 프린스플 엔지니어는 수가 적고 뚫기 힘든 관문이고 리더십 능력도 갖춰야야한다는 이야기이다. 한국에서 생각하면 평가 권한이 없으면 다른 매니저 밑에 있는 개발자를 움직이기 힘들다고 생각하지만 그럼에도 불구하고 리더십 능력을 가지고 일을 이끌어 내야한다. 매니저에 관련된 책은 없지만 스태프 엔지니어이상에 대해 기대하고 이야기해주는 책이 없었고 최근에 발견해서 열심히 읽고 있다. 내용도 만족스럽다. 여기서 자세히 이야기하지 않고 다음 글에 책에 대한 내용을 이야기할 예정이다.
다시 돌아와서 개발자의 능력은 시니어 엔지니어가 되면 어느 정도 스스로 자기에 주어진 업무를 하고 주니어 개발자를 리딩하면서 업무를 진행할 수 있을 것으로 많이들 기대한다. 스태프 엔지니어 이상으로 가기 위해서는 조금 더 많은 팀과 시니어 개발자, 매니저에 영향력을 줄 수 있는 리더십을 갖추기 위해서 노력하고 승진을 하기위해서 본인이 한 것에 대한 Visualibility를 보여주어야 한다고 개인적으로도 생각한다. 물론 반대의 의견을 가지고 있는 개발자들도 많이 있다. 그건 매니저의 역할일 수 도 있다면서.. 하지만 지금까지 필자가 겪어온 실제는 매니저가 도와주면 고마운것이고 본인 스스로가 직접 많이 어필해야 한다는 것이다.
필자도 여전히 Visualibility 를 보여주는 방법, 개발 외 리더십 및 개인 역량 향상에 대해 많은 고민을 하고 있고 향상시키려고 계속 노력하고 있다. 어찌보면 정치를 한다 고깝게 볼 수도 있지만 스스로의 능력을 증명하고 모두는 아니지만 대다수의 동료들에게 신뢰를 쌓아야 하는게 중요하다고 생각한다. 본인의 지위를 가지고 영향력을 행사할 수도 있지만 신뢰 기반의 영향력이 더 중요할 수도 있다고 생각한다.
'Development' 카테고리의 다른 글
M1 IPAD Pro에서 터미널(shell + git) 개발 환경 구축하기 (0) | 2023.10.10 |
---|---|
The Linux Graphics Stack (0) | 2023.09.24 |
소프트웨어 개발에서 Automation (자동화)에 대한 허와 실 (0) | 2023.09.08 |
jfrog (artifactory) CLI 도구 사용 (0) | 2023.08.29 |
QT LTS Commercial 버전과 QT LTS LGPL 버전 (0) | 2023.08.28 |