「エンジニアリングマネージャーのしごと」を読んだ

はじめに

現在はソフトウェアエンジニアとして働いており、エンジニアリングマネージャーではないが、最近になって将来のキャリアパスとしてエンジニアリングマネージャーに興味が出てきたので読んでみた。もともとはエンジニアリングマネージャーよりもソフトウェアエンジニアの方がスキルが必要だと思っていてあまり興味がなかったのだが、最近になって、「人って技術よりも複雑だよな」と思い、人を扱うエンジニアリングマネージャーこそ高いスキルがいるのではないかと思って興味が出てきた。

マネージャーのアウトプット

マネージャーのアウトプット=あなたのチームのアウトプット+あなたが影響を与えたほかのチームのアウトプット

チームのアウトプットがマネージャーのアウトプットということは分かっていたが、影響を与えたほかのチームのアウトプットも自分のアウトプットだとは考えたことがなかった。

1on1の頻度

本書では1on1を週次でするように書いてあった。この手の書籍にはだいたい週次で1on1をするように書いてある気がするが、ほんとに世の中の人たちはそんなペースでしているんだろうか？デイリーとかで話す機会がない場合を想定しているのかな。

マネージャーの仕事内容

1. 情報収集
2. 意思決定
3. ナッジング
4. ロールモデル

ナッジングとは、議論に対して自身の観点を提供することで決定に影響を与えること。

ナッジングという言葉は初めて知った。ナッジングは、やっても成果としてアピールしにくくて困る。でもちゃんと名前がついていて、仕事内容として認められている行為なんだと知れてよかった。

締め切りを延期したらだめなのか

締め切りをずらすことが本当に意味することは何なのか
AppleでさえWWDCのステージで何かを発表し、数か月後に登場する

確かにと思った。ちゃんと考えよう。

心穏やかに過ごすために

コントロールできること、コントロールできないこと、ある程度コントロールできることに分類する。
コントロールできることにのみベストを尽くせばＯＫとする。コントロールできないことは諦める。そして、ある程度しかコントロールできないことに対しては、他者に依存する外部ゴールではなく、自分で達成できる内部ゴールを設定して、内部ゴールに対してベストを尽くせばＯＫとする。

自分にとっては、内部ゴールに対してベストを作ればＯＫだと分かっていても気持ち的に割り切るのが難しそう。ここは訓練しないといけないなと思った。

マネジメントバグ

マネジメントにまつわる問題のこと。ネーミングがいいなと思った。

終わりに

またエンジニアリングマネージャーになったら読み返そう。