동료가 훌륭한 일을 했다면 그 동료의 매니저에게 알려주세요

• 매니저가 직접 보지 못한 동료의 성과와 영향을 전달하면 평가와 승진 논의에서 중요한 근거가 될 수 있음
• 좋은 피드백이라도 당사자 동의 없이 공유하면 성장 목표와 역할 기대에 어긋나 역효과가 날 수 있음
• 부서 간 협업, 1:1 도움, 문제 예방, 문서화·코드 리뷰, 원격 근무, 지원 역할처럼 가시성이 낮은 일은 의도적으로 드러내야 인정받기 쉬움
• “잘했다”는 말보다 무엇을 했고 어떤 결과를 냈는지 구체적으로 쓰고, 기대 수준을 넘어선 지점을 짚어야 승진 근거로 쓰기 좋음
• 이메일, 공개 칭찬, 동료 보너스, 사내 피드백 시스템 모두 가능하지만 공개 방식과 공유 대상은 먼저 당사자에게 확인하는 편이 안전함

---

매니저에게 알리기 전에 먼저 물어보기

• 동료의 좋은 성과를 매니저에게 전달하는 일은 도움이 되지만, 당사자 동의 없이 진행하면 예상치 못한 문제가 생길 수 있음
• 긍정적인 말도 상황에 따라 역효과가 날 수 있음
  • 도메인 기술 전문가로 성장하려는 사람에게 프로젝트 관리 능력만 강조하면 현재 성장 목표와 맞지 않을 수 있음
  • 매우 시니어한 엔지니어에게 단순하고 일상적인 작업을 잘했다고 말하면 역할 기대를 이해하지 못한 낮은 수준의 칭찬처럼 보일 수 있음
  • 특정 프로젝트에 집중해야 하는 사람이 다른 팀을 도운 일로 칭찬받으면, 매니저가 본업에 집중하지 않는다고 볼 수 있음
  • 어떤 매니저는 동료의 뛰어난 성과를 위협으로 느낄 수 있음
  • 어떤 사람은 그런 방식으로 공개되거나 지목되는 것을 원하지 않을 수 있음
• 많은 사람은 매니저가 자신에 대해 어떤 피드백을 듣는지 스스로 통제하고 싶어함
• “X 프로젝트에서 한 일이 인상 깊었고, 매니저가 그 프로젝트에 깊이 관여하지 않아 네 기여를 못 봤을 수 있어 이 내용을 보내고 싶은데 괜찮은가”처럼 먼저 물어볼 수 있음

언제 특히 중요한가

• 매니저는 부하 직원의 모든 일을 항상 볼 수 없고, 보이지 않는 뛰어난 일은 승진 속도에도 영향을 줄 수 있음
• 특히 인정받기 어려운 일을 드러내는 데 효과적임
  • 다른 부서 사람이 회사에 큰 도움이 되는 기여를 했지만 그 사람의 매니저가 그 영향을 잘 모를 때
  • 비공개 채널이나 1:1로 몇 시간 동안 도와준 일이 프로젝트 성공에 크게 기여했을 때
  • 장애 대응처럼 눈에 잘 띄는 일보다 덜 보이는 문제 예방 작업
  • 인종차별, 성차별 등으로 과소평가되는 집단의 기여
  • 문서화, 코드 리뷰, 프로그래밍 외의 중요한 작업
  • 회사에서 원격 근무자의 일이 덜 보이는 경우
  • 지원 업무처럼 일반적으로 덜 인정받는 역할의 기여
• 주니어 동료가 잘하고 있을 때 그 기여를 강조하는 것도 좋은 방법임

승진 근거를 만드는 방식

• 승진에는 가치 있는 일을 했다는 증거가 필요하고, 매니저가 그 증거를 모두 직접 모을 시간이 항상 있는 것은 아님
• 본인이 직접 brag document를 작성할 수도 있지만, 동료가 성과의 가치를 설명해주는 진술은 신뢰도를 높이는 데 도움이 됨
• 동료가 승진 심사 대상이라는 사실을 알고 있다면 이런 피드백은 특히 유용함
• 뛰어난 일을 한 뒤 1년 뒤에야 인정받는 대신, 더 적절한 시점에 인정받도록 도울 수 있음

