同僚が素晴らしい仕事をしたなら、その同僚のマネージャーに伝えましょう
(jvns.ca)- マネージャーが直接見ていない同僚の成果と影響を伝えると、評価や昇進の議論で重要な根拠になり得る
- 良いフィードバックであっても、本人の同意なしに共有すると、成長目標や役割期待と食い違って逆効果になることがある
- 部門間の協業、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スレッドは、過小代表グループを支援する別の方法を扱っている
2件のコメント
2年前に投稿された記事なので、GeekNewsでも翻訳して掲載したことがありますね。
同僚が仕事で素晴らしい成果を上げたら、その同僚のマネージャーに伝えてください
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 があのモジュールで行った作業は本当に素晴らしかったと言いたいです。ありがとう！」と言うのはとても簡単で、良い影響力になり得る。
良い仕事を公平に褒める人になれば、他の人たちはより気分よく働き、よりよく働き、本当の友情も築きやすくなる。人は、自分が一生懸命働いているときにはたいてい分かっている。
称賛は公に、修正は非公開で行うべきだ。
私は時間や場所、表現を判断して、わざわざ先に聞かなくてもよい褒め方をする自信があるし、いつ先に聞くべきかもかなりうまく判断できると感じている。人を知るのも得意だし、オープンで善意があるように見せるのも得意だ。大げさに言えば、信頼関係を築くことが得意だ。
しかし、社会的なやり取りや状況判断が本当に難しい人もいる。複雑な状況をうまく判断できない人にとっては、「とにかく聞け」という助言は非常に価値がある。全員に当てはまるわけではないだけだ。
原則として、自分を助けてくれた人について良いことを伝えればいい。そんなに複雑なことではない。
公の場で褒めるなという意味ではない。ただ、空気を読む必要がある。いつもそうだが、特に社会的なやり取りでは文脈が重要で、話し相手を知っていなければならない。
聞かなかったせいで人を困惑させたことがある。グループで受ける称賛への反応は人によって違う。
「まず本人に聞くべき」という提案には同意しない。それはプロセスに摩擦を加えて不自然にし、実際に褒めようという動機を減らしてしまう可能性がある。
代わりに、褒められる社員に害が及ばないフィードバックをする。こういう文章を書くにはコツがあり、たいていは自分の立場と、自分の問題がどう楽になったかを中心に書けばよい。
「別チームの人を助けて即席の同僚ボーナスをもらったという理由で、マネージャーに叱責された」という事例のことだ。
これは私が最後まで譲らない原則だ。$this_companyの人たちは一つのチームであり、互いに助け合うことは健全なチームと組織を作るうえで核心である。スケジュールには余裕があるべきで、その余裕は互いに助け合うために使われるべきだ。
もちろんバランスは必要だが、「詰まっているところを解消するのに1時間手伝うことはできず、[スケジュールを確認したうえで]次の四半期あたりなら……可能かもしれません」のような反応は、思っている以上に組織へ大きな害を与える。
そういう状況で公に褒めると、その指示を弱めてしまうし、マネージャーが今回だけはよいと考えていたとしても、「Xが必要ならJohnのところへ行け」と宣伝したくはないかもしれない。
好意的なレビューがオンラインに上がった後に解雇された従業員の話もある。「私たちのサーバーのMarieは本当に素晴らしかったです！息子の誕生日に無料のアイスクリームまでくれました！」というようなものだ。
1番の組織で働く人たちは、何の見返りもなく仕事だけをさらに割り当てられるのではないかと恐れるかもしれない。時には、割り当てられる仕事が、本来自分の分を果たしていない他の人たちがやるべき仕事であることもある。
その通り。こういう行動は、自分が働きたい組織を作る助けになる。
それを強化すべきだ。会社に物質的な動機を提供することはできない。もちろん、自分がその会社の最大顧客でもあるなら別だが。その代わり、経営陣に強化フィードバックを与えることはできる。
XYZの同僚がなぜ助けになったのかを定量化すればいい。
経営陣が聞かないなら、気にしなければいい。マネージャーが本当に間違った形で反応する瞬間を見極め、次は足で投票すればいい。
同僚に限った話ではない。
カスタマーサポート担当者が私の問題を本当にうまく解決してくれたなら、その日の助けにどれほど感謝しているかをマネージャーに伝えてもよいか尋ねる。
これまでは皆かなり喜んでいるように聞こえた。
マネージャーには、その人が私の問題を本当にうまく解決してくれて、顧客として満足させてくれたと伝える。マネージャーたちもそういう話を聞いてかなり喜んでいるようで、そのフィードバックを従業員ファイルに追加すると言った人もいた。
今参加している研究室は、最初は雰囲気がよかったが、一緒に働くのがそれほど pleasant ではない人も何人かいた。指導教員が適切な人を採用するうえで大きな役割を果たしたが、私たちも互いにかなり支え合ってきた。
誰が始めたのかは分からないが、皆が互いを良く言い合い、互いの仕事を批判するときでさえ、時間が経つにつれて雰囲気が良くなっていった。パンデミックの間ずっと人間対象データを扱って働いていたことを考えると、これは大きな意味がある。
今は研究室で一緒に働きたくない人が思い浮かばない。
面白いことに、私はチームリードなのだが、チームの共同開発者の一人が明らかに私に取って代わりたい、あるいは何らかの形で私のリードになりたがっているように見える。何度も冗談まで言っている。
時々彼は私の作業を褒めるが、まるで私がようやく彼の専門性のレベルに近づいたと言っているかのように聞こえる。説明しにくいし、私が深読みしすぎていると言われるかもしれないが、本当にそうだと確信している。
特に反応はしていない。いずれにせよ彼はかなり腕があり、一緒に働くのも楽しい。ただ、そういうことの一つだと思っている。
ここのコメントは、この話題がどれほど文化的文脈に左右されるかをよく示している。
ちなみに筆者は北米の背景を持つ人だ。
2020年のスレッドを見ると、会話の流れがかなり違っていたのが興味深い。特にスタックランキングに関しては、会社のプロセスにより焦点が当たっていたように感じる。ここではずっと「個人的」で、「私はただ率直に聞きたい」とか「褒め言葉が意図せず人を傷つけることがある」という方向に近い。
客観的にどちらが良い悪いとは言いにくいが、一方はもう一方より少し表面的に感じられる。
北米文化では幼稚園のような段階に達したように見える。最優先の指針が感情を守り、「害」を減らすことになっている。民間部門に対する学界の影響力が大きくなったせいかもしれないと疑っている。
まだフィードバックをしていないなら、始めたときの利益は非常に大きい。聞かずにフィードバックをして相手に害が及ぶリスクはとても小さい。
この助言に従おうとしていて、フィードバックが「逆効果」になるのが怖いなら、そう考えるべきだ。リスクはゼロではないが、要点は「フィードバックが逆効果になって人を傷つける可能性がある！」ではなく、フィードバックを始めるべきだということだ。
マネージャーにより多くの称賛を伝える利益は、誤って伝わった称賛のリスクをはるかに上回る。
だから迷うなら、やってみるほうがよい。尋ねることも助けになるし、私は確信がないとき、たいてい先に本人へフィードバック文案を送って、どのように修正したいかを尋ねる。別の点に焦点を当てたいなら、それでもよい。大事なのは感謝を表し、その人の助けになることだ。
ここに一つ付け加えるなら、同僚が素晴らしい仕事をしたときは、その同僚に直接伝えるべきだ。自分がうまくやったことに誰かが気づいてくれると気分がいい。
何もかもマネージャーに報告する必要はない。時には、ただその人の仕事を褒めたり、努力に感謝したりすればよい。