GN⁺: 직원 성과 지표에 대해 마음이 바뀌었습니다

• 과거(2004-2006년경)에는 직원들의 커밋 수, 댓글 수 등으로 "업무 산출량"을 측정하는 도구를 만들었음
• 최근 "직원 지표" 관련 제품에 관여해 달라는 제안을 받은 것을 계기로 과거 내가 했던 일이 잘못되었다고 판단하고 더 이상 추천하지 않기로 결심함

입장 변화의 이유

• 직원들의 업무 성과와 효율성을 파악하는 것은 관리자의 고유 업무라는 점을 깨달음
• 관리자가 이를 제대로 못한다면 그들 스스로가 무능한 것이며, 이는 그들의 상급 관리자가 책임져야 할 문제
• 직원 관리는 관리자 본연의 역할이며, 이를 위해 별도의 도구나 타인의 도움은 필요하지 않음

새로운 입장

• 그런 종류의 도구를 만들거나 돕지 말 것
• 동료들이 기본적인 "서비스 청결(service hygiene)" 이슈를 해결하는지 테스트하지 말 것
• 성과 리뷰에서 실질적(substantive)인 말을 하지 말 것
• 이런 일들은 당신이 생각하는 것처럼 상황을 개선하지 못하고 오히려 삶을 더 힘들게 만듦
• "동료 리뷰가 실제로 상황을 개선한다"는 것은 기술 업계의 큰 착각임

이기적인 관점에서의 조언

• 20년 전에 만든 도구들은 누가 태만한지 보여주는 것이 아니라, 당시 Rackspace의 관리자들이 코앞에서 일어나는 일도 모른다는 것을 보여줌
• 이러한 사실을 지적하는 것은 불필요한 적을 만들 수 있는 위험한 행동임
• 동료의 업무 태만을 지적하고자 하는 충동을 자제하는 것이 현명함. 그렇게 하면 오히려 자신에게 해로울 뿐

GN⁺의 의견

• 개발자 성과 측정 도구들은 종종 정량적 지표에만 집중하여 코드 품질, 협업 능력, 문제 해결 능력과 같은 중요한 질적 요소들을 간과하는 경향이 있음
• 이러한 도구들은 개발팀 내 불필요한 경쟁과 긴장을 조성할 수 있으며, 이는 장기적으로 팀 문화와 생산성에 부정적인 영향을 미칠 수 있음
• 최근의 DevOps 문화와 애자일 방법론은 팀워크와 협력을 강조하는데, 이는 개인별 성과 측정보다 팀 전체의 성과와 학습을 중시하는 방향으로 발전하고 있음

[neo]

Hacker News 의견

• 관리자는 직원의 성과를 파악하고 그들이 효과적으로 일하는지 확인할 책임이 있음. 자동화된 대시보드는 관리자의 호기심을 줄이고, 직원들을 대시보드 최적화에만 집중하게 만듦. 이는 창의적인 시스템 설계에 부정적인 영향을 미침.

• 대규모 엔지니어링 조직에서 내부 플랫폼을 작업하며 팀 수준 이상의 세부 데이터를 노출하지 않기로 결정했음. 개인별 성과 지표는 오용될 가능성이 높고, 플랫폼에 대한 신뢰를 손상시킬 수 있음.

• TV 쇼 "Suits"의 한 장면에서 성과 지표가 실제로 중요한 기여를 간과할 수 있음을 보여줌. 다른 사람을 도운 직원이 성과 지표에서 낮은 순위를 받았음.

• 코드 라인 수로 성과를 측정하는 것은 무의미함. 복잡성을 줄이고 고객 요구를 더 잘 충족시키는 것이 목표임.

• 관리자가 성과 지표를 올바르게 이해하거나 적용할 것이라는 신뢰가 없음. 데이터보다 피드백이 우선시되는 경우가 많음.

• 관리자는 양적 세부사항보다 질적 세부사항에 더 관심을 가져야 함. 성과 지표는 큰 그림을 보는 데 유용하지만, 팀의 행복도나 갈등은 보여주지 않음.

• 익명 설문조사를 통해 프로젝트 진행 상황을 파악하는 것이 더 정확한 답변을 얻을 수 있음. 익명성이 중요하며, 회사는 종종 정확한 답변보다 듣고 싶은 답변을 원함.

• 대규모 회사의 엔지니어링 매니저로서 성과 지표는 기존 인식을 보완하는 데 사용되지만, 인식을 완전히 바꾸지는 않음.

• 경영진의 성과를 측정할 수 있다면, 직원들도 자신의 성과를 측정하는 것에 대해 불평하지 않을 것임. 공정한 평가가 필요함.

• 자동화된 도구는 모든 것을 보여주지 않음. 좋은 리더는 자동화 도구로는 보이지 않는 기여를 인식할 수 있어야 함.