몇가지 가정이 있어야 한다고 생각합니다.

1. 회사에서 제시하는 정확한 방향성이 있다.
2. 방향성에 알맞은 목표들이 제시되어있다.
3. 목표를 달성하기위해 주기적인 관리가 진행되고 있다.

당연히 신입 또는 이러한 과정이 처음인 직원들은 제대로된 목표 설정이 어렵습니다.
매니저도 처음보는 직원이라면 어느정도 감으로 할뿐 쉽게 되지는 않습니다.

스프린트를 도입하고 스프린트 단위로 목표 달성률을 보고 회고를 하거나, 월별, 분기별로 목표를 수립하고 달성지표를 지속적으로 관찰 후
결과에 따라서 다음 목표를 좀더 상향시킬지 하향시킬지 결정을 하는 과정의 반복을 통해서 평균적인 수치를 찾아갑니다.
(이런 데이터가 굉장히 많은 회사라면 이런 과정이 최소화되겠죠)

물론 하향에도 적정선은 있어야 합니다. 누가봐도 최소치도 못하는 사람은 문제가 있으니 혼내든 뭘하든해야겠죠

이런 목표를 설정하는것도 훈련과 교육이 많이 필요하다고 생각이 드는데 대부분의 회사에서는 이런곳에 비용을 쓰기 싫어하는게 현실이죠 ㅜㅜ

제가 겪은 회사들중에서는 이런 관리를 잘한 회사는 한곳 정도였고, 나머지는 말로만 okr혹은 무슨 관리방법 어쩌고하지 실제로는 알아서 목표 세우고 알아서 지표도 세우고 알아서 평가도하고 그랬던거 같네요...

저 자신에게도 부끄러운 얘기지만 실무를 이해하고 일을 쪼개며 그에 따라 의사결정을 할 줄 아는 기술 매니저는 제가 일하면서 겪은 바로는 거의 보기 힘들었습니다. 보통은 경력과 연차때문에 매니징을 하게 되고 전혀 기술적인 배경이 없는 사람이 전체 개발자를 매니징하는 경우더라고요. 백엔드 개발자출신 매니저가 한 프로젝트에서 프론트엔드 개발자까지 매니징하게 되고, 적당히 자세한 수준의 설계와 지시사항은 없이 그냥 실무자에게(대부분 저연차 개발자에게) 기계적으로 이슈 생성하고 기능 이름만 던지는..

우리나라의 개발 조직문화는 바뀌긴 할런지 이젠 의문점만 남습니다.

물론 정량적으로는 어려울 것 같고요.

관리자마다 하시는 방식이 다르겠지만, 저라면 참여자들의 자신감으로 정성적 측정을 할 것 같습니다.

예를 들어, 참여자가 직접 본인 작업에 대한 자신감을 평가하게 하고

1. 어느정도 시간이 주어지면 무조건 가능하다
2. 불확실한 부분들이 어느정도 있긴 하지만, 예전에 해본 것과 유사한 면들이 있어서 할 수 있을 것 같다
3. 시작은 어떻게든 해볼 수 있겠는데 마무리는 어떻게 할지 아직 모르겠다
4. 어떻게 해야 할지 완전히 각이 안 보인다

2번으로 셀프 평가한 작업을 주고
1번이라면 더 어렵게 만들고 (시간제한 추가, 제약조건 추가 등)
3번이라면 더 쉽게 만들고 (코치 추가, 도구 추가, 스펙 줄이기 등)

이런 식으로 할 것 같네요.

훌륭한 글에 훌륭한 코멘트까지.. 감사합니다.

쌍따봉 드립니다. :)