반응형

 

직원들에게 "업무가 많은 편인가?"라고 물어보면 대다수가 "당연하다. 업무가 너무 많아서 힘들다.",  "과도한 업무량 때문에 야근을 해야 할 정도다. 요즘은 주52시간 근무제 때문에 공식적으로는 야근을 별로 안 하는 것 같지만, 집에 가져 가서 하는 경우가 많다."는 식의 답변을 하곤 한다. 나는 지금껏 20년 넘게 컨설턴트로 일하면서 "나는 일이 별로 없다." 혹은 "적절할 정도로 업무량이 주어진다"는 대답은 한번도 듣지 못했다. 그렇게 답하지 못하는 이유는 업무량이 더해질까 염려하기 때문일 것이다. 또한 자신이 맡은 역할의 중요성과 함께 본인의 존재감이 미미하지 않음을 남들에게 적극 변호하고자 하는 욕구 때문일 것이다. 

흥미로운 것은 "홍길동은 일을 별로 안 하는 것 같다. 일찍 퇴근한다."는 식의 이야기도 뒤따라 나온다는 점이다. 본인의 업무량이 과도하다는 점을 더욱 부각시키려는 것인지, 그렇게 자신에게 일이 몰린 이유가 '일 못하고 일 안 하는 홍길동'이라고 하소연하고 싶은 것인지, 평소에 홍길동과 사이가 별로 좋은 않은 것인지, 팀장이 홍길동을 편애하는 것인지 나로서는 알 수는 없다. 홍길동의 업무능력이 출중하여 업무시간 내에 일을 훌륭히 끝내는 것일 수도 있지만, 이것 역시 외부인인 나는 예단하기 어렵다. 어쨌든 나는 이런 모습을 볼 때마다 자신에게 가해지는 부당함을 강조하기 위해 상대에 대한 비난을 동원하는 것이 인간사회의 어두운 면 중 하나라는 생각을 하곤 한다.

 



나는 업무량의 과도함을 호소하는 직원들에게 "일이 별로 없다고 생각하는 홍길동에게 일을 도와 달라고 부탁해보지 그러세요?"라고 제안해 본다. 이 질문은 실제로 홍길동에게 도움을 요청해 보라는 제안이라기보다 사실은 직원의 반응을 보기 위함이다. 많은 직원들은 이렇게 대답한다. "한번 홍길동에게 도와 달라고 해 본 적이 있는데, 귀찮아 하더라구요. 자기일도 바쁘다고 핑계를 대더군요. 별로 일 없어 보이던데..." 그러고는 다시 일을 부탁하기가 싫어지더라는 말을 덧붙인다.

하지만 이렇게 생각해보면 어떨까? 절대적으로 업무량이 많든 그렇지 않든 홍길동 자신의 기준으로 볼 때(누구나 자기 기준을 적용한다) 일이 많다고 여길지 모르는 일 아닌가? 업무시간 내내 조금도 쉬지 않고 일을 끝마치느라 애를 쓰는 것은 아닐까? '칼퇴근'을 한다고 해서 할일이 별로 없다고 무조건 간주해서는 곤란하지 않을까? 상사에게 '얼굴 보여주는 시간(face time)'이 조직 충성도나 '열정'의 잣대로 평가받는 것에 대한 거부감이 있지는 않을까? 나는 '동료들도 나만큼 업무가 많을 것이라고 '일단' 간주하는 것'이 동료들에게 도움을 요청할 때 지녀야 할 무엇보다 중요한 마음가짐이라고 생각한다. 간혹 정말로 놀면서 회사를 다니는 동료 직원이 있긴 하지만, 대다수의 동료들은 '당신만큼' 일이 많다. 당신만큼 과도한 업무량에 허덕인다. 이런 마음가짐을 지닌 채 동료들에게 일을 부탁한다면 어떻게 해야 할지 감을 잡을 수 있을 것이다. 

첫째, 구체적이고 세부적인 일을 요청해야 한다. 도움을 요청하는 것이 '이 사람이 나에게 일을 떠안기는구나'라고 느끼게 만든다면 누가 요청을 들어주겠는가? 당신이 해야 할 업무 중에서 동료의 도움이 절실하게 필요한 부분, 동료가 더 잘할 수 있는 일이나 동료가 해야 안심이 되는 일을 구체적이고 세부적으로 요청하라. 그냥 "나 좀 도와줘"라고 푸념하듯 말하지 마라. 구체적이고 세부적인 부분을 요청해야 동료가 자기 시간을 크게 빼앗기지 않는다고 여기지 않겠는가? 동료가 '이 사람이 나에게 무슨 일을 부탁하는지 모르겠군. 나 보고 다 해달라는 건가?'라고 생각하게 되면 실제로 여유시간이 있더라도 "미안하지만, 나도 좀 바쁘거든"이라 대꾸하기 마련이다. 입장 바꿔 생각하면 알 수 있을 것이다. 

