97 Things Every Engineering Manager Should Knowの32-59まで読んだ

マスタカと言えばエンジニアリングマネージャー
そんなわけで知るべきことは多いため本書を読んでみた
32-59を読んだのでまとめる

以下、内容

・4つのレイヤーでのコミュニケーション
下のレイヤーがないと上が支えられない

misson
組織全体で何をするか
無限大の期間
strategy
どうやって組織の一部として働くか
次の4半期やること
tactics and process
どうやってチームが一緒に働くか
今月やること
execution
個人ワーク
今日やること

・聞いたら気をつける言葉
justやsimplyを使った場合、技術的にどのぐらい難しいか忘れさせるので注意
日本語だと「簡単に」や「とりあえず」とかかしら
他にもshouldやsoonやveryやtrivialも注意
日本語だと「すべき」や「すぐに」や「単純な」とかかな

このような言葉が出てきたら、もう少し詳細に深掘りする必要がある

・プロセスを進化させる
悪いプロセスは問題の定義が間違ってる
結果として非常に些細な良いことのために、多大な不便を引き起こしてる

良いプロセスを進化させることはマネジメントとして一番レバレッジをかけれる行為の一つ

・良い方向を向ける
チームの仕事に対して優先順位をつけること
そのため、以下を定期的に問いかける
・適切に動けているか
・予期した通りの進捗が出ているか
・チームが実施していることの優先順位を変更する情報を集める

・より良い1on1
1週間を通して新たに話したいことがないならキャリアについて話すべき

基本的には以下に従う
20分は個別のアジェンダについて話す
10分はキャリアについて話す

・急速な変化を通常に導く
変化は永遠に終わらない
安定した状態になったら、それはニューノーマル
変化の激しい業界なので変化とニューノーマルを繰り返す

・面接では技術以外も重要
コミュニケーションスキルだけでなくチームワークも重要
ミスを認めることができる

インタビューではエンジニア以外のデザイナやPMを混ぜる
見下したり、遮ったりしないか等の振る舞いを確認する
技術スキルがあっても態度等が問題だとすべてを台無しにする可能性がある
なので技術以外の評価も重要である

・新しいチームをチームと感じられるようにする
最初にやるべきことは、どうやってチームを一緒に働かせるか
次にやるべきことは、一緒に働くことで楽しめるようにする
個々の幸せに拘らず、全体の幸せを考える

・メンバーがどこで立ち止まるか注意する
少し観察するだけでどこで立ち止まるか分かる
クセ等をメモして次の1on1でフィードバックしてあげよう

・どうやって新卒のエンジニアを助けるか
短期のゴールと長期のゴールについて話す
技術だけでなく、コミュニケーショんの達成についても記録を取り褒める

・メンバーをAPIと考える
メンバーをAPIのサービスだと考える
最初にすべきことはどんなデータを投げるとどんなデータが返ってくるか
を確認する
メンバーを新しい機能に置き換えたり、不明な機能が分かったら
マイクロサービスのスケールや成長ができたことになる

昨日まで動いていたけど突然動かなくなることがある

同様に、メンバーは上司に対してどんなデータを送るとどんなデータが返ってくるか確認してくる
そして、メンバーとのサービスレベルを定義しよう

・エンジニアとマネージャーの違い
エンジニアは白黒がはっきりする
マネージャーは白黒つかずにグレーな部分が多い

・メンタルモデルで決断を改善する
メンバーが色々言ってくるのでマネージャーの仕事は以下を聞くこと
何を言いたいんですか？
何が実際に起こっているんですか？

また、相手によっては質問に回答すべきか相手に考えさせるかを考える

・マネージャーの引き継ぎ
1on1on1を実施する
これでメンバーがいる形で情報を適切に引き継げる
キャリアやプロジェクトの状態等

・エンジニアからマネージャーへ
どうやって技術を保ち続けるか
これは第一線で活躍していた人からよくある質問
だけど回答がなさそう・・・・マネージャーにさっさとなれとのこと

毎日一番影響を与えたことについて記録をつける
こうすることで自身に寛大になれる

・みんなが管理職になりたいわけではない
マネージャーになって辛いと思った場合の選択肢は以下
・耐えるか
・会社内で異動するか
・会社を辞めるか

マネージャーに一度なった後なので
エンジニアに戻るよりは面目を保つために会社を辞めることが多い
そうなると会社は貴重な戦力を失う

本書はとてもためになりました
まだまだ続くよ