Engineering Managerはスーパーマンじゃない
とても良い内容で３回位聞きました。人に共有するのにpodcastはなかなか難しくて（聞いてくれない）、感想を交えながらまとめてみました。
あ、ちなみに僕はマネージャーではなくいちエンジニアです。
マネージャーとは？
マネージャーはただの役割なのに上の人と呼ばれがち。求められることが多く見えてしまって優秀な人がマネージャーを避けがち。高校野球や芸能人のマネージャーを上だと思うことはない。
僕はマネージャーではないのですが、マネージャーに対してそう思ってしまうことはあります。弊社の場合上長なので、まぁ間違ってない気もします。
ただ、やっぱりジョブディスクリプションはっきりしてない問題が大きいと思ってます。期待していいことが何かわからないんですよね。やること、やらないことをはっきりさせるのがいいんじゃないかなぁと思い始めたところです。
マネージャーをなぜ上に思ってしまうかですけど、マネージャー→管理する人→管理者→管理職ってことなんじゃないかなぁ。管理者までなら野球とか芸能人のマネージャー感覚がありますけど、管理職って偉い人ですもんね。
失敗できることが大事
会社が若い人に与えられる最大の福利厚生は小さく失敗できること
これはとてもいい考え方だなぁと思いました。
良い組織は「失敗しそうだな」がマネージャーから見えやすい。悪い組織は「失敗しそうだな」がマネージャーから見えにくい。失敗を隠そうとしてしまう。
ヤバイときにヤバイと言えなくなってしまう。特に非エンジニアに対してのコミュニケーションで隠してしまう。そうすると非エンジニアからはいついつまでにやれとしか言えなくなり、エンジニア側はバッファーを積むようになる。
ただ、バッファーを積んだところで学生症候群で遅れるだけなので、結局また遅れてしまう。結果なにも成し遂げられない。
心理的安全性
言いにくいことを言えるようにする。BBQとかして仲いいですよ！っていうのだけじゃ意味ない。隠しがちな部分を心理的安全性を担保して嫌なことでもを言う必要がある。
すごくアットホームな雰囲気でよく飲みに行くけどプロジェクトの問題について何も話さない。誰も言いにくいことを言わない。心理的安全性はそもそも言いにくいことを言うためのもの。
「喧嘩するほど仲がよい」という言葉がありますが、喧嘩しないから仲が良いわけではなくて、仲が良くないと喧嘩出来ないんですよね。絶縁してしまうから。
ここで言う喧嘩はもちろんムカついたとかそういう話ではなくて、喧々諤々議論することを言ってます。
構造を理解して勇気を発揮する。このままじゃヤバイってときに勇気を持って発言する。誰かが必要なときに、その人を連れてこれる。そういう勇気が大事。
これが本当にエンジニアリングマネージャーに求められること。他のスキルはそこまで求められないのかも。
極端に言うとエンジニアじゃなくてもいい。エンジニアの人に話を聞いてもらうための関係づくりが、元エンジニアだったり技術力があったほうがやりやすいだけ。
これも結局の所、ジョブディスクリプション問題な気もします。何を期待されていて、何をする役割なのかが明確になっていないんですよね。
責任とは
２種類の責任を分けて考える。responsibilityとaccountability。responsibilityはやると言ったことをやる責任、accountabilityは説明責任。何よりもマネジメントに求められるのはaccountability。
確かに責任を取るとはどういうことなんだろう。辞任しか思いつかない。日本ではそもそもレイオフされないのでここは分けて考える必要がありそう。
何よりもマネジメントに求められるのはaccountability。状況を正しく報告することは、例えば経営陣からするとオプションを考えるなど、出来ることがある。状況を隠し続けてどうにもならなくなってからだと「なんとかしてくれ」としか言えなくなると。
これは経営陣からすると当然のこと。またaccountabilityはマネージャーでなくても、みんなにあるものと思っている。ただ、相手がマイクロマネジメント大好きな人だったりすると、話すと面倒なことになるし、ただでさえ時間無いのにさらに突っ込まれて時間取られそうだなーと思ってしまうことは正直ある。
おわりに
これがとっても楽しみです！
いいなと思ったら応援しよう！
