2021.08.01 / 다른 사람에게 나는 어떤 팀원일까 / 이끌든지, 따르든지, 비키든지

이끌기 위한 용기는 없고, 따르기 위한 존중도 없고.

'이끌든지, 따르든지, 비키든지'. CNN 창업자 테드 터너가 한 말이라고 한다. 이전까지는 이렇게까지 와닿지 않았는데, 이번 팀 미션을 하면서 크게 공감한 말이다. 저 한 문장은 내 잘못된 태도와 앞으로 어떻게 바뀌어야 하는지를 모두 포함하고 있었다.

 

프로젝트 초반에 열정이 앞서 의견을 마구마구 내었다. 물론 의견을 잘 내주고 대화에 참여해주는 것은 중요하다고 생각한다. 문제는 나는 비판만을 말했다. 스스로도 모호하고, 정확히 알지 못하면서, 투덜대기만 했다. 성장을 위해서 비판이 분명히 필요한 것은 맞지만, 내 비판은 성장을 위하지 않았다. 그저 '뭔가 거슬리고, 내 것과 다르다' 라는 생각 아래 문제점을 찾았던 것 같다.

 

어느 순간부터 내가 문제 삼았던 부분이 정말 우리 팀을 위한 것인지 회의감이 들었고, 그렇지 않았다는 것을 그때 알게 되었다. 나는 '팀에게 좋은 것'이 아니라 '내 마음에 편안한 것'을 위해 의견을 내었던 것 같다. 마음에 들지 않아 의견 제시를 하자니 제대로 된 근거로 설득은 못 시키겠고, 따르자니 찝찝했다. 딱 이끌지도, 따르지도 못하는 상태였다.

 

바뀌고 싶었다.  당장에 태도, 생각 변화를 만들기 쉽지 않으리라 생각했고, 그래서 나름의 규칙을 만들어보았다. 의식적으로라도 이 규칙을 따라보려고 한다. 처음에는 어렵더라도 계속 의식하고, 연습하면 나중에는 의식하지 않아도 자연스레 몸에 배지 않을까 기대하고 있다. 마치 이제는 무의식적으로 쓰고 있는, 맥북 단축키를 연습할 때처럼 말이다. 

 

1. 책임을 질 수 있는 의견을 제시하자

자신도 명확하지 않은 상황이거나, 또는 설명할 준비가 안 된 상황에서 의견을 제시하지 않는다는 것이다. 회의 중에는 정말 많은 말들이 오가고, 모든 말들이 책임을 질 수 있는 것들은 아니라는 것을 알았다. 나 역시 아직 정리가 안 된 상황에서 말을 하거나, 정확하지 않은 정보로 흐름을 망칠 때가 있었다.

 

어떤 의견을 제시할 때 보다 명확한 근거를 갖고 말을 해야 한다는 것을 배웠다. 의견을 제시할 때 근거가 없으면 떼쓰는 것과 다를 바가 없고, 본인 생각이 있어도 그걸 설명하지 못한다면 생각이 없는 것과 다를 바가 없다고 느꼈다. 물론 모든 의견에 확신을 갖지는 못 할 것이다. 확신을 갖지 않고 마구 아이디어를 뽑아야 하는 회의도 있겠지만, 그렇지 않은 회의에서 책임지지 못하는 '아마 그럴 거 같은데?'로 물을 흐리지 않으려 노력해야겠다.

 

2. 아무 말보단 차라리 침묵한다. 

팀플에서의 침묵은 '비협조적인 것'으로만 생각하고 있었는데 아니었다. 침묵이 더 나은 상황도 있음을 이번 프로젝트에서 배웠다. 그저 참여함을 표시하기 위해 아무 말을 하기보단, 차라리 침묵해야겠다고 생각하게 된 것 같다. 모르는 상황에서 던진 의견이 다른 사람들의 생각에 방해가 될 수 있다는 것을 배웠다.

 

처음에는 아예 음소거 모드를 하고 사람들의 대화를 들었다. 회의가 어떻게 흘러가는지, 내가 뭘 놓치고 있고, 다른 사람들은 어떤 생각을 갖고 의견을 말하는지를 보았다. 문제는 그런 일이 반복되니 적극적이지 않은 모습으로 비치진 않을까 걱정을 하게 된 것 같다. 적극적이지 않은 모습에 팀 분위기를 헤칠까 싶었다.

 

