TL;DR

  • 피드백을 받았을 때 진위·인지 시점·전달 경로·책임 소재를 점검하고 대응 방식을 신중히 선택해야 피드백을 계속 얻을 수 있음.
  • 불만을 성급히 무시하거나 상대를 공격하거나 약속을 지키지 않으면 이후 피드백의 빈도와 형태를 해칠 수 있음.
  • 문제가 사실이라면 바로 해결하고, 상대가 피드백을 늦게 전달한 이유와 조직 문화의 장애 요인을 확인해야 함.
  • 피드백 내용이 틀렸더라도 오해가 생긴 원인을 살펴보고, 전달 대상이 잘못됐다면 책임 구조와 팀의 소통 방식을 점검해야 함.
  • 피드백을 준 사람에게 감사를 표현하고 수용·처리 과정을 조직에 공유하면 반복적인 피드백과 안전한 피드백 문화를 촉진할 수 있음.

피드백은 귀중하지만 낭비되기 쉬움

  • VPE에게 피드백을 받은 지 오래됐는지 물었고, 최근 몇 차례 피드백을 어떻게 다뤘는지 확인한 뒤 그 이유를 이해함. 피드백을 잘못 다루면 이후 피드백을 받는 빈도와 형태가 달라질 수 있음.
  • 불만을 너무 쉽게 무시하거나 상대를 공격하거나, 하겠다고 약속한 일을 끝내지 않는 행동은 상대가 다시는 말하지 않게 만드는 확실한 방법임.
  • 순간적인 반응으로 관계를 망치거나 전달받은 내용을 제대로 활용하지 못하는 경우가 있음. 피드백에서 얻을 수 있는 가치를 최대한 끌어내는 것이 목표임.

피드백이 없다면?

  • 이미 피드백을 받고 있다고 가정하지만, 실제로는 그렇지 않을 수 있음.
  • 부하 직원, 동료, 상사에게 피드백을 요청하고 그들이 솔직하게 말할 수 있도록 하는 일부터 시작해야 할 수 있음.

피드백을 최대한 활용하는 절차

  • 누구에게서든 피드백을 받았을 때 스스로에게 던질 질문을 점검표로 활용할 수 있음. 함께 일하는 고객과 이 질문을 살펴보면 지나쳤던 가치 있는 단서를 적어도 하나 발견하는 경우가 많음.

사실인가?

  • 충분히 생각하지 않은 채 피드백을 일축하지 않는 것이 기본임. 전달받은 내용을 평가하고 상황이 실제로 설명된 그대로인지 확인해야 함.
  • 문제의 존재를 인정하기 어려울 수 있음. 외부의 관점이 도움이 될 수 있으며, 잠시 멈춰 몇 가지 질문을 던지고 반대편의 주장을 대신 세워보는 것도 통찰을 얻는 데 유용함.
  • 설명된 내용이 사실이라면 문제를 해결하는 방향으로 이어져야 함. 문제를 고쳐야 함.

너무 늦게 알게 됐는가?

  • 학습을 극대화하려면 사람들이 처음 문제를 알아챈 시점과 내가 알게 된 시점 사이의 간격을 살펴야 함.
  • 피드백을 준 사람이 한동안 문제를 묵혀뒀는지, 나에게 말하지 못하게 한 요인이 무엇인지 확인해야 함.
  • 예를 들어, 여러 회사에서 사람들이 먼저 요청받기를 기다리거나 몇 주마다 한 번 있는 정기 회의까지 문제를 키우는 경우를 봄.
  • 기다릴 이유가 없다면 그 지연을 해결하고 조직 문화의 어떤 부분이 잘못 설정돼 있는지 파악해야 함.

다른 사람이나 경로를 통해 들을 것으로 예상했는가?

  • 실제로 피드백을 전달한 사람이 누구든, 다른 경로로 더 일찍 알게 되리라 기대했는지 돌아봐야 함. 행사장을 떠나는 엘리베이터에서야 치아 사이의 파슬리를 발견하는 것처럼, 친구가 더 일찍 알려줄 거라 믿었지만 그러지 않은 경우와 같음.
  • 예를 들어 직속 부하 직원에게 어떤 내용을 들었지만, 동료나 CEO가 직접 알려줄 것으로 기대했을 수 있음. 또는 상황을 감시하는 시스템이나 절차가 이미 있다고 생각했을 수도 있음.
  • 어떤 경우든 필요한 경고가 왜 울리지 않았는지 살펴볼 기회임.

틀린 내용인가?

  • 앞선 점검 항목과 반대되는 경우에도 대응이 필요함. 누군가 틀린 내용을 말했다면 내가 무언가를 잘못하고 있다는 신호일 수 있음.
  • 충분히 명확하게 소통하지 않았는지, 상대가 그런 인상을 받은 이유가 무엇인지, 상대가 그렇게 느끼지 않도록 무엇을 할 수 있는지 확인해야 함.
  • 동료나 상사의 피드백을 받았을 때 그들이 상황을 나와 다르게 보고 있음을 깨닫는 경우 특히 중요함. 비판을 피하려 하기보다 그런 인상을 만드는 데 내 역할이 무엇이었는지 이해해야 함.

전달 대상이 잘못됐는가?

  • 피드백이 실제 문제를 설명하더라도 내가 해결할 적임자가 아닐 수 있음. 이를 무시하거나 직접 나서서 처리하고 싶은 충동이 들 수 있지만, 먼저 왜 나에게 전달됐는지 생각해야 함.
  • 회사에서 책임 소재가 불분명하다는 뜻일 수 있음. 또는 소통 역량이 부족하고 팀이 리더를 의존처로 삼는 증상일 수 있음.
  • 그런 의존처 역할을 맡아 메시지를 전달하는 데 만족할 수도 있음. 대부분의 경우 권장하지 않는 방식이지만, 적어도 의식적으로 선택해야 함.

다시 피드백을 받을 가능성을 어떻게 높일까?

  • 피드백을 실행하든 하지 않든, 다른 사람에게 전달하든 직접 처리하든, 피드백을 준 사람의 경험도 고려해야 함.
  • 상대가 인정받았다고 느끼고 다음에도 피드백을 주고 싶도록 어떤 표현을 쓸지 생각해야 함. 피드백을 피하고 싶은 경험으로 만들 수도 있고 정기적인 일로 만들 수도 있음.

다른 사람에게서 피드백을 받을 가능성을 어떻게 높일까?

  • 마지막으로, 이 피드백을 더 많은 피드백을 이끌어내는 단서로 활용해야 함.
  • 조직 내 다른 사람과 피드백 내용을 항상 공유할 수 있는 것은 아니지만, 공유할 수 있을 때는 피드백 행동을 장려하는 효과가 있음.
  • 누군가 피드백을 줬다는 사실을 알리면 조직에서 피드백을 주고받는 일이 자연스러워짐. 내가 피드백을 받아들이고 처리하며 준 사람에게 감사를 표하는 모습을 보면 다른 사람도 같은 행동을 하기 편해짐.
  • 다른 사람도 약간의 경쟁심을 느껴 공유할 만한 좋은 피드백을 더 주의 깊게 찾게 될 수 있음.

마무리

  • 이 질문들을 점검하면 앞서 언급한 폐쇄적인 사고에 갇힌 VPE와 정반대의 방식으로 피드백을 다룰 수 있음.
  • Feedback Skeleton에 대한 자세한 설명은 The Tech Executive Operating System에서 확인할 수 있음.
  • 외부의 피드백이 필요하다면 연락을 요청함.