좋은 피드백을 쓰는 방법

• “잘했다”보다 무엇을 했고 어떤 영향이 있었는지 구체적으로 설명하는 편이 좋음
  • 예: “X가 이 시스템 설계를 훌륭하게 해냈고, 출시 후 6개월 동안 해당 규모의 프로젝트로서는 이례적으로 큰 운영 문제가 없었다”
• 승진에 도움이 되려면 그 사람이 자신의 레벨 기대를 초과 달성한 지점을 드러내야 함
  • 예: 아직 시니어 엔지니어가 아니지만 시니어 엔지니어에게 기대되는 종류의 일을 하고 있을 때
• 피드백 시스템을 통해 매니저에게 보낸 경우에도 당사자가 바로 보지 못할 수 있으므로, 메시지를 직접 보내주는 것이 좋음
• 당사자는 그 피드백을 나중에 다시 활용할 수도 있음

공개 인정과 동료 보너스

• Slack 채널이나 팀 미팅에서 좋은 일을 공개적으로 인정하는 방식도 도움이 될 수 있음
• 공개 인정은 동료의 신뢰도를 쌓는 데 도움이 되고, 협업 성과라면 인정받는 사람이 대화에 참여하거나 피드백 제공자에게 응답할 수도 있음
• 공개 칭찬을 싫어하는 사람도 있으므로 이 경우에도 먼저 물어보는 것이 좋음
• Google이나 동료 보너스(peer bonus) 제도가 있는 회사에서는 더 공식적인 인정 방식으로 peer bonus를 선호하는 사람들도 있음
• 이메일 대신 회사에 맞는 피드백 시스템이나 인정 방식을 사용하면 됨

누구나 할 수 있는 지원 방식

• 새로 입사했거나 더 시니어한 사람의 업무 효과성을 평가할 자격이 부족하다고 느껴도, 자신이 직접 도움받은 사실은 말할 수 있음
  • 예: “이 사람이 내 안전지대 밖의 프로젝트를 할 수 있게 도와줬다”
• 친구의 성과만 알리는 데 그치지 않고, 시간이 지나며 더 넓은 범위의 동료에게 관심을 둘 수 있음
• 뛰어난 일을 하는 동료를 살피고, 그 일이 인정받도록 만드는 실천이 중요함

더 넓은 후원 방식

• 동료를 끌어올리는 방법은 매니저에게 좋은 성과를 알리는 일 외에도 많음
• Lara Hogan의 what does sponsorship look like?는 후원의 여러 예시를 다룸
• Mekka Okereke의 “difficulty anchor” Twitter 스레드는 과소대표 집단을 지원하는 또 다른 방법을 다룸

[xguru]

2년전에 올라온 글이라, 긱뉴스에도 번역해서 올렸던 적이 있네요
동료가 일을 잘했다면, 그 동료의 매니저에게 말해주세요

[GN⁺]

Hacker News 의견들

