[협업] 신뢰 자산과 팀의 기술적 공감대

출처: https://yozm.wishket.com/

"00의 도입을 주도해 ~을 얼마만큼 개선했습니다." 개발자 이력서에서 흔히 볼 수 있는 성과 사례이다.
그런데 조직에 막 합류한 사람이 이런 변화를 추진한다면 어떻게 될까?
이 글은 이런 실수를 했던 지난 내 커리어에 대한 이야기다.

조직에 새로 합류했을 때, 조급한 마음에 사로잡히기 쉽다. 특히 대부분의 기업에서 3개월의 인턴 과정을 거치게 되는데, 이게 불안의 원인이 되곤 한다. 게다가 내가 리더 포지션으로 입사했다면 "그래서 00이 합류해서 더 나아진 게 뭔데?"라는 생각에 스스로를 옥죄일지도 모른다.

 

이런 조급함은 급진적 변화를 부추긴다. 이보다 먼저 선행되어야 할 과정은 팀에서 신뢰 자산을 쌓는 일이다.
기본적인 업무 능력을 보여주고 이를 넘어 팀에 긍정적인 영향력을 줄 수 있다는 신뢰를 얻은 뒤에 변화를 준비해야 한다.
대개 급진적 변화는 구성원들의 반감과 저항을 동반되기 때문에 팀 개발에는 설득과 준비 과정이 필요하다.
 
매우 안타갑게도 이 당연한 사실을 경험을 통해 배우게 되었는데, 당시 나는 1인 개발을 하다가 이직하며 3명의 개발자와 협업하게 되었다. 스스로 판단하고 결정하는 일에 익숙해진 터라 동료들의 의견과 그동안의 방향성을 무시한 채 급진적 변화를 추진했다. 빨리 나의 능력을 인정받아 불안의 눈초리에서 벗어나 신뢰를 얻고자 하는 조급함 때문이었다.
 
결과적으로 나에 대한 불만이 생기고, 팀과 융화되기 어렵고 독선적인 사람이라는 분위기가 형성되는 지경에 이르었다. 이때 깨닫게 된 것이 팀의 기술적 공감대이다. 기술 도입으로 얻고 싶은 것은 팀 퍼포먼스의 개선이다. 그런데 급진적 변화는 팀의 기술적 공감대를 해치면서 불신과 함께 팀 퍼포먼스 하락이라는 결과로 이어진다.
 
그렇기에 뚜렷한 개선 포인트를 발견하더라도, 조급한 마음을 다스리고 팀이 가지고 있는 방향성과 기술에 대한 수용성을 고려해 걸음을 맞추어야 한다.
 
결국 제품을 만드는 일은 팀 스포츠이다.
 
p.s. 초반에 독선적 성격이라는 평가를 받았던 나는 내부 분위기를 감지하고 태도를 개선해 후에 "피드백을 통해 긍정적 방향으로 변화할 수 있는 분"이라는 새로운 평가를 받으며 무사히 조직에 적응할 수 있었다.