회의에 적극적임을 보이면서도, 효과적으로 생각이 없음을 표현할 방법은 없을까. 침묵이 최선일까. 침묵 다음으로 연습해본 태도는 생각 없음을 말로 꺼내 표현하는 것이었다. 

 

'잘 모르겠습니다', '방금 내용에 집중하지 못했습니다', '당신의 생각을 못 따라갔습니다' '아예 기호가 없습니다'

 

기본적으로 나의 부족함이나 잘못을 드러내는 말들이다. 어쩌면 생각 없이 질렀던 아무 말은, 이런 부족함을 보일 용기가 없어서가 아니었을까. 앞으로는 위 말들로 부족함을 솔직하게 표현할 것이다. 그리고 공부할 생각이다. 다음번엔 그 이슈에 대해서 온전한 내 생각을 가질 수 있도록.

 

3. 작업 내용에 반하는 피드백을 할 때는 작업자만큼 고민하고 권한다.

처음 프로젝트를 하면서, 코드나 설계에 대한 피드백을 어떻게 줘야 좋을지를 가장 많이 고민했던 것 같다. 그리고 찾은 다짐이다. 잠깐 보고 리뷰해주는 나보다, 작업자는 훨씬 더 많은 시간을 써가면서 고민했음을 기반으로 피드백을 줘야겠다는 것이다. 

 

연습하고 있는 방법은 작업자만큼 해당 코드에 공을 들여 피드백을 주는 것이다. 더 자세히는 피드백을 주기 전에 직접 다 해보고 있다. 피드백을 줘놓고도 실제로 직접 해보면서, 왜 작업자가 이렇게 하지 않았는지 그제서야 볼 수 있었던 상황을 경험했다. 작업자를 지치게만 하는 피드백이 이었던 것이다.

 

전체 코드가 어떻게 진행되는지. 다른 코드에 너무 많은 변화가 생기진 않는지. 생각했던 것보다 어려워 개발 자체에 너무 많은 비용이 들진 않은 지. 스스로 더 확실한 근거를 잡을 수 있고, 작업자에게 더 명확하게 내가 원하는 방식을 제시할 수 있었다.

 

모든 피드백에 이렇게 많은 시간을 쏟으려는 것은 아니다. 이 규칙으로 경계하고 싶은 것은 확실하지 않은 피드백이지, 시간을 덜 들인 피드백이 아니다. 확신할 수 있는 피드백과 그럴 것만 같은 피드백을 잘 구분해야 할 것 같다. 

 

마무리 : 다른 사람에게 나는 어떤 팀원일까

돌이켜보면 본인을 객관적으로 바라보는 경우보다, 타인을 부정적으로 평가하는 경우가 훨씬 많았던 것 같다. 본인보다 타인을 평가하는 것이 쉽고, 긍정적인 평가보다 부정적인 평가에 더 적은 지표가 필요했다. 그래서 이별 이야기에는 나쁜 놈만 있고, 헬스장 후기에는 빌런들만 있고, 그래서 조별 과제는 잔혹사뿐인가 보다.

 

이번 프로젝트를 하면서는 팀원들에 대한 평가를 멈추고 나를 평가해보고 싶었다. 다른 사람에게 나는 어떤 팀원일까. 스스로를 돌이켜 보면서 내가 얼마나 부족한 사람인지를 더 많이 느낀 거 같다. 그리고 실수를 되짚어 봤을 때, 팀원들을 존중하지 못해서 생긴 잘못들이 대부분이었다는 것을 찾았다.

 

내가 정말 우리 팀원들을 존중하고 있었을까. 그들은 나에게 존중받는 느낌을 받았을까.

특별히 '팀원을 믿지 않겠어'라는 마음을 가지진 않았지만, '우리 팀원들을 존중해야지'라는 생각도 해본 적 없는 것 같다.

 

존중할 줄 아는 사람이 될 수 있도록 노력할 생각이다.

잘 지킬 수 있길.