• 먼저 괜찮은지 묻는 건 꽤 예리한 조언임. 모두가 공개적인 자리에서 칭찬받는 걸 좋아하는 건 아니고, 자기 업무 범위를 벗어나 도와줬다는 사실을 세세히 통제하는 관리자가 알길 원치 않을 수도 있음
  칭찬은 언제, 어떤 맥락에서 해야 적절한지 의식해야 함. 그래도 동료가 잘한 일을 고맙다고 말하고 칭찬하지 않는다면 팀에서 문제가 되는 쪽은 본인임
  동료의 나쁜 결과물이나 “내 방식이 아닌” 결과물을 공개적으로 꼬집고 있다면, “이렇게 접근한 점이 정말 좋았는데, 이런 방식도 생각해봤나요?”처럼 방향을 담은 칭찬으로 바꿔보는 게 좋음. “왜 이렇게 안 했나요?”보다 낫다는 뜻임
  행동을 칭찬하는 것이 결과를 칭찬하는 것보다 왜 나은지에 대한 흥미로운 자료도 많고, 아이들을 대상으로 한 내용이긴 하지만 잘 요약한 영상은 https://youtu.be/59gx55bNunU임

  • 그런 식으로 소통하는 사람들과는 같이 일하고 싶지 않음
  • “이렇게 접근한 점이 정말 좋았다”고 말하는 건 거짓말의 선을 넘는다고 봄. 차라리 “이 방식으로 하면 더 좋을 것 같아요”라고 말하는 편이 낫다
    상대를 멍청하다고 부르거나 불필요하게 객관성을 가장하는 건 나쁘지만, 억지로 웃으며 칭찬하는 척할 필요는 없음
  • 동료를 몰래 도와야 하는 상황이라면 기능 장애가 있는 직장이거나 최소한 아주 나쁜 관리자 밑인 것 같음. 그런 상사나 직장은 가능한 한 빨리 떠나겠음
    칭찬은 항상 괜찮아야 함. 나쁜 결과물에 대한 피드백을 칭찬처럼 바꾸는 것도 좋지 않은 생각임. 내 경험상 부정적 피드백은 솔직하고, 명확하고, 건설적이며, 비공개로 해야 함
  • 영상 초반에 나오는 연구는 논란이 있고, 대체로 재현에 실패했다고 보는 게 공정할 듯함
    해당 연구는 “Praise for intelligence can undermine children's motivation and performance”, Dweck & Mueller: https://pubmed.ncbi.nlm.nih.gov/9686450/
    논란 개요: https://en.wikipedia.org/wiki/Carol_Dweck#Criticism
    해당 논문에 대한 예전 HN 토론: https://news.ycombinator.com/item?id=12233571
  • 이건 매우 스타일과 주관에 따른 해석임. 모든 직장 문화와 모든 사람이 이런 소통 방식을 선호하지는 않고, 직접적인 소통 방식을 두고 “네가 나쁜 사람”이라고 붙이는 딱지를 불쾌하게 여기는 사람도 많음
    나는 칭찬받기 위해 일하지 않고, 개인적 직업 윤리로 높은 기준을 유지함. 동료가 나를 인정하든 말든 거의 신경 쓰지 않고, 경영진은 노력보다 손익을 봄
    영상이 아이들과 관련된다는 점도 놀랍지 않음. 이런 감정 중심 접근은 성인들이 각자 왜 그 자리에 있는지, 고용 조건이 무엇인지, 어떤 목표를 향해 일하는지 알고 있어야 하는 전문 직장에는 어울리지 않음. 기본 소통 방식이 이렇게 유치해지는 건 오히려 모욕적으로 느껴짐
    “왜 이 방식으로 안 했나요?”가 제안된 대안보다 훨씬 짧다는 점도 보임. 일반적으로도 마찬가지로, 청중에 맞춰 조정한 소통은 정확성·간결성·명확성 원칙을 따르는 소통보다 훨씬 장황하고 작성하기도 힘듦
    그런 조직들이 표현을 끝없이 바꾸느라 낭비하는 시간을 상상해보면 됨. 감정 상태를 관리하는 건 듣는 사람이나 읽는 사람의 책임이어야 하고, 말하는 사람의 일은 아이디어를 최대한 명확하고 간결하게 전달하는 것이어야 함. 그게 더 효율적임

