エンジニアリングマネージャーのしごとメモ
EMが関わる領域として、よく言われるのは以下。
- ★ピープルマネジメント
- テクノロジーマネジメント (テックリード寄り)
- プロジェクトマネジメント (プロジェクトマネージャー寄り)
- プロダクトマネジメント (プロダクトマネージャー寄り)
組織やチームのステージによって関わり方は異なるが、この中でも特に軸となるのがピープルマネジメント。
基本的にマネージャーは油断すると稼働率100%の消防車みたいになる。
- 突発的な仕事が多数降ってくる
- 大規模障害、メンバーからの悩み相談、予算プロセス、評価面談、etc
- 本当に解くべき問題に時間を使えなくなる。
- 自分が考える、作業する時間も必要
- 皆が帰った後にやる、土日にやる、みたいな思考ではどこかで破綻する
自分のキャパシティに余裕を持たせなければならない。
- マネージャーにはあらゆる情報が殺到してくる
- 必要なときに必要な情報を探したり、見返せるように整理しておく必要がある
- 記憶に頼らない
- カレンダー、ToDo管理ツール、メールボックス、など自分にあったツールの活用
- カレンダーのブロックは重要
- マネージャーの考える時間を確保するため
- ToDoリストにないものはやらない、シンプルに保っていく
- 自分自身を整理できていないのに、それより大きなチームを効果的に扱えるはずがない
マネージャーのアウトプット (アウトカム)、成果の考え方。
- マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット
ポイントとしては
- チームのアウトプットに対して最終責任を持つ
- チームのアウトプットはマネージャー個人のアウトプットより重要
- 自分のタスクをこなすより、権限移譲、メンタリング、コーチングなどに時間を使うべき
- 他チームに良い影響を与える
- ロールモデルになる、ナッジング (後押し)
- 「自チームを優先して他チームに迷惑をかける、他チームに悪い影響を与える = アウトプットの総量が下がる」
マネージャーのしごとの分類。状況、タイミングによってどこに特に注力すべきかは変わるが、大きく以下の4点。
-
情報収集
- メール、未読チャット、1on1、雑談など
- 自分の意思決定の土台になる情報の収集
-
意思決定
- マネージャーが持つ大きな権限の1つ
- 細心の注意を払い、結果に責任を持つ (メンバーに任せるのも実行責任)
- 採用、アサイン、設計など重要な意思決定
- マネージャーが持つ大きな権限の1つ
-
ナッジング (意思決定などを後押しすること)
- 議論などに対して自分の観点を提供して、意思決定に影響を与える
- 自分の考えを共有する、自チームの取り組みを紹介し、他チームに提案する
- 経験が少ない人も採用候補にするよう、CTOに提案する
- 1on1で次の仕事の取り組み方をアドバイスする
- 議論などに対して自分の観点を提供して、意思決定に影響を与える
-
ロールモデル
- リーダーとして組織が求めている人物像を体現する、まわりに行動で示していく
- TeckTalkで自分がまず発表して、メンバーの登壇を支援するなど
移譲について。
「マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット」、なのでマネージャーのアウトプットを最大化するためにはなんでもかんでも自分でやることは良くないし、そもそも無理。移譲が重要になってくる。
説明責任 (結果責任)は移譲できない (自分が担うべき責任)ので実行責任をメンバーに移譲する。
どのタスクをどの程度メンバーに移譲するのか、を意思決定するのがマネージャーの仕事。移譲度合いを決めて、教育、コーチング、メンタリング、確認をバランスよくやっていくことが重要。
時間とともに学習が進んでメンバーのできることが増える、その結果チームのアウトプット総量が上がる。
移譲でやるべきこと、やってはいけないこと。
- やるべきこと
- 移譲すること
- 相手にとってチャレンジになるくらい移譲すること
- コンフォートゾーン、パニックゾーンではなく、チャレンジゾーン/ラーニングゾーン内に入るテーマ
- タスクの重要性に応じて、適切なコントロールは持ち続けること
- やってはいけないこと
- 丸投げ
- 他の人のやり方が自分と同じであることを期待すること
- 説明責任はアウトプット/成果に対してであり、プロセスは任せる
- 渡した仕事を後で取り返すこと
- やられた側からしたら、もう二度とやりたくないという気持ちになってしまう
マネージャーとして移譲をすると以下のような不安と対峙することになる。
- 自分がやったほうが早いし、品質も間違いないと考えてしまう
- 移譲したタスクの進捗が不安になる
- 期待した品質でタスクが完成しないことにイライラする
ここで重要な考え方は
- すべてのことをコントロールすることはできないと理解すること
コントロールの三分法のすすめ。以下の3つに分類し、整理するとよい。
- 私達がコントロールできるもの: 自分のタスクなど
- 私達が全くコントロールできないもの: 天候、他人の感情など
- 私達がある程度コントロールできるもの: 試合に勝ちたいなどの願望など
それぞれの向き合い方:
- 自分でコントロールできること
- -> 結果について心配する
- 自分でコントロールできないこと
- -> 結果について心配しない
- 自分である程度コントロールできること
- -> 内部ゴールを設定してベストを尽くす
- 良いプロダクトを作って世の中に貢献したい -> プロダクトチームで設定した目標達成のための実行をやりきる
メンバーが欲求を満たせるように多くの機会、ポジションを作るのはマネージャーとしての責任である。これができないとメンバーが離職する -> チームのアウトプット総量が下がる。
仕事に合った人を獲得するのではなく、人に合った仕事を獲得する。
- 対所属の欲求
- メンバーと強い関係を築く
- 成長を支援するため、率直なフィードバックを促し、実際にやってみせる
- チームにいる人にとってのロールモデルになる
- 対承認の欲求
- 適切な賞賛と批判を通して、メンバーがしたことを確実に評価する
- キャリアアップに関する議論をを円滑に進め、メンバーのレベルに応じて的確な職位と責任を持たせる
- 対自己実現の欲求
- 適切な移譲、メンバーが学び、貢献し、成長する継続的な機会を提供する
- メンバーが仕事とトレーニングやカンファレンス参加などを通して、新たな能力を身につける機会、環境を提供する
- アウトカムが擦り合っている限り、メンバーのやり方で問題を解決する自由を与える
まとめ
- マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット
- マネージャーはメンバーのために存在する
- 1on1は誰のため? -> メンバー
- 時間がないので1on1は月1だけ、とかやっていないか?
- 評価面談は誰のため? -> メンバー
- 「今期あなたはどんなことしたんでしたっけ?」とかメンバーに言っていないか?
- 1on1は誰のため? -> メンバー