둘째, 동료의 거절을 수용하라. 동료에게 A라는 일을 부탁했는데 "미안하지만 A 전부를 할 시간은 없어. 대신에 A'를 해주면 안 될까?"라고 동료가 제안한다면 어떻게 해야 할까? 이때 속으로 '이 사람이 내 부탁을 거절하네. 섭섭하군'이라는 감정이 들겠지만, 상대방도 나만큼 바쁠 거라는 전제를 한다면 '최대한 나를 도와주려고 하는군'이라고 여겨야 할 것이다. 동료가 "나는 도와줄 시간이 없지만, 여기여기에 가서 문의해 보면 도움을 받을 수 있을 거야", "미안하지만, 내가 지금 이 일을 마치고 난 다음에 도와주면 어떨까? 그때 다시 나에게 구체적으로 말해줘"라고 동료가 말한다면 일단 거절(혹은 핑계)을 수용하고 물러서는 게 좋다. 

악감정을 가질 필요가 없고, 그래서도 안 된다. 왜냐하면 인간은 남의 부탁을 거절할 경우 그것을 언젠가는 들어줘야 할 부채로 인식하기 때문이다. 그래서 다음에 부탁할 때는 요청을 들어줄 가능성이 훨씬 높아진다. 프랜시스 플린(Francis J. Flynn)의 연구 결과가 이를 증명하고 있다. 이 연구에서 도움요청자(help-seeker)들은 잠재적 조력자(potential helper)가 과거에 자신의 부탁을 거절했다면 앞으로도 계속 자신의 부탁을 거절할 거라고 예단하는 경향을 보였다. 그러나, 계속해서 남의 부탁을 거절하면 조직 내에서의 관계를 원활하게 유지하기가 어렵다는 점을 누구나 알지 않는가? 내가 남의 부탁을 거절하면 나도 남에게 일을 부탁하기가 어려운 법인 말이다. 플린의 연구에서 실제로 잠재적 조력자들은 과거의 거절을 미안하게 생각하고 앞으로는 부탁을 들어줄 용의를 보였다.

 



셋째, 동료의 부탁을 최대한 들어주라. 부탁을 거절한 것을 부채로 느끼는 것처럼, 부탁을 들어준 것 역시 갚아야 할 부채로 여기는 법이다. 당연한 말이지만,  내가 평소에 동료를 많이 도와주었다면 상호호혜라는 불문율에 따라 동료의 도움을 기대할 수 있는 것 아니겠는가? 동료의 도움을 받으려면 평소에 동료의 부탁을 최대한 들어주거나 내가 먼저 동료에게 도움의 손길을 건네야 할 것이다. 물론 사정상 동료의 요청을 들어주지 못할 경우라면(이런 경우가 잦을 것이다), 이때는 솔직하게 자신의 상황을 설명하고 최대한 자신이 도울 수 있는 방법을 역으로 제안하는 것이 좋다. 문서 작성을 부탁 받으면 그와 유사한 샘플 문서를 건넨다든지, 나중에 프린트되어 나온 결과물의 제본과 배포를 돕는다든지 등 언제든지 가용할 경우에는 최대한 돕는다는 인상을 주어야 한다.

넷째, 동료의 도움을 고마워하라. 동료가 당신의 부탁을 들어주었다면 그 결과물의 질이 어떤 수준이든 관계없이 고마움을 표해야 한다. 동료가 나의 부탁을 들어주지 않은 부채가 있다고 해서, 또 내가 그동안 많이 도와줬으니 내 부탁을 들어주는 게 당연하다고 해서 고마움을 표하지 않는다면, 누가 기분이 좋겠는가? 역시나 입장 바꿔 생각하면 알 수 있을 것이다. 여기에서 중요한 점은 동료의 도움이 훌륭하지 않고 결과적으로 유용하지 않더라도 고마움을 표해야 한다는 것이다. 어찌됐든 동료는 자신의 시간을 할애하지 않았는가? 또한, 그 동료에게 부탁을 한 것은 당신 자신이기 때문에 도움의 결과에 대해서도 당신이 책임을 져야 한다. 무엇보다, 당신은 동료의 상사가 아니기 때문이다. '일을 시킨 것'이 아니라 '도움을 요청한 것'이기 때문이다. 그리고 당신이 동료에게 일을 구체적으로 부탁하지 못했고 동료가 감당하기 어려운 일을 부탁했기 때문일 수도 있다. 

팀워크의 성공은 협력에 있다. 그리고 협력이 잘 이루어지려면 도움을 요청하는 법을 팀원 각자가 능숙하게 발휘할 수 있어야 한다. 상호호혜의 불문율을 각자 준수하는 수준을 뛰어넘어 동료들에게 먼저 도움을 제안할 수 있어야 한다. 그러나 이보다 중요한 것은 '이유 있는 거절' 역시 마음 편하게 할 수 있어야 하고 그런 거절을 '쿨하게' 받아 들이는 분위기가 전제돼야 한다는 점이다. 이렇게 도움을 주고 받을 때 지켜야 할 룰을 팀원들의 합의로 결정하는 것이 하나의 실천방법이 되지 않을까?

to be continued...


*참고논문
Newark, D. A., Flynn, F. J., & Bohns, V. K. (2014). 

Once bitten, twice shy: The effect of a past refusal 

on expectations of future compliance. 

Social Psychological and Personality Science, 5(2), 218-225.

반응형

  
,