레벨제 도입 전 답해야 할 질문 세 가지
레벨제를 검토하신다면 제도의 형태보다 아래 세 가지를 먼저 정리하셔야 합니다.
네이버의 2020년 사례가 질문들의 중요성을 잘 보여줍니다.
첫째, 레벨을 올리는 기준이 명확한가요?
2020년 네이버 직원들의 반발에서 가장 많이 나온 이야기입니다.
당시 사내 익명게시판에는 "회사 측은 레벨을 올리려면 기술공유 문서 작성, 코딩 작업량, 기술면접, 동료 평가 등이 필요하다고 한다"며 "고등학교 내신관리도 아니고 대놓고 스펙 쌓기를 요구하는 것 같다"는 반응이 올라왔습니다. "성장의 방향성은 모르겠고 그냥 열심히 해서 레벨 올리라는 식"이라는 지적도 있었습니다.
여기서 중요한 점은 레벨 기준이 곧 조직의 가치 선언이 된다는 사실입니다.
문서 작성량을 평가하면 문서를 많이 쓰는 사람이 올라가고, 코드 라인 수를 보면 코드를 많이 짜는 사람이 올라갑니다. 기준이 조직이 진짜 원하는 성장과 일치하지 않으면, 구성원은 성장이 아니라 점수를 관리하게 됩니다.
둘째, 눈에 안 띄는 업무는 누가 맡나요?
레벨제의 구조적 딜레마입니다. 평가 가능한 업무에 사람이 몰리면, 평가되지 않지만 조직에 필요한 일은 공백이 생깁니다.
레거시 시스템 정리, 신입 온보딩 지원, 팀 내 갈등 조정, 다른 팀 업무 지원 같은 일들은 성과로 잡히기 어렵습니다. 그런데 해당 업무가 사라지면 조직은 서서히 무너집니다.
하여, 레벨제를 도입하려면 보이지 않는 기여를 어떻게 평가에 반영할 것인지가 함께 설계돼야 합니다. 그렇지 않으면 개인 성과는 올라가는데 조직 전체 성과는 떨어지는 상황이 만들어집니다.
셋째, 레벨이 결국 직급이 되지는 않을까요?
비공개 원칙에도 불구하고 현실에서는 서로의 레벨을 대략 알게 됩니다. 그리고 그 순간 레벨제는 이름만 바뀐 직급제가 됩니다.
구글의 전 최고인사책임자 라즐로 복은 저서에서 관련 경험을 언급했습니다.
감독자 직급을 '디렉터 엔지니어링'과 '엔지니어링 디렉터'로 나눴더니, 직원들이 더 높은 등급으로 여겨지는 쪽에 집착하는 현상이 나타났고, 결국 두 직급을 '감독자'로 통일했다는 내용입니다.
레벨제를 도입하면서 위계를 없애려 했는데, 오히려 더 정교한 위계를 만드는 결과가 될 수 있습니다. 해당 리스크를 어떻게 관리할 것인지가 도입 성패를 가릅니다
