개발자 성과
무엇이 성과 일까?
성과 공유회 이후 나온 질문들을 모아 보면 다음과 같다.
Q. 서버와 클라이언트가 하는 일이 다른데 성과 비교는 어떻게 되는 걸까요?
Q. 각 OS별로 따로 하고 피드백을 서로 주는 방식을 시도해 보면 좋겠습니다.
Q. 동료는 성과라고 생각하지만, 나는 납득할 수 없는 부분에 대해서 이야기를 할 수 있어야지 개선이 있지 않을까요?
Q. 클라 서버 간 발표내용을 보고 서로 성과/평가를 납득할 수 있을까 하는 생각이 들었습니다.
Q. 객관적인 성과가 아니라 일기장을 공유한 느낌이 들었습니다.
Q. 리더의 피드백이 공개적으로 있어야 공정성이 확보되지 않을까 하는 생각이 들었습니다.
Q. 어떻게 모두에게 성과를 높은 해상도로 설명할 수 있을까, 나는 어떻게 해야 더 잘 이해할 수 있을까
무엇이 성과 일까?
성과는 우리가 하는 일에서 달성한 성공의 결과물이라고 할 수 있을 것이다.
개발자로서 우리의 일은 "개발"일 것이고, 일(개발)을 하기 위해 필요한 다른 부수적인 요소들도 포함될 것이다.
우리 조직이 일이라고 정의한 내용은 다음과 같다.
개발
코드리뷰
동료 학습 (팀 성장)
자기 학습 (성장)
발표
서비스 오너십 (조직, 회사 기여)
이 여섯 가지가 정답이라고 생각하지는 않는다. 하지만 하나의 기준 "개발"에만 포커싱을 두면 안 된다고 생각했고, 우리가 팀으로서 일하면서 이루어 내는 각각의 역할들이 포함되어야 한다고 생각한다.
우리의 일을 잘 달성하는 것이 성과라고 생각될 수 있도록 하는 게 조직장의 역할이라고 생각해서 정의했다.
역량의 따른 성과
주니어, 미들, 시니어, 스태프, 프린시플, 디스팅귀시드까지 세분화된 개발자의 커리어 패스에서 각 레벨에서 요구되는 역량과 성과는 어떤 게 있을까?
역량과 연봉이 개개인을 만족시키고 있는지는 모르겠지만. 조직은 역량과 연봉이 비례한다고 가정하고 생각한다.
즉, 연봉과 레벨이 높다는 의미는 기대되는 역할이 더 다양하고 더 클 것이라고 가정한다.
주니어
주니어의 역량 기대치는 하드 스킬로 조금은 단순하게 평가할 수 있는 것 같다.
주니어 개발자가 우리가 만들어야 하는 기능을 얼마나 빠르게 좋은 품질로 만들어 내는지에 따라서 성과를 평가할 수 있을 것이다.
"개발 역량" 하나에 집중해서 실력을 쌓아 올리면 되기 때문에 다른 레벨의 개발자보다 비교적 쉽게 인정받거나 스스로를 증명해 낼 수 있다.
미들
미들급 개발자는 개발의 실력과 함께 아웃풋의 품질을 조금 더 냉정하게 평가받는다.
주니어 개발자의 개발이 "할 수 있느냐"라면 미들 개발자는 얼마나 "잘" 할 수 있느냐로 평가받는다.
만들어낸 산출물이 확장성이 보장되고, 안전한 코드로 되어있는지 따져보게 될 것이다.
그리고 이때부터 같이 일하는 동료에 어떤 영향을 주는지도 확인해 보게 된다.
이 시기에 좋은 시니어나 리더로부터 피드백을 잘 받는 다면 빠른 성장을 보일 수 있지만, 방치되면 10년 차 주니어가 되는 것 같다.
시니어
숲을 볼 줄 아는 수준이 되면 시니어 개발자에 들어서는 것 같다.
우리가 만들어 내고 있는 프로덕트의 아키텍처를 중심을 잡아줄 수 있어야 한고, 구성원들의 수준을 이해하고 빠르게 해야 하는 과제, 성장 과제들을 세분화해서 적절히 분배할 수 있는 능력을 갖고 있어야 한다.
그리고 이 시기부터 소속 조직뿐 아니라 다른 조직과에 협업에서 영향력을 행사할 수 있어야 하는 것 같다.
주니어, 미들이 기능 요구 사항을 받아서 구현하는 단계라면, 시니어는 이 요구사항을 분석해서 고객이 원하는 것들이 기술적으로 어떻게 해석되는지를 이해시키는 역할을 해야 한다.
스태프
스태프 엔지니어는 시니어 이상의 엔지니어를 뜻한다.
테크리더, 아키텍트, 해결사, 오른팔 등의 역할을 하는 엔지니어 그룹을 지칭한다.
우리나라에서는 스태프 엔지니어 보다 스태프 엔지니어 매니저가 더 흔한 것 같다.
흔희 말하는 개발 팀장 (개발도 잘하면서 팀원 관리도 할 수 있는...)
어쨌든 스태프 레벨에서의 성과는 기술적 방향성(기술 로드맵)을 만들고 운영하며, 멘토링, 스폰서십을 갖고 있으며 정의되지 않는 다양한 역할을 소화해 낼 수 있어야 한다.
이 부분이 참 모호한 것 같지만, 다양한 형태의 일들이 발생한다.
예를 들면 코드리뷰가 느려지면 코드리뷰가 느려지는 원인을 분석해서, 교육을 시키거나, 강한 룰을 만들어 내거나. 새로운 기술의 도입을 논의하거나.
이런 일들은 시니어 레벨에서 할 수 있지만 주도적이고 창의적인 활동을 할 수 있는지에서 차이가 발생하는 것 같다.
더 큰 성과
위에 레벨에 따른 역량과 기대 성과에 대해서 이야기했다.
그러면 조직 안에서 더 큰 성과를 만들어 내기 위해서는 어떻게 하면 좋을까?
평가를 해야 하는 조직장의 입장에서의 큰 성과는 무엇일까?
누가 봐도 어려운 일 (대단한 일)
평가 시즌이 되면 각자가 한 일들 정리하고, 그 성과를 놓고 평가를 하게 된다.
그 해에 우리의 일들 중에 난이도가 꽤 높은 일이 있다면 큰 성과를 가져갈 누군가는 쉽게 정해진다.
개발 난이도, 일정 등을 비교해 봐도 압도적인 실력과 노력(시작)을 보여준 사람이 쉽게 구분이 되고 동료들도 쉽게 인정을 하게 된다.
그런데 비슷비슷한 수준의 일들이 있을 때는 우위를 따지기가 힘든 게 사실이다.
이럴 때는 과제 외적으로 어려운 일을 한 사람을 찾게 된다.
회사에서 주최하는 큰 발표를 준비해서 실행하거나, 조직을 대표하는 역할을 하는 사람에게 자연스럽게 눈이 간다.
눈에 띄는 성장
우리의 연봉이 기대하는 결과를 반영하는 것이라면, 높은 연봉을 받는(대개는 시니어) 개발자가 더 어려운 개발을 해내거나, 더 좋은 품질의 산출물을 만들어 내는 건 당연히 요구받는 사항이 될 것이다.
기대하는 성과치가 주니어는 작을 것이고, 시니어는 그에 비해서 더 클 것이다.
주니어, 시니어 모두 성장을 해서 기대보다 더 큰 성과를 만들어 냈다고 가정을 해보자.
주니어의 기댓값이 100이고, 시니어의 기댓값이 150이라고 가정하면
각각 10, 12 이렇게 성장해서 110과 162의 성과를 내게 된다면 비율적으로 주니어가 더 큰 성과를 낸 것으로 간주될 것이다.
그래서 단순히 개인의 성장만 비교했을 때는 주니어가 더 좋은 성과와 평가를 받는 경우가 발생한다.
물론 미들, 시니어 급에서 폭풍 성장을 하거나, 주니어의 성장이 더디다면 결과는 다를 것이다.
하지만 경험상 시니어 이상에서 뭔가 뛰어난 성장을 증명해 보이는 경우는 많지 않았다.
시니어의 성과
개인의 성장만으로 더 큰 성과를 만들어 낼 수 없다면 어떻게 해야 할까?
위에서 언급했든 시니어, 스태프의 역할을 다시 상기해 보자.
시니어는 구성원, 타 조직에 더 많은 영향력을 행사하고, 협력을 통해서 그 성과를 입증해야 한다.
프로젝트 또는 조직전체의 효율을 개선하거나, 타인의 성장을 지원하여 그 노력을 인정받아야 한다.
그래서 "멘토십", "스폰서십", "글루역할" 등이 강조된다.
즉 누군가의 성과를 극대화시키고 기여를 인정받아서 성과를 키워야 한다.
그냥 혼자 열심히만 일하면 안 된다는 말이다.
냉정하게 말하면 "혼자 열심히 일해서 만들어 내는 결과물"은 밥값(연봉)을 하는 것이다.
