97 Things Every Engineering Manager Should Know: Collective Wisdom from the Experts
の1~31まで読んだ
マスタカと言えばエンジニアリングマネージャー
そんなわけで知るべきことは多いため本書を読んでみた
以下、内容
・チームの改善をしない場合の成功
チームの改善を通しての成功でない場合
マネージャーは何も貢献しておらず、ただ良いメンバーに依存してるだけ
これは分かる
・生産性を上げるためにマネージャーがやるべきこと
メンバーの作業を中断せずにコミュニケーションをできる仕組みをつくる
定期的にリリースできるようにスコープを分解する
将来の負債にならないようにビジネスとのバランスを取る
優先度をつける
・キャパシティを100%にするとどうなるか
調査する時間を取られたり
出てきた問題に対応したりするので
キャパシティ100%を出すことはできない
100%になってるのであれば、それは120%以上のキャパシティで実施してる
・良い仕事をしてるマネージャーか見分ける方法
1週間休みをとるとどうなるか
仕事に戻った時に何が起こってるか確認する
リーダーなしで問題に対応できるか
全ての問題がリーダーに来るなら、時間が取れなくなる
継続的にリリースできているか
チームは自己改善しているか
・リーダーはロールモデル
どんな行動が悪い振る舞いで良い振る舞いかを
ロールモデルとして表す必要がある
・1on1をクリエイティブに変える10のこと
頻度
時間
誰が主催するか
どこでやるか
何をお互いに準備するか
アジェンダ
ゴール
MTGの長さ
コミュニケーションの方法
MTGと一緒に何かするか(通勤や飯)
・部下のキャリアについて
メンバーが欲しいものを理解して機会を与えること
キャリアパスを作ることではない
・同じことを言い続ける
メンバーは一度では理解できないので7回は言い続ける
・状況を伝える
傘となりチームを守る場合、無駄な精神的ストレスに晒される
なので状況を伝えてチームで解決策を模索するように働きかける
・上位者へのコミュニケーション
Xについて話します。なぜならYだからです
Xの詳細はこれです
あなたにはZをして欲しいです。Xを達成するために、なぜならYだからです
・リーダーのレベルアップ
影響範囲が広がった時
マネージャーはレベルアップしたことになる
例えば2チームを担当するようになったとき
このときにもっとリードする方法を学ぶ必要がある
なぜなら時間がないからだ・・・・・
やるべきことは
優先順位をつけて意図を伝えること
優先順位をつけて委譲すること、次のリーダーを育てること
そして、良いリーダーはnoと言うこと
・問題社員
時間をかけずにすぐの対応が必要
パフォーマンスが低い場合、コミュニケーションで気づかせる必要がある
長期間独房に入れるのはとてもストレス
問題社員はスキルがいかせるより良い場所に行かせるべきである
・5W1H
カンパニーのプロダクトはWhat
顧客はWhy
従業員はWho
文化はHow
・文化
ワールドクラスの候補者でも採用しない
なぜなら文化に合わないからだ!
これができないなら文化はまだ定義できてない
・採用候補者
スキルは分かりやすいがキャッチアップも簡単なエリア
価値観や能力は直接は見えない
能力は詳細を見るや大局を見ること。かなり頑張らないといけないもの
価値観は例えば継続して学ぶ価値観の会社であれば、どうやって学んできたか尋ねる質問が有効
うまく答えられなければ採用は見送った方が良い
・コーディングテスト
どうして今回の実装にしたかを聞く
・組織に足りない人は誰か
エンジニアのヘッドが組織の仕事を委譲できない
=> ディレクターを採用
ディレクターがマネジメントに時間を取られ、組織に貢献できていない
=> マネージャーを採用
マネージャーが事象に対して時間を取られてる
=> 部下を減らす
マネージャーが技術リードに時間を取られる
=> テックリードを採用
マネージャーがPRに時間を取られる
=> チームを信頼する。良い意思決定ができる人を採用
マネージャーがコーディングに時間を取られる
=> エンジニアを採用する。マネージャーがやることを減らす
テックリードがいない。そしてチームが小さい
=> やることが多過ぎる
テックリードがPRに時間を取られてる
=> まじで止めた方が良い
テックリードとシニアエンジニアがコーデイングに時間が取られてる
=> 採用プロセスを再考する。シニアエンジニアにはリーダーシップが入ってる
シニアエンジニアが重要でないことに時間を取られてる
=> 優先度がついてないか、コミュニケーションがうまくいってない
シニアエンジニアが火消しに時間を取られてる
=> トレーニングやツールの作成に時間が取られていない
CTOやVPOEが上記の問題を考えていない
=> まずは本当に考えてないか聞いてみよう。まじなら新しい人雇おう
本書はとてもためにまりました
まだまだ続くよ
関連記事:
- 97 Things Every Engineering Manager Should Knowの60-78まで読んだ
- 97 Things Every Engineering Manager Should Knowの79-94まで読んだ
- 新人技術系マネージャーが読むべき10冊