• “먼저 물어보라”는 관점에는 동의하지 않음. 맥락 속에서 칭찬하는 게 도움이 되기 때문임
  누군가 훌륭한 일을 했으면 그 사람의 관리자에게만 말하지 말고 모두에게 말해야 함. 스탠드업에서 그 사람이 어제나 지난주에 한 일을 말한 직후, 공개적으로 분명하게 말하면 됨
  “Joe가 그 모듈에서 한 작업이 정말 훌륭했다는 걸 말하고 싶어요. 고마워요!”라고 하는 건 아주 쉽고, 좋은 영향력이 될 수 있음
  좋은 일을 고르게 칭찬하는 사람이 되면 다른 사람들이 더 기분 좋게 일하고, 더 잘 일하고, 진짜 우정도 쌓기 쉬움. 사람들은 자신이 열심히 일하고 있을 때 대체로 알고 있음
  칭찬은 공개적으로, 교정은 비공개로 해야 함

  • “물어보라”는 조언은 특정 이유에서는 정말 유용하다고 봄. 다만 모두에게 해당하지 않을 수도 있음. 엔지니어들은 사회적 신호를 극도로 못 알아차릴 때가 있음
    나는 시간과 장소, 표현을 판단해서 굳이 먼저 물어보지 않아도 되는 칭찬을 할 자신이 있고, 언제 먼저 물어야 하는지도 꽤 잘 판단한다고 느낌. 사람을 알아가는 것도 잘하고, 개방적이고 선의가 있어 보이게 만드는 것도 잘함. 거창하게 말하면 신뢰 관계를 만드는 것에 능숙함
    하지만 사회적 상호작용과 상황 판단을 정말 어려워하는 사람도 있음. 복잡한 상황을 잘 판단하지 못하는 사람에게는 “그냥 물어보라”는 조언이 아주 가치 있음. 모두에게 적용되는 건 아닐 뿐임
  • “도와주면 안 되는 일을 도와줬는데 그걸 칭찬해서 해고되면 어떡하나?” 같은 예외 상황을 떠올리는 것 같지만, 그건 예외임. 대부분의 합리적 상황에서는 상식과 분별을 발휘하면 됨
    원칙적으로 자신을 도와준 사람에 대해 좋은 말을 전하면 됨. 그렇게 복잡한 일이 아님
  • 일반적인 조언으로는 잘 모르겠음. 나는 칭찬이나 찬사를 받으면 꽤 불편하고, 특히 그룹 상황에서는 더 심함. 창피하고 어색하게 느껴짐
    공개적으로 칭찬하지 말라는 뜻은 아님. 다만 분위기를 읽어야 함. 늘 그렇듯, 특히 사회적 상호작용에서는 맥락이 핵심이고, 대화 상대를 알아야 함
  • 선행은 벌을 받는다는 말이 있음. 계층화된 위계적이고 준권위주의적인 기업 사회 구조에는 이상한 유인이 존재함
  • “칭찬은 공개적으로, 교정은 비공개로”에 1000% 동의함. 그래도 큰 그룹 앞에서 칭찬해도 괜찮은지 당사자에게 먼저 물어봄. 편안하게 받아들일 수 있는지 확인하기 위해서임
    물어보지 않았다가 사람들을 당황하게 만든 적이 있음. 그룹에서 받는 칭찬에 대한 반응은 사람마다 다름

