エンジニアマネージャーとなり、一番悩み困ったのがネガティブ・フィードバックでした。
指摘したり課題を伝えるのって難しいですよね。
だれかのなにかの役に立てることができれば幸いです。
ネガティブ・フィードバック
目的
育成、改善、課題解決のために行うものです。
指摘・指導ですね。
なにが難しい？
- 課題の特定
- 伝え方
- 伝えるときの気持ちの持ちよう
課題の特定
チームリーダー自体はポジティブ・フィードバックはするものの、ネガティブ・フィードバックはほぼしたことがありませんでした。
ん？と思うことがあったとしても、「人それぞれやしな」「この言い方はよくないんじゃない？」のような主観で捉えていました。
また課題だと思うことをうまく言語化するのが難しかったです。計画的ではないように見えるがなんて言ったらいい？みたいな（※今回はこの話はしません）
マネージャーになり、メンバーの振る舞いや言動を見て感じたことがあったとしても
「それって本当に課題なのか？」
「私の価値観と遠いだけなのかも」
「なんか傷ついたけど正しいことを言われている気がする・・・」
「課題に感じるがなんて言ったらいいかわからない・・・」
など、ポイズン状態でした。（古くて伝わらない）
というのをある先輩に相談したところ
「大事なのは事実と主観(解釈)をわけること」
とアドバイスをもらいました。
私はこの２つがごっちゃになっており言うべきことなのか・・？の判断に時間がかかり、タイミングが遅れてしまい効果的にフィードバックができていませんでした。
またマネージャーとして指針を決めると良いと聞きました。
私が決めた指標
- 楽しく成長して働いてほしい
- チームワークを重視する
- チームで成果を出す
- ルールは基本的に守る
- ただMUSTにしない、臨機応変に対応する
- 企業理念や行動指針を大切にする
- 自分のためではなく相手のための課題と捉える
例：言い方に問題があるように感じた
→なぜか？→感じがわるく感じた→言い方として問題があるか？他の人だと何か感じそうか？→特になさそう→問題なし！
→なぜか？→それによってメンバーが気にしてしまい、パフォーマンスがでなくなっている→問題なのでフィードバック
なぜそう思うか？自分の主観で捉えていないか？それによってなにかに影響したか？を問いかけて課題を特定しています。
このやりかたにしてからアンガーマネジメントもできるようになってきました。
また伝える前に大事なのが相手と前提をあわせることです。
計画性が足りてないね、という話をしたときに「計画性がある状態というものはなにか」をすり合わせておくとよいです。
この前提がずれているとこのあとの伝え方を工夫しても伝わらないです。
伝え方
耳が痛い話をするので、受け取る側は受け入れにくいこともありますよね。
実際自分も関係性がない人に指摘されたときにあまり受け入れることができませんでした。
フィードバックする目的は改善や成長のためなので、改善しよう！と思ってもらうことが重要ですよね。
なのでまずは関係構築が大事だなと思います。
- 相手を知ること、自分を知ってもらうこと
- ポジティブ・フィードバックを普段から伝えていること
あなたのことを承認していますよ
あなたのことを応援していますよ
が伝わっている前提でネガティブ・フィードバックを行うのが大事だと思います。
伝え方は以下を大切にしています。
- 1on1の場や見えないところで行う
- フィードバック内容は整理してどう伝えるか考える
- 相手を思う気持ちを持って話す（押し付けない）
- 自分の感情も混ぜて話す
- こうしてくれるととても助かる等
- 自分の感情も混ぜて話す
プラスαとして、相手の価値観に沿ったフィードバックができるとなおよいと思います。
それについてはまた別の機会にでも。
伝えるときの気持ちの持ちよう
勇気がいりますよね・・・・！
伝わるかなー、落ち込んだりしないかなー、また伝えたときの相手の反応など
気持ちの面でちょっと緊張感がありますよね。
これもわりとマネージャーになって長く悩んだことになるのですが、
「変えられるものと変えられないものを区別したほうがいい」
と先輩からアドバイスをもらいました。
全然響かないとか逆ギレされちゃうこともあるかもしれません。
相手を変えることはできません。自分の振る舞いは変えることができます。
なので響かなくても逆ギレされても気にする必要はないのです。
次どうやったら伝わるかなと考えて動くだけでよい。
とは言っても気にはなるのですが、このアドバイスをもらってからは勇気もでるし、ナイスチャレンジと自分にもフィードバックできるようになりました。
まとめ
今でも苦手ですし、できることならやりたくない思いはありつつ、
でも役割なので頑張っています。
フィードバックする前に課題を整理→伝え方を考える→伝える→振り返る。エンジニアリングも似たようなもの。
ユーザに使ってもらえる機能を作るのも難しい。
そのために調査したりスキルを身につけたり、やっていることは同じなんだと。
上司との1on1や評価面談でこういった話をするのですが、書き起こすことはなかったので
アウトプットしてみて、言語化できてない部分に気づけたりして記事書いてみてよかったなーと感じました。
次回はポジティブフィードバックについて書こうかな〜と思ってます！