프로젝트 팀원의 단점만 보이는가?

최근 프로젝트를 몇 번 실패하고 퇴사한 직원이 있었다.

입사한 지 갓 1년을 넘은 경력직으로 이전에 대기업 전산직으로 근무했던 사람이었다.

나도 같이 프로젝트를 한 번 같이 했다.

내가 리더였고 그 직원은 팀원이었다.

처음 분위기는 좋았지만 한 달 정도 지나면서 다른 프로젝트에서 실패하고 리젝(reject)된 이유가 슬슬 보이기 시작했다.

내 장점 중 하나라고 한다면 프로젝트를 하면서 만나는 팀원들의 장단점을 빨리 알아차린다는 것이다. 물론 나 또한 장단점이 명확하다. 특히 야근과 주말근무를 엄청 싫어하기에 윗 분들은 별로 좋아하지 않는 타입니다. 

위에선 큰 기대를 하고 경력직으로 뽑은 이 직원은 입사 후 첫 프로젝트에서 리더로 들어갔지만 두어 달? 정도 있다가 리젝 되었다. 물론 보통 사람들은 자신의 잘못을 쉽게 인정하지 않는다. 나도 그렇기에..

작은 프로젝트 리더를 맡고 그 직원이 같이 참여하게 되었다. 리젝된 후 두 번째 프로젝트인 것이다. 리더가 나였기에 팀원으로 들어왔다. 왜 리젝 되었는지 이야기를 들어보니 본인의 잘못은 없었다. 그저 고객사의 문제를 강조했다. 그 고객사는 최근 나도 프로젝트를 진행했기에 어떤 상황인지 금방 이해하게 되었다.

작은 프로젝트는 시작되었다. 역시 말도 안되는 개발팀을 구성해 주었고 정말 답답한 마음이 앞섰다. 하지만 크고 작은 모든 프로젝트가 거의 완벽에 가까운 팀을 구성하긴 힘들다.

요구사항을 정리하고 기획을 시작하면서 단점이 드러나기 시작했다. 사실 이 직원뿐만 아니라 비슷한 또래의 임직원들의 고질병 같은 상황이 나타나기 시작한 것이다. 최근 시작하는 프로젝트에도 비슷한 나이대의 임원과 회의를 하는데 한마디로 꼰대다. 90년대 스타일의 개발 방식을 내세우면서 요즘 트렌드를 이해 못 한다고 했다. 굴삭기가 있는데 배우는데 복잡하다고 삽질이 최고다를 외치는 그런 분위기다.

여하튼 이 직원도 업무를 진행하는데 약간의 문제를 만들기 시작했다. 사실 리더의 역할 중 하나는 고객과 개발팀과의 적절한 업무적 조율을 잘해야 한다. 고객 편에 서면 개발팀의 개고생과 반발이 심해지고 프로젝트는 지옥의 나락으로 떨어진다. 최종적으로 지연과 함께 회사의 이익과 신뢰는 떨어질 수밖에 없다. 반대로 개발팀 편이나 본인 편을 강조하게 되면 고객사는 엄청난 불만이 발생하고 결국 리젝 되는 상황까지 발생하는 것이다.

이 직원은 그 동안의 경력을 기반으로 정말 많은 기능을 추가하고 있었다. 처음 이야기 한 것처럼 이 프로젝트는 작은 사이즈이다. 많은 기능을 넣으면 좋겠지만 고객의 요구도 아니고 기간, 팀 능력 및 금액적으로 봐도 불필요한 상황이었다. 사이즈에 맞게 적절한 기능을 고객과 협의해서 구현하는데 최적의 상황인데 마치 대형 프로젝트인 듯 상황을 만들어갔다. 고객의 입장에서도 해주면 좋겠는데 할 수 있겠냐는 우려를 표현했다. 그런 상황이 고객과 개발팀원들의 문의로 알게 되었고 내가 고객과 다시 조율해서 현실성 있는 구도로 다시 각을 잡았다. 그리고 그 직원에게 이래저래 상황을 설명하고 협의된 내용대로 진행하자고 했다. 그런데...

그런 상황을 그 직원은 자존심이 상했는지 리더인 나 몰래 다시 고객을 만나 설득하기 시작했다. 세상에...

그런 사실을 모르고 있다가 다음날 고객이 다시 메시지로 연락이 왔다. 불편하다고...정리가 안되는 거 같다고...

그래서 그냥 나랑 얘기한대로 진행할 테니 그 직원과 한 이야기는 넘기라고 했다.

그 뒤로도 업무의 역할 때문에 다툼이 있었다. 본인이 할 일이 아니라면서 짜증을 냈다. 가장 큰 문제는 개발 팀원 중 한 명의 요청 때문에  중요한 변경에 대해서 리더나 설계자와 전혀 상의하지 않고 임의로 변경하고 보고도 하지 않았다. 그것 때문에 다들 많은 시간 고생했다. 바뀌었는지 모르고 잘 실행되던 것이 계속 오류가 났기 때문이다. 결국 내가 발견했고 누가 이걸 변경했냐고 하니 그 개발 팀원이 알려줬다. 이래저래 요청하니 저분이 수정해 줬다고. ㅎㅎㅎ

