この記事では内容の詳細については触れておらず、感想っぽいものを羅列しただけです。特定チームのマネジメント、複数チームのマネジメント、そして経営幹部になってから...レベルごとに変わるマネジメントスキルに触れておきたいと思い読んでみる。
もちろん、自分は複数チームを管理するまでにはまだ至っていない（チームの単位にもよるけど）し経営幹部でもないので、後半は自分の話し相手の心を理解しようという気持ちで読みました。
1章 マネジメントの基本
- 1on1のミーティングはプライベートや検討事項の共有にも意味がある、単なる現状報告は1on1とは言えない
- 部下へのフィードバックと指導をする、上司は部下のキャリアアップのリソースの一部を担っている
- 自分へのフィードバックは出世するほど機会が少なくなりがちなので注意する
- 自分の成長に必要なリソースを判断するのは自分自身であり上司ではない、自分を幸せにする技術・知識・状態は自分で探すべき
- 技術以外のスキルを学ぶ機会はどうやって探せるだろうか
- 自分を他チームに売り込んでみる、上司に手伝ってもらうことも一案だ
2章 メンタリング
- 新人へのアプローチ方法、新人にとっての素晴らしい指南役とは？
- インターン生に満足してもらうテーマを考えるのは難しい（自分の体験）、しかし実はインターンの受け入れメンターは将来の管理職の練習の舞台にもなりうる
- コミュニケーションのやり取りは、インターン生のレベルに関係なく練習できるし、インターン生にとっても実のある期間にできる
- 新人やインターン生の意見は客観的なもの
- 新人やインターン生が何を望むか聞いてあげるべきであると同時に、どうあってほしいかも伝えるべきだ
- メンティー・メンターになったなら、その期間で何を望むのか考えるべきだ
- リーダーになるには、一人だけの力ではなれないということを忘れてはいけない
- 新しい人とのコミュニケーションの機会と見れば、メンタリングの時間は客観的に自分を見つめなおす機会になる
3章 テックリード
- テックリードにはコミュニケーション力が必要
- テックリードを引き継ぎ前提の職責群とするアイデアの背景を理解する
- システムアーキテクトとビジネスアナリストの役割をともに担う必要がある
- 確実に予測可能なスケジュールは、無い！
- ただ伝えただけでは人は動かない
- プロセスツァーの性質が向いている場面と向いていない場面を自分で理解して切り替えられるか
- 優秀なテックリードに求められる性質：アーキテクチャや技術選定の知識だけあればいいというわけではない、開発はチームですることを理解している
4章 人の管理
- マネジメントは部下とのコミュニケーションをする、そのコミュニケーションの仕方の希望もチェックするべき
- 1章と同じ内容もある、つまりリーダーは部下の成長のリソースの一部になることを理解する
- 自分自身を含め、何をしたいのか・希望は・キャリアパス・プライベートの苦痛を話し合える相手になる
- 新人にドキュメントを更新させるのは、典型的な、しかし効果のあるチームへの理解を促進する方法
- コンテクストの理解が不十分な時期の意見は批判に聞こえうることを心にとどめておく
- 1on1はTODOリストとかの準備をして臨むという形態もあるらしい、しかし1on1そのもののコストを増やすのもどうか、と思った
- 1on1の議事録はドキュメント化すべだろうか、単に音声認識で記録しておくだけではだめだろうか
- マイクロマネジメントして状況をコントロールするのではなく、レポートの手段を工夫すべき
- 勤務評価は、功績や褒章には時間をかける、改善を挙げるときは要点を決めて端的にまとめる
- キャリアアップやライフプランについて定期的に話題を振ってみようと思ったし、逆に自分のプランについて話すのもいいかと思った
5章 チームの管理
- 管理する人数が増えれば難易度は格段にアップする、エンジニアリングリードになったとしても少しは開発には携わるべき
- そして技術系の管理と意思決定をする以上、技術ドメインの知識のアップデートを怠るべきではない、でも時間のすべてを勉強に掛けることは人である以上無理
- 個人的に気になる文言、この著者は『技術力が頭打ちになる』という言葉が定期的に出てくる
- キャリアが進むにつれて技術のインプットは難しくなる、その中で最低ひとつ以上の言語・開発ツールで秀でた技術を保有しない限り、すぐに『頭打ち』が来るということだろう。そしてそれはキャリアパスの頭打ちにも（技術を捨てたドメインに移動しない限り）つながりうるということだと思う
- チームの問題の改善はまず自分が改善する意思を示すところから始まるのだろう、そして時にはチームに厄介ごとを持ち込ませようとする外部からの守りとして立ち回るのがエンジニアリングリード
- しかし保守的すぎて外部からの意見をすべてはじくのは当然×、客観的な判断や新しい風も必要
- 問題を他者への責任転嫁で解決してはいけない、またすべて多数決もｘ（そのために1on1とかで個別にバックグラウンドを聞いてきたはず）
- 『秘密裡』、言い換えると勝手に変更を加えて伝達しない人にはすぐに問題を伝える、それはすぐに解決できる
6章 複数チームの管理
ここから先の章は自分では経験したことがない、もしくは同期でやっている人がほぼいないレイヤー。しかし、仕事の上で上司やさらにその上の上司との面談は当然ある。彼ら・彼女らの考えを理解するために読んでみます。
- このレベルからは毎日コードを書くことは不可能に近い、コードレビューを通じて触れるのがいい。もちろん、レビューできるレベルの知識と経験が必要だろう
- ここでも『ひとつ以上の言語の知識を完全に身に着ける』ことの大切さが語られている
- このレベルであっても、自由時間でのブログや技術的なインプットなどの創作作業は価値のあるものになるだろう
- 管理もコードも（そしてデザイン・営業・その他すべてが）仕事でありリスペクトをもって接することを忘れてはいけない、そしてどの職・階級が正しい選択であると決めつけてもいけない
- 重要さ・緊急さのラベルを判断できるように、当然それにはこれまでの経験とエンジニアとしての知識が生きてくる
- ひとつは、そして可能なら複数のプログラミング・開発環境を通じて得られた知識は共通化され、新しい技術に対する理解のハードルを下げる助けにつながるはず
- 製品アップデートやリリースの頻度は最もわかりやすいチーム健全度の指標のひとつ
- 「無精」「短気」「傲慢」はエンジニアの美徳、もちろん履き違えてはいけない（つまり、例えばデザイナーとか他チームに向けて傲慢になったりしてはいけない）
7章 複数の管理者の管理
- 複数チームの管理と基本は変わらないが責任度は格段にアップ
- もはやエンジニアチームだけと接するレイヤーではない
- 自分の新しい長所短所が見えてくるかもしれない（なぜだろうか）
- 過去の仕事の延長ではないことを意識して、離れたランクの人からの情報収集、組織の健康度合いを把握する手段を確立する必要がある。もちろんこれ以外にもやるべきことがある。
- 1on1は直属の部下だった、スキップレベルミーティングは2つ離れた部下との面談
8章 経営幹部
(省略)
9章 文化の構築
(省略)