16. 과장도 팀장도 아닌 엔지니어입니다.
상하관계가 아닌 전문적 역할이 반영된 직함
[6. "갑"이 없는 조직]에서 살펴본 바와 같이 Rank-driven 조직에서는 Rank가 높은 사람이 지시를 내리고 Rank가 낮은 사람이 직무 지시를 수행하고 보고서를 올린다. 그러한 조직에서는 누가 Rank가 높은 지를 확실히 해야 직무 지시 체계에서 혼란을 막을 수 있다. 대부분 해야 할 일이 명확한 제조업 위주의 Fast-follower 기업에는 다양한 생각과 의견이 필요하지 않고 여러 사람의 의견이 다를 때 누구 말을 들어야 하는지가 명확해야 빠르게 의사결정을 할 수 있다.
그렇기 때문에 Rank-driven 조직에서는 직급을 통해 누가 결정권을 갖는지를 확실히 각인시킨다. 과장님이 무슨 말을 해도 부장님이 아니라고 하면 그만이고, 부장님이 어떤 주장을 해도 사장님의 결정에 따라 모든 것이 바뀔 수밖에 없다. 하나하나의 사안에서 누구의 의견이 옳은 지가 중요한 것이 아니다. 어떻게 하면 빠르게 움직일 수 있는지가 더 중요하고 의사결정에 들어가는 시간을 최소화하는 것이 중요하다. 그리고 Rank가 가장 높은 사람의 의중을 누가 더 많이 파악하고 있는지가 중요하다.
반면 Role-driven 조직에서는 각 역할을 맡은 사람이 각 전문분야의 결정권을 갖는다. CEO는 경영에 대한 결정을 내리고, 디자이너는 디자인 결정을 내리고, 엔지니어는 엔지니어링 결정을 내린다. 엔지니어의 결정과 CEO의 생각이 다를 경우 CEO가 자신의 의견을 개진할 수는 있지만, 그 의견을 듣고 엔지니어링 결정을 내리는 것은 엔지니어의 역할이다. 반면 경영에 대한 결정은 엔지니어가 어떤 좋은 의견을 내어도 CEO가 최종적으로 결정한다.
Role-driven 조직은 혁신을 만들어내는 조직이다. 이러한 조직들은 가는 방향이 정해져 있지 않다. 아무도 가지 않은 길을 가는데, 어디로 가야 가장 좋은 길인지는 각 전문가의 의견을 종합해서 판단하는 수밖에 없다. 의사결정에 들어가는 시간은 혁신을 하려는 기업에게는 가장 가치 있는 시간이다. 미션을 이루기 위해 무엇을 만들어야 하는지 고민하는 그 시간 자체가 혁신을 만드는 시간이다.
엔지니어 레벨과 승진하는 방법
구글, 페이스북, 에어비앤비 등 실리콘밸리의 IT기업들은 대부분 비슷한 엔지니어 레벨 시스템 가지고 있다. 대부분 Entry Level로 대학을 졸업한 신입에 해당하는 레벨 3에서부터 시작한다. 레벨 4는 경력 3-4년 정도나 박사학위자 정도에 해당하고 레벨 5는 시니어 엔지니어로 가장 중추적인 역할을 하는 엔지니어이다.
레벨 6부터는 스태프 엔지니어라고 부른다. 특별한 재능이 있거나 경험이 많은 엔지니어이다. 평생 레벨 6 엔지니어가 되지 않고 은퇴를 할 수도 있다. 레벨 7, 8 엔지니어는 매우 적다. 상위 1% 정도에 해당하는 높은 레벨의 엔지니어이며, 8 레벨 엔지니어는 매우 드물다.
5 레벨 엔지니어는 0 레벨 엔지니어링 매니저로 전환할 수 있다. 0 레벨 매니저는 상황에 따라 다르겠지만 보통 5명 이하의 엔지니어들을 매니지한다. 그들의 역할은 엔지니어들과 1:1 미팅을 통해 각 엔지니어들의 문제점들을 해결해주고, 인사 평가를 통해 각 엔지니어들에게 피드백을 제공하는 것이다.
레벨 6 엔지니어는 1 레벨 엔지니어링 매니저로 전환할 수 있다. 1 레벨 매니저는 작은 스타트업을 운영하는 것과 비슷하다. 총 20명 정도 되는 엔지니어들을 2-3개 팀 정도로 나누어 운영한다. 새로운 프로젝트들에 대한 고민을 하기 시작하는 레벨이다.
2 레벨 매니저는 회사의 미션에 맞추어 100명 정도 되는 팀의 조직을 정하고 팀의 미션을 만들어간다. 2 레벨 엔지니어 다음에 오는 8 레벨 엔지니어에 해당하는 D1, 즉 1 레벨 디렉터는 회사 전체의 엔지니어링/프로덕트의 방향의 결정에 참여하는 역할이다.
각 레벨에서 다음 레벨로 승진하는 방법은 간단하다. 다음 레벨에 해당하는 성과를 6개월에서 1년 정도 보여주면 된다. 즉, 현재 4 레벨 엔지니어 중에 이미 5 레벨 엔지니어로 활동을 하는 사람을 5 레벨 엔지니어로 인정해 준다. 계속 4 레벨 엔지니어의 책무만을 하고 있으면 계속 4 레벨 엔지니어에 머물게 된다. 물론 은퇴할 때까지 4 레벨에 머물러도 누구도 이상하거나 한심하게 보지 않는다.
매니저로 전환하는 방법도 마찬가지이다. 엔지니어 역할을 하면서도 매니저 역할을 반년 이상 하면 매니저로 타이틀을 전환할 수 있다. “오늘부터 매니저니까 어제와는 다른 매니저 역할을 하세요"라는 경우는 없다. 이미 하고 있는 역할에 맞도록 타이틀(직함)을 조정하는 것이 승진 또는 매니저로의 역할 변경이다.
레벨은 역량을 나타낼 뿐 권력이 아니다
Role-driven 조직에서 엔지니어링 레벨은 엔지니어 전문분야의 역량을 뜻하고, 그 역량만큼 연봉을 받는다. 각 레벨에 따라 다르게 연봉이 책정되며, 연차에 따라 연봉이 오르지는 않는다. 그리고 레벨이 결정권의 크기와 비례하지는 않는다.
Rank-driven 조직에서는 레벨, 즉 직급에 따라 결정권을 갖는다. 우리 팀 과장의 의견보다 옆팀 부장의 의견이 더 중요하다. 사장의 의견은 누구의 의견보다 더 중요하다. 엔지니어링 팀장이 아무리 옳은 결정이라고 생각해도 사장의 의견이 더 존중된다.
이러한 레벨에 따른 결정권의 차이에는 투명성의 결여도 큰 역할을 한다. 기본적으로 Rank-driven조직은 윗사람이 정보를 독점하고 아랫사람들에게는 필요한 정보만 제공한다. 엔지니어링 팀장이 기술적으로 MySQL DB가 가장 적합하다고 결정해도 CEO가 Oracle과 비지니스 계약을 맺었다면 엔지니어링 팀장의 결정은 무의미해진다. 그래서 정보를 독점하고 있는 윗사람은 “너네가 뭘 안다고 결정을 내려”라는 말을 할 수 있다.
반면 Role-driven 조직에서는 레벨보다 직무(Role)가 결정권의 배분에 더 중요한 요소이다. 3 레벨 엔지니어의 결정을 CEO가 마음에 안 들면 엔지니어의 결정 바꿀 수 있도록 논리적으로 설득할 수 있어야 한다. 설득이 안 되면 당연히 엔지니어의 결정이 엔지니어의 영역에서 우선시 된다. 스마트폰을 만드는 회사에서 디자이너가 한 디자인이 CEO 마음에 안 들면 Rank-driven조직에서는 CEO 마음에 맞게 다시 만들어야 하지만 Role-driven 조직에서는 CEO의 개인 의견을 받아들이는 것은 디자이너의 결정이다.
각 역할의 전문성에 기반한 결정을 하도록 하기 위해서는 회사의 모든 정보를 최대한 공유하는 것이 필수적이다. CEO가 Oracle과 비지니스 딜을 맺었다면, 그 정보를 최대한 빨리 회사 내에 전파하여 각 엔지니어가 다른 DB를 가지고 고민하는 시간을 줄여야 한다. 그러한 자신의 전문 분야뿐만 아니라 회사 내의 종합적인 정보에 기반하여 결정을 내리는 것이 Role-driven 조직의 직원의 책무이기도 하다.
각 역할 조직에 따라 결정권이 주어지고 각 역할 조직 안에서는 레벨보다 전문성이나 논리와 데이터가 의사 결정에 더 중요하기 때문에 전 회사에 적용되는 레벨 시스템은 필요도 없고 어색하다. 3 레벨 엔지니어와 1 레벨 엔지니어링 매니저와 5 레벨 디자이너가 있을 때 서로 누가 높은지 낮은 지를 따져서 의사 결정을 대리는 일은 없다. 모두 다 정보를 공유하고 공유된 정보에 기반하여 토의 끝에 의사 결정을 내린다.
각자의 전문성과 역량에 맞게 레벨이 정해지기 때문에 회사에 다닌 연차와 레벨은 전혀 상관이 없다. 나이, 경력과 대부분 비례하지만 직접적인 상관은 없다. 실제로 50대 엔지니어가 4 레벨 엔지니어인 경우도 많고 30대 엔지니어가 7 레벨 엔지니어가 되기도 한다.
5 레벨 이상의 엔지니어는 엔지니어링 매니저가 될 수 있지만 매니저가 엔지니어보다 더 높은 사람은 아니다. 그냥 역할이 매니저로 바뀌는 것뿐이다. 엔지니어링 의사 결정은 여전히 엔지니어들이 하고 매니저들은 각 엔지니어들이 조화롭게 자신의 역량을 최대한 발휘할 수 있도록 돕는 역할을 한다.
매니저는 기술적인 자문을 할 수도 있지만 본업이 엔지니어링 의사 결정을 하는 것이 아니다. 각 팀의 방향을 회사 전체의 미션과 맞추고, 각 엔지니어들에게 팀의 방향을 정확히 소통하고, 피드백을 통해 각 엔지니어의 성장을 돕는 역할이다. 리더십과 사람에 대한 이해가 매우 중요한 자리이다.
매니저가 된다고 해서 결정권이나 연봉 등이 더 많아지는 것이 아니기 때문에 리더십이나 팀원 간의 조화에 관심이 없는 엔지니어들은 매니저가 될 필요도 없고 고려도 하지 않는다. 리더십에 대한 관심이 없거나 이해가 부족하지만 엔지니어로서 뛰어난 팀 멤버를 억지로 리더의 자리에 앉히는 것은 개인에게도 회사에게도 비극이다.
각 레벨의 상세 역할
Software Engineer Levels
L3 (Junior Engineer)
기술 (Tech Ability): 자신이 일하는 시스템에 대해 이해하고 있음
영향력 (Impact): 주어지는 일을 해결할 수 있음
범위 (Scope): 조금만 가이드를 주면 버그를 고치거나 작은 사이즈의 일들을 할 수 있음
자율성 (Autonomy): 매니저나 테크 리드가 정해주는 일을 주로 함
성장에 기여 (Enrichment): 기술 면접의 면접관으로 참여함
4 레벨 엔지니어로 성장하기 위해 4 레벨 엔지니어의 역할을 일부 수행함.
L4
기술: 좋은 기술적 판단력을 가지고 결정을 내림. 동료들에게 의미 있는 코드 리뷰를 제공할 수 있음.
영향력: 팀에 목표에 비추어 자신이 기여할 수 있는 부분을 스스로 찾아 기여한다.
범위: 작은 프로젝트를 맡거나 프로젝트의 일부를 맡을 수 있다.
자율성: 매니저나 테크 리드의 약간의 도움만으로 일을 성취함
성장에 기여: 신입 직원들에게 멘토가 되고 인턴 호스트가 되어 인턴들을 도와줌.
5 레벨 엔지니어로 성장하기 위해 5 레벨 엔지니어의 역할을 일부 수행함.
L5 (Senior Engineer)
기술: 큰 기술적 문제를 가장 좋은 방법으로 해결할 수 있음
영향력: 다른 사람들이 높은 생산성을 유지할 수 있도록 도와주며 팀의 목표에 비추어 자신이 할 프로젝트를 만들어서 할 수 있음
범위: 하나의 시스템이나 프로젝트 전체를 맡아서 관리할 수 있음
자율성: 혼자서 모든 업무를 할 수 있음
성장에 기여: 다른 팀들과 좋은 관계를 쌓으며 팀 내 리더 역할을 함. 엔지니어들의 멘토로 활동하며 면접 과정에 깊이 관여하여 새로운 면접 문제나 유형을 만들기도 함.
5 레벨 엔지니어는 엔지니어의 중추적 역할을 하며 한다. 3 레벨 엔지니어와 4 레벨 엔지니어는 5 레벨 엔지니어로 성장하기 위해 노력하도록 명시되어 있다. 그러나 5 레벨부터는 6 레벨 엔지니어로 성장하기 위해 노력하도록 명시되어 있지 않다. 6 레벨부터는 특별한 재능과 노력이 필요하다. 엔지니어링보다 팀 관리에 뛰어난 리더는 매니저 트랙으로 갈 수도 있다.
L6 (Staff Engineer)
기술: 특별한 기술적 능력을 소유하고 있음. 뛰어난 문제 해결 능력.
영향력: 영향력이 큰 프로젝트를 만들어서 할 수 있음
범위: 해결 방법이 아직 알려지지 않은 어려운 프로젝트를 맡아서 할 수 있음
자율성: 새로운 프로젝트를 제안하고 리드할 수 있음
성장에 기여: 경험이 많은 엔지니어의 멘토가 되며 팀 간의 갈등을 해결할 수 있음.
L7 (Principal Engineer)
기술: 여러 엔지니어링 분야의 전문가
영향력: 다른 엔지니어와 팀들의 생산성을 높여줄 프로젝트를 제안함
범위: 큰 프로젝트를 이끌 수 있는 역량이 이미 증명되어 있음
자율성: 자신이 직간접적으로 기여하는 큰 프로젝트들을 제안하고 리드할 수 있음.
성장에 기여: 모든 엔지니어의 존경을 받으며 여러 팀의 방향을 정함
L8
기술: 소프트웨어 산업 전반의 전문가
영향력: 회사 전체에 영향을 미침
범위: 회사 전체의 혁신을 이끄는 프로젝트를 수행
자율성: 회사 전체의 엔지니어링의 방향을 바꾸는 프로젝트를 제안하고 리드함
성장에 기여: 다른 회사의 엔지니어들에게도 존경을 받는 엔지니어
Software Engineering Manager Levels
M0
L5 엔지니어의 기술력을 갖춘 사람은 M0 매니저로 전환할 수 있다. M1부터가 제대로 된 매니저로 인정을 받으며 M0는 매니저 수습생 정도로 볼 수 있다.
인적 자원 관리 (People Development): 각 엔지니어의 커리어 개발을 돕고 모든 팀원이 기술적 멘토를 가질 수 있도록 한다. 각 엔지니어에게 직접적이고 행동할 수 있는 피드백을 제공하여 성장을 돕는다. 회사에 각 엔지니어에게 기대하는 바를 정확히 소통한다. 팀 내 모든 엔지니어들과 1:1 미팅을 최소 2주에 한번씩 갖는다.
팀 관리 (Team Health & Development): 새로운 엔지니어들을 뽑고, 건강하고 다양성이 있는 팀을 만든다. 팀원 간의 갈등을 해결한다.
전략 수립 (Strategy & Impact): 이미 수립된 전략과 방향을 소통하고 수행한다. 엔지니어들이 회사와 팀의 방향을 정하는 과정에 적극적으로 참여하도록 돕는다. 팀이 하는 일에 깊은 기술적 이해도를 갖추고 필요할 경우 기술적인 조언을 한다.
영향력과 소통 (Influence & Communication): 팀의 존재가치를 명확히 하고 회사 전체와 조화를 이루도록 한다. 팀 내 각 엔지니어의 의사 결정이 조화를 이루도록 한다. 회사 내의 정보를 엔지니어들에게 빠르고 투명하게 소통한다.
M1
인적 자원 관리: 각 엔지니어들이 성장할 수 있도록 멘토링과 피드백을 제공한다. 뛰어난 커리어 코치로서의 역량을 가지고 있다. 자신이 맡은 팀 외의 엔지니어들에게도 도움을 준다.
팀 관리: 생산성이 높고 효율이 높은 팀을 관리한다. 경험 많은 엔지니어들을 팀에 데려온다. 자신과 팀원들의 성공을 위해 무엇을 해야 할지를 계획한다.
전략 수립: 새로운 방향과 아이디어들을 제안하고 수행한다. 6개월 정도를 앞서 내다보며 팀의 방향을 계획한다. 팀 내 엔지니어링 활동이 가장 좋은 방법으로 이루어지도록 (Best Practice) 점검하고 멘토링 한다.
영향력: 자신의 팀과 주변 팀에 좋은 영향력을 가지며 엔지니어 외의 직군의 사람들과도 좋은 관계를 형성한다.
M2
인적 자원 관리: 시니어 엔지니어와 매니저들을 관리하고 멘토링 하며 성장을 돕는다.
팀 관리: 팀 내 인재 구성의 다양성과 밸런스를 맞춘다. 엔지니어링 팀 전체를 효율적으로 성장시킬 수 있는 패턴을 만든다. (Post-mortem, Performance Feedback 등)
전략 수립: 1년 앞을 내다보며 회사의 성장에 기여할 수 있는 기회를 찾는다. 새 팀을 만들고 큰 팀을 리드한다.
영향력: 몇 개의 팀으로 이루어진 큰 조직에 영향력을 가지며 다양한 팀의 소통을 돕는다.
M3 (Director)
인적 자원 관리: 조직의 모든 사람들이 성장할 수 있도록 시스템을 갖춘다. 각 팀의 리더들이 회사를 떠나지 않도록 관리하며 새로운 리더들을 팀에 데려온다. 리더들의 멘토가 된다.
팀 관리: 회사의 발전과 성장에 기여할 수 있는 조직 내 문화를 만든다. 조직 내 모든 팀이 좋은 건전하고 문화를 갖고 있도록 한다.
전략 수립: 회사 전체의 성공을 책임진다. 회사의 미션에 맞는 방향을 수립한다.
영향력: CEO를 포함 회사 전체의 의사 결정에 영향을 미친다.
개인적으로 매니저의 매니저의 매니저인 디렉터 급의 리더에게 면담을 요청해서 팀 내 문화와 다양성에 대해, 그리고 내 개인적 커리어 성장에 대해 물었을 때 적극적으로 시간을 내어 면담을 하는 모습이 인상적이었다. M3의 역할을 읽어보니 이제 왜 그 사람이 그렇게 적극적으로 임했는지 이해가 간다. 디렉터의 임무는 전체 조직의 다양성과 문화를 개선하는 것이고 각 엔지니어들의 성장을 돕는 것이기에 내 면담 요청은 불만에 대한 소원수리가 아닌 오히려 그 디렉터의 일을 돕는 것으로 인식되었다.
생산의 최대화를 통한 시장 점유 vs. 전문성의 최대화를 통한 혁신
혁신을 만들어내는 Innovator와 혁신을 확산시키는 Fast Follower. 그 두 조직은 매우 다른 목표로, 다른 조직의 형태로, 다른 방식으로 움직인다. 각 직원의 전문성을 살려야 하는 Innovator 기업은 Role-driven 조직을 만들어서 각 사람의 전문성과 창의성을 최대한 끌어낸다. 그들에게 중요한 것은 얼마나 빨리 만드느냐가 아니라 미션을 이루기 위해 무엇을 만드느냐이다. 전문성과 창의성에 기반하여 길고 긴 의사 결정 과정을 통해 다음 나아갈 방향을 정한다. 그렇기 때문에 빠른 의사결정이 목표가 아니다.
반면 Fast Follower들은 치열한 경쟁에 직면해 있다. 느린 의사결정은 회사에 큰 타격을 입힐 수 있다. 이미 다른 기업들이 간 길들 중 가장 좋은 길을 빠르게 선택하여 가면 된다. 그래서 가장 윗사람에게 끊임없이 잘 정리된 보고서가 올라가야 하며 다른 기업이 간 길을 분석한 보고서를 토대로 가장 Rank가 높은 사람 한 사람이 결정하는 것이 가장 효율적이다. 그들에게 중요한 것은 “어떤 새로운 것을 만들어내느냐”보다 “얼마나 빨리 잘 만들어서 시장을 선점하느냐”이다. 그들에게도 미래 시장을 위한 혁신은 필요하다. 그러한 혁신이 현재의 조직구조와는 맞지 않기 때문에 Rank-driven의 Fast follower조직들은 별도의 부서를 마련하여 혁신을 맡기곤 한다. 물론 결정권이 위에 있기 때문에 한두 개의 혁신부서를 만든다고 해서 혁신이 일어나는 것은 매우 어려운 일이다.
Fast Follower 기업들은 빠른 결정을 위해서 누가 위에 있어서 결정권을 더 많이 가진 사람인지를 확실히 할 필요가 있다. 과장님과 부장님의 의견이 부딪히면 차근차근 설득시키고 의견 충돌을 해결해 나가는 것보다 부장님의 말을 듣는 것이 훨씬 빠르다. 그래서 직급이 담긴 직함을 통해 누가 결정권자인지를 확실히 각인시킨다. Rank-driven 조직에서의 직급은 결정권의 크기와 근무 경력과 비례한다.
Innovator 기업들은 전문성에 따라 결정권이 주어지기 때문에 각 사람이 어떤 일을 하는지가 중요하다. 그래서 직함이 엔지니어, 디자이너, CEO, 엔지니어링 매니저 등 하는 역할을 나타낸다. 레벨은 서로 모르는 경우도 많고 Rank-driven 조직에서만큼 중요하지도 않다. Role-driven 조직에서의 레벨은 업무 능력과 연봉과 비례하지만 직무를 넘나드는 결정권의 크기와 근무 경력과는 비례하지 않는다.
Role-driven 조직에서의 매니저들의 역할은 회사의 미션을 수행하기 위한 크고 작은 프로젝트들이 충돌 없이 수행될 수 있도록 지속적으로 커뮤니케이션하고 팀의 역량을 키워나가는 일이라고 할 수 있다. 능숙한 매니저가 이끄는 팀일수록 반복되는 업무보다 창의적인 일에 더 많은 시간을 쏟을 수 있도록 한다. 결과적으로, 팀원들의 역량이 고르게 발전하게 되어 회사가 미션을 이루는 데 더 빨리 다다를 수 있도록 한다.
글: Will. 소프트웨어 엔지니어. 기업 문화와 조직에 관심이 많음.
그림: Chili. 디자이너. 생각을 그림으로 요약하는데 관심이 많음.
Project Group 실리콘밸리를 그리다 / 페이스북