같은 내용에 대한 반복적인 문의와 잘 삐지는? 그런 성향때문에 고객도 좀 힘들어했다.

그런 과정을 지켜보니 왜 이전 프로젝트에서 리젝되었는지 이해가 되었다. 그 뒤로도 몇 번의 기회가 있었지만 프로젝트에서 모두 리젝 되었다고 들었고 결국 퇴사하게 되었다.

다들 그 직원 탓만 하고 그 직원이 문제가 많아서 퇴사하게 되었다고 생각한다. 과연 그렇게 말하는 본인들은 잘 하는가?

물론 그 직원은 프로젝트 리더로서 자격이 부족함은 맞다. 반면 장점도 있었다.

다들 그 직원의 단점만 가지고 평가하고 선입견을 가졌기에 장점을 활용할 생각을 못한것이다.

모든 직원이 완벽하기를 기대한다는 것은 잘못된 생각이다. 그렇게 평가하는 본인은 정말 완벽하냐는 것이다.

사실 나에 대한 평가도 대충 알고 있다. 장점을 아는 사람들은 내 능력을 잘 활용하는데 그저 단점만 보는 리더들 때문에 답답한 늪에 빠지고 있다는 생각이 종종 든다.

나는 작은 프로젝트를 하면서 그 직원의 단점만 본것이 아니라 장점도 봤다. 그래서 그 장점을 최대한 활용하고 그 직원의 능력을 높이 평가해 줬다. 감정적으로 부딪힌 적도 있지만 최대한 빨리 정리했다. 그것도 리더의 능력이다.

하지만 보통 리더들은 자신의 주장과 자존심이 강해서 조금만 다른 의견을 보이면 화를 내거나 짜증을 내고 가버린다. 팀원들에게 엄청 무례한 행동이다. 그리고 자신에게 다른 의견을 제시하거나 바른 정보를 제공하면 감정적으로 대하기 시작하고 결국 진급이나 연봉에 영향까지 주기도 한다. 흔히 꼰대라고 한다.

진정한 리더라면...

우선 리더는 팀원을 존중해야 한다. 근태나 업무진행에 문제가 있는 경우는 당연히 조치를 해야 한다. 그리고 그 직원의 장점과 단점을 빨리 파악해서 장점을 잘 활용할 수 있도록 도와줘야 한다.

IT는 정말 빠르게 변하고 발전한다. 스마트 폰 앱을 만드는데 2G 폰 시절 개발방식을 라떼는~ 하면서 요구한다면 프로젝트는 산으로 갈 것이고 팀원들은 실망하게 될 것이다. 리더라면 직접 개발하지 않더라도 최신 트렌드는 꾸준히 이해하면서 팀원들과 커뮤니케이션을 해야 한다. 회의를 하는데 현재 프로젝트에서 요구하는 신 기술과 전혀 관계없는 라떼를 외친다면 빨리 그만둬라. 최근에도 회의를 하는데 엉뚱한 옛날이야기를 하길래 이 부분은 이런저런 신기술에 대한 부분이다라고 이야기해 주니 살짝 삐져서 가버렸다.

리더라면 회의 시간에 좋은 의견을 주는 팀원에게 긍정적 리액션을 해줘야 한다. 그런데 의견을 제시하는 것에 샘이 나는건지 무슨 의견만 내면 "그럼 니가 해" 라는 말을 툭툭 던지는 리더가 있다. 실제로 내가 일하는 곳에서도 있다.

그렇게 대응하면 어떤 팀원도 좋은 의견이 있어도 이야기 하지 않을 것이다. 발전도 없고 시간 낭비 회의가 될 것이기 때문이다.

프로젝트가 잘 진행되기 위해서는 리더의 역할과 능력이 정말 중요하다. 고객과 팀원과의 관계가 엄청 중요하기 때문이다. 그리고 리더는 항상 공부를 해야 한다. 라떼는 카페에서 맛있게 주문해서 먹는 걸로 끝내야 한다. 

그렇다고 그들의 오랜 경력과 경험을 무시하면 안된다. 프로젝트가 꼭 기술력으로만 성공하는 것이 아니기 때문에다.

멋진 리더가 되는 방법 중 하나는 팀원의 장점도 잘 살펴보고 응원하고 잘할 수 있도록 활용하는 것이다.

 

요즘은 정말 답답한 상황이 많이 발생하고 있다. 무엇이 중요한지 그래서 어떻게 해야 하는지 꼼꼼히 챙기고 진행하는 것이 필요한데 그저 대충대충 아무나 아무나 식으로 프로젝트를 준비하는 것을 보면서 정말 되기를 바라는 것일까 의문이 든다.

오늘도 열심히 스킬을 업 하는 신기한 연구소였습니다.