• “먼저 물어보라”는 제안에는 동의하지 않음. 그건 과정에 마찰을 추가해서 덜 자연스럽게 만들고, 실제로 칭찬하려는 동기를 줄일 수 있음
  대신 칭찬받는 직원에게 해가 되지 않을 피드백을 함. 이런 글을 쓰는 데는 요령이 있는데, 보통 내 입장과 내 문제가 어떻게 쉬워졌는지를 중심으로 쓰면 됨

  • 나는 관리자에게 그들의 직속 직원과의 좋은 상호작용을 알려줌. 먼저 물어볼 생각은 한 번도 못 했지만, 이제는 그럴 수도 있겠음. 다만 아래 같은 이유로 칭찬을 안 하는 상황은 정말 화가 남
    “다른 팀 사람을 도와서 즉석 동료 보너스를 받았다는 이유로 관리자가 질책했다”는 사례 말임
    이건 내가 끝까지 고수할 원칙임. $this_company의 사람들은 한 팀이고, 서로 돕는 일은 건강한 팀과 조직을 만드는 데 핵심임. 일정에는 여유가 있어야 하고, 그 여유는 서로 돕는 데 쓰여야 함
    물론 균형은 필요하지만, “막힌 걸 풀어주는 데 한 시간 도와줄 수 없고, [일정을 확인한 뒤] 다음 분기쯤… 가능할지도요” 같은 반응은 조직에 생각보다 훨씬 큰 해를 끼침
  • 먼저 묻는 건 말이 됨. 그 사람의 관리자가 당신 문제를 우선순위에서 낮추거나 중단하라고 지시했을 수도 있는데, 그 사람이 자기 판단으로 그래도 도와줬을 수 있기 때문임
    그런 상황에서 공개적으로 칭찬하면 그 지시를 약화시키고, 관리자가 이번 한 번은 괜찮다고 생각했더라도 “X가 필요하면 John에게 가라”고 광고하고 싶진 않을 수 있음
    긍정적인 리뷰가 온라인에 올라온 뒤 해고된 직원 얘기도 있음. “우리 서버 Marie가 정말 대단했어요! 아들 생일에 무료 아이스크림까지 줬어요!” 같은 식임
  • 그 입장은 이해함. 나도 전에는 허락을 구할 생각을 해본 적이 없음. 하지만 이 부분의 의도를 존중해서, 다른 사람에게 영향을 줄 일을 하기 전에는 분위기를 읽는 것이 좋은 생각이라고 봄
  • 조직에는 두 종류가 있다고 봄
    1. 훌륭한 일을 하는 사람에게 더 많은 일을 주는 조직
    2. 훌륭한 일을 하는 사람에게 더 많은 책임을 주고, 코칭하며, 승진이나 실질적 인정으로 이어지는 길에 올려놓는 조직
       1번 조직에서 일하는 사람들은 아무 이득 없이 일만 더 배정될까 봐 두려워할 수 있음. 때로는 배정되는 일이 자기 몫을 하지 않는 다른 사람들이 해야 할 일이기도 함
  • 무엇이 해를 끼칠지 절대 확실히 알 수 없음. 그냥 물어보면 됨. 복잡한 일이 아님

• 맞음. 이런 행동은 내가 일하고 싶은 조직을 만드는 데 도움이 됨
  그걸 강화해야 함. 회사에 물질적 동기를 제공할 수는 없음. 물론 회사의 최대 고객이기도 하다면 다르겠지만. 대신 경영진에게 강화 피드백을 줄 수는 있음
  XYZ 동료가 왜 도움이 됐는지 정량화하면 됨
  경영진이 듣지 않는다면, 신경 끄면 됨. 관리자가 정말 잘못된 방식으로 반응하는 순간을 알아차리고, 다음에는 발로 투표하면 됨

  • 동료를 버스 밑으로 밀어 넣지 말아야 함. 본인에게는 그 대의가 가치 있어 보일 수 있지만, 다른 사람을 본인의 십자군에 강제로 끌어들이면 안 됨

• 동료에게만 해당하는 게 아님
  고객지원 담당자가 내 문제를 정말 잘 해결해줬다면, 그날 도움에 얼마나 감사했는지 관리자에게 말해도 되는지 물어봄
  지금까지는 모두 꽤 기뻐하는 것처럼 들렸음
  관리자에게 그 사람이 내 문제를 정말 잘 해결해줬고, 고객으로서 기쁘게 만들었다고 말함. 관리자들도 그런 얘기를 듣고 꽤 기뻐하는 듯했고, 일부는 그 피드백을 직원 파일에 추가하겠다고도 했음

• 지금 참여 중인 연구실은 처음에는 분위기가 좋았지만, 함께 일하기 덜 pleasant한 사람들도 몇 명 있었음. 지도교수가 적합한 사람을 뽑는 데 큰 역할을 했지만, 우리도 서로를 많이 지지해왔음
  누가 먼저 시작했는지는 모르겠지만, 모두가 서로를 좋게 말했고, 서로의 작업을 비판할 때조차 시간이 지나며 분위기가 좋아졌음. 팬데믹 내내 인간 대상 데이터를 다루며 일했다는 점을 생각하면 이건 큰 의미가 있음
  지금은 연구실에서 같이 일하기 싫은 사람이 떠오르지 않음

• 웃긴 게, 나는 팀 리드인데 팀의 한 공동 개발자가 명백히 나를 대체하거나 어떤 식으로든 내 리드가 되고 싶어 하는 것 같음. 여러 번 농담까지 했음
  가끔 그가 내 작업을 칭찬하지만, 마치 내가 이제야 그의 전문성 수준에 가까워졌다는 식으로 들림. 설명하기 어렵고, 내가 너무 깊게 읽는다고 할 수도 있겠지만, 진짜 그렇다고 확신함
  따로 반응하진 않았음. 어쨌든 그는 꽤 실력 있고 함께 일하기도 재미있음. 그냥 그런 일 중 하나라고 봄

• 여기 댓글들은 이 주제가 얼마나 문화적 맥락에 따라 달라지는지 잘 보여줌
  참고로 글쓴이는 북미 배경을 가진 사람임

  • 여기 댓글들을 보면 학대하지 않는 직장을 구해야 할 것 같음. 칭찬이 상사나 동료에게 불리하게 쓰일까 봐 그렇게 겁먹을 필요는 없어야 함. 늘 뒤를 살피느라 시간을 보내면 일을 해낼 수 없음
    2020년 스레드를 보니 대화가 꽤 다르게 흘러갔다는 점이 흥미로움. 특히 스택 랭킹과 관련해서는 회사의 절차에 더 초점이 있었던 느낌임. 여기서는 훨씬 더 “개인적”이고, “난 그냥 직설적으로 듣고 싶다”거나 “칭찬이 의도치 않게 사람을 해칠 수 있다”는 쪽에 가까움
    객관적으로 어느 쪽이 더 낫거나 나쁘다고 하긴 어렵지만, 하나는 다른 하나보다 좀 더 표면적으로 느껴짐
  • 당신 문화권의 일화도 들어보고 싶음
    북미 문화에서는 유치원 같은 단계에 도달한 듯함. 최우선 지침이 감정을 보호하고 “해”를 줄이는 것이 됨. 민간 부문에 대한 학계의 영향력이 커진 탓일 수도 있다고 의심함

• 아직 피드백을 주지 않고 있다면, 시작했을 때의 이익은 아주 큼. 묻지 않고 피드백을 줬다가 상대에게 해가 될 위험은 매우 작음
  이 조언을 따르려는데 피드백이 “역효과”를 낼까 두렵다면, 그렇게 봐야 함. 위험이 0은 아니지만, 핵심은 “피드백이 역효과를 내서 사람을 해칠 수 있다!”가 아니라 피드백을 시작해야 한다는 것임
  관리자에게 더 많은 칭찬을 전달하는 이익은 잘못 전달된 칭찬의 위험을 훨씬 능가함
  그러니 의심스러우면 해보는 쪽이 좋음. 묻는 것도 도움이 되고, 나는 확신이 없을 때 보통 먼저 당사자에게 피드백 문안을 보내서 어떤 식으로 수정하고 싶은지 물어봄. 다른 쪽에 초점을 맞추고 싶다면 괜찮음. 핵심은 감사를 표현하고 그 사람에게 도움이 되는 것임

  • 이상한 해석임. 원치 않는 피드백에는 위험이 있지만, 그냥 묻는 비용은 거의 0에 가까움. 왜 굳이 위험을 감수함?

• 여기에 하나 덧붙이자면, 동료가 훌륭한 일을 했을 때는 그 동료에게 직접 말해야 함. 내가 잘한 일을 누군가 알아봐 주면 기분 좋음
  모든 걸 관리자에게 보고할 필요는 없음. 때로는 그냥 그 사람의 작업을 칭찬하거나 노력에 감사하면 됨