Read Book: The Manager's Path

読んだ本：Fournier, Camille. The Manager’s Path

2019年11月20日に購入して、先日ようやく読み終えた。同僚のすすめで読んでみたが学びが多かった。 今後すぐどうということではないが、将来のキャリアパスの選択肢について考える上で得られた知識は多かったと思う。 後の参考のため、以下に印象に残った箇所をメモしておく。

なお、この本の論じているマネジメントは、ソフトウェアエンジニアリングチームについてであり、一般全てのマネジメントではない。 特に断りない限り以下では、「エンジニア」「メンバー」はソフトウェアエンジニアを指し、「マネージャー」はソフトウエアエンジニアリングマネージャーを指す。

1. Management 101

What to Expect from a Manager

• マネージャーはチームのスループットを最大化すること、タイムリーなデリバリーを実現することに責任を負う。
• Individual Contributer (IC)はプロダクト、サービス、コードのデリバリーに責任を負う。
• ICの稼働の範疇で完結できるタスクについては、ICに権限を移譲することが適切。ICはプロダクト、サービス、コードの特定の範囲について最も詳しいはずなので、その人間が判断できることが重要。
• 信頼関係無しに権限を移譲することはできない。当然ながら信頼関係を構築するために、日常会話や1-1は重要なツールと思う。
• 双方の記憶が鮮明なうちにフィードバックをすることが重要。早期に指摘することで、改善のチャンスも多く得られるし、同じ過ちを繰り返すリスクも減る。

How to Be Managed

• よいマネージャーは、社内で何が重視され何が求められるか理解している。それはICへの適切なフィードバックのためにも必要。
• 適切なネットワーク構築はチームのスループットを向上するために必須。

2. Mentoring

Being a Mentor

• フィードバックを早期にと同じだが、方向性がおかしいことに気づいた場合は直ちに修正すること。失敗するまで待ってはいけない。
• わからないことについて、他人に質問するまでの時間の目安を明言するのはよい方法と思う。それをコンテキストとして共有することで受け手も質問が来ることを想定するし、質問者も躊躇しづらくなる。
• 組織の外から来た人から得られるフィードバックは貴重。その人が「組織内の人」になるまでの時間は極めて短い。
• 新しい人とのネットワーク構築の労力を惜しまず、習慣化すること。
• シニアグレードではチーム外ともメンタリングの関係が自発的に形成されるべき。

Good Manager, Bad Manager: The Alpha Geek

• アルファギークとは
  • チーム内の最も優れたエンジニアの1人。
  • 知性とテクニカルスキルにを置き、それを有するものが意思決定をするべきと考える。
  • チーム内でテクニカルな権威であろうとし、それをサポートするメッセージにしか反応しない。

  • The alpha geek tries to create a culture of excellence, but ends up creating a culture of fear.

• テクニカルスキルがあるにも関わらず他人が相談にこない、アルファギークの一つの兆候。

Tips for the Manager of a Mentor

• メンタリング関係を組むとき、その目的は明確でなければならない。メンターの時間をいたずらに奪ってはいけない。
• メンタリングによりメンターには一つ責任が増える。その分生産性が落ちることは明確に考慮されなければならない。

Key Takeaways for the Mentor

• 視座を合わせ、同じコンテキストでコミュニケーションをとる。一方的なレクチャーであったり、相手の理解していない内容、反対している内容について議論するのは最悪。

3. Tech Lead

• Tech leadは最も経験あるエンジニアのポジションではない。確立した定義はないが、コードを書くだけではなく一定のグループのマネジメントにも責任を持つというのが例。

All Great Tech Leads Know This One Weird Trick

• マネジメントトラックの最初の一歩として、コーディングとマネジメントのバランスをとることがTech leadの挑戦の一つとなる。

Being a Tech Lead 101

• 健全な組織では課題は早期に周知される。情報がtransparentであることは組織の健全性の指標となる。

Managing Projects

• マネジメントトラックを進んでいくために、個人のスコープを超えてタスクを適切にブレイクダウンする方法を習得していかなければならない。
• 情報を正しく伝達することに十分時間を費やす。Poor communication creates more work.
• よいプランニングプロセスとは、正確でなくともタスクがどの程度の時間や労力を要するか知ることができるもの。
• 自分のテクニカルスキルにある程度満足するまでマネジメントトラックに乗るべきでないといのが著者の考え。これはよい指標と思う。マネージメントのポジションに就く前に、マネージメントのリテラシーを挙げておくのも良いと思う。

Good Manager, Bad Manager: The Process Czar

• Process Czarとは
  • 正しいプロセスは1つのみであると考える。それが正しくデザインされ、正しく運用されれば全てのチームの主要な問題は解決すると考える。
  • on-call, core review, release等のプロセスについて詳細なアイディアを持ち、プロセスが詳細まで整然と規定されていることを好む。
  • agile, Kanban, scrum, lean, waterfall等特定のプロセスに傾倒している場合もある。
  • タスクを厳格に管理し、漏れがでないことから、プロジェクトマネジメントチームからは賞賛される。
  • 最善のプロセスに従わない者を非難する。プロセスに柔軟性を持たせる選択肢を持たない。
  • 計測しやすいメトリクスのみに注目する。
• プロセスに頼りすぎてはいけない。フィットするプロセス、ツール、ワークスタイルは、全てのチームで異なることを理解する。
• プロセスに違反したものを過剰に非難するような体制にするべきではない。人が合わせやすいようプロセスを変えることも常に選択肢に入れる。

How to Be a Great Tech Lead

• Tech leadのポジションでは、シニアより下のエンジニアのために、成長の機会のためのタスクを残しておかなければならない。チームのレベルを引き上げるのはシニアエンジニアの役割。
• ライティングとスピーキングのスキルをあげる。リーダーには議論を先導することが求められる。

4. Managing People

Different 1-1 Styles

• 個々のメンバーの不満や愚痴に付き合いすぎないように。面と向き合い過ぎてしまうとおそらく事態は悪化する。そうしたトラブルに対しては、すぐに対処するか、合意の元いったん保留する。無言で放置しない。

Practical Advice for Delegating Effectively

• 自分で集められる情報をメンバーをいちいち小突いて聞き出すのは最悪のマイクロマネージメント。チケット、アラート、メトリクス、コードの変更など一次ソースを少し見てわかるものは自分で確認する。

Creating a Culture of Continuous Feedback

• 継続的かつ頻繁にフィードバックする文化を作る。個々人に注意を払うようになるし、結果として才能の発掘や育成にも役に立つ。

Performance Reviews

• フィードバックに仕方に気を付ける。いきなり改善点から始めない。
• ポテンシャルは早期に成果となって現れる。高いポテンシャルを持った人のパフォーマンスが低く徐々に上がっていくケースはほとんどない。ポテンシャルがあると考えるならそれが発揮できるポジションへの異動を考える。

Cultivating Careers

• アーリーキャリアのポジションでは、promote or quitといった雇用方針も有効。日本の労働法では実現は難しいだろうが、西海岸ではこうした慣行で雇用されることがあるということを理解しておいたほうがよい。
• 昇進が近いと考えるメンバーに対しては、それに値するか見極めるためのプロジェクトを用意してサポートする。

Challenging Situations: Firing Underperformers

• マネージメントの大原則の一つは、メンバーにとってのサプライズを避けること。マイナスのニュースについては、特に伝え方に気を付ける。例えば、期待するパフォーマンスを満たしていないメンバーには、できるだけ早期からかつ繰り返しそのことを明確に伝える。

5. Managing a Team

Staying Technical

• 単一チームのマネージャーは、なおテクニカルであり続けなければならない。よいマネージャーは開発の最短経路を見つけることに長けている。

Debugging Dysfunctional Teams: The Basics

• リリースのプロセスが複雑でかつ頻度が低いと、それが作業の衝突の原因となる。リリース順序の調整などコミュニケーションのオーバーヘッドが発生し、それが生産性を低下させる。リリースの頻度を増やすことでそうした非効率を解消できる。

How to Drive Good Decisions

• 見過ごされがちだがプロジェクトが終了したらレビューをする。もし失敗に終わったとしても、そこから学べば時間の無駄ではない。

Good Manager, Bad Manager: Conflict Avoider, Conflict Tamer

• チームに課題や衝突がないかのように見せかけてはいけない。取り返しのつかなくなるまで悪化しないと顕在化しないようなチーム運営は最悪。面倒事はあろうとも、反対意見が言える組織の方が遥かによい。
• コンセンサスや多数決に頼りすぎない。専門性や立場の違いにより、判断のために必要な情報を持ち合わせるのは一部のメンバーだけである場合がほとんどだし、関係者が増えるほどコンセンサスに費やす手間も増大する。実行者に権限と責任を移譲するプロセスを活用する。

Advanced Project Management

• 稼働日を全て埋めるような計画を立ててはいけない。unplannedなタスクに多くの時間が費やされることを考慮する。

6. Managing Multiple Teams

• 週に半日は何かクリエイティブなことをするための時間を作っておこう。（エンジニアリングブログ執筆、カンファレンス登壇準備、OSS等）

Managing Your Time: What’s Important, Anyway?

• 緊急ではないが重要なタスクの例として、健全なミーティング運営があげられる。健全なミーティングは関係者を網羅しつつも、短時間で生産的であり、全ての参加者が事前準備をして臨むものである。

Challenging Situations: Strategies for Saying No

• 配下のテックリードにマネージメントのスキルを与え、自信を持たせることが一つの役割。

Measuring the Health of Your Development Team

• リリース頻度が低いことの弊害は、エンジニアのクオリティに対する責任感の欠落させ、QAチームに全てを押し付けるようになる。またそれによりコミュニケーションのオーバーヘッドが生じる。リリースが失敗したときのロールバックに時間がかかる。多くのチームの問題はリリースを頻繁にできていないことから生じる。

Good Manager, Bad Manager: Us Versus Them, Team Player

• チームの弱点、課題に気を取られすぎない。複数チームのマネージャーとして、会社のビジョン、文化にフィットするチーム作りをしていかなければならないが、それは欠点を直すことでなく、長所を伸ばすことで実現するべき。

7. Managing Managers

Skip-Level Meetings

• このポジションでは、情報収集方法のトレードオフを常に念頭に置く必要がある。コミュニケーションをどの程度綿密に行うかと、時間と労力はトレードオフにあるので、パーフェクトな方法というのは存在しない。悪い知らせを知るのが極端に遅い場合、バランスを見直す機会である。

Good Manager, Bad Manager: The People Pleaser

• Noと言えない環境や、意思決定を過剰に頼ることが、People pleaserが生じさせる一因となる。

Managing Experienced Managers

• マネジメントは会社のカルチャーに密接に関係するタスクなので、マネジメントのポジションで採用するときは、カルチャーフィットは最重要項目となる。

Hiring Managers

• 時にカルチャーの一部は変化が必要になる。そして、新しいマネージャーを採用することでその速度は助長される。成長中のスタートアップでは、経験豊富なマネージャーや幹部を採用して、経験不足を補完することがよくあるが、これは非常にうまくいくことも、破滅的に失敗することもある。なのでカルチャーに変化を生じさせるときは十分過程の出来事に注意を払う。

Debugging Dysfunctional Organizations

• 退屈で非生産的なミーティングはカルチャーが悪化している兆候。

8. The Big Leagues

Models for Thinking About Tech Senior Leadership

• リーダーシップポジションの役割
  • Decision Making: 不完全な情報でチーム全体に影響しうる意思決定をすること。意思決定は精神を消耗するストレスフルなタスクである。
  • Technology strategy/visionary: ビジネス環境とテクノロジーの変遷を見極め、次のプロダクト開発戦略を決定する役割を担う。ビジネスに重点が置かれる点で、R&Dとは異なる。

What’s a VP of Engineering?

• CTOとVPoE両方のポジションがある場合、多くはVPoEがチームのプロセスの実施に重点を置き、CTOが長期の戦略やビジョンの策定に重点を置く。

Changing Priorities

• ビジネス環境の変化等により、リーダーシップからの路線変更の通達は予告なしに起こることもある。一方で現場では、現場のプライオリティがあるが、リーダーシップポジションでは日々のオペレーションから切り離されているが故に、その認識合わせがうまくいかず変化に時間を要することがある。変化に早急に対応するために、現場も現在優先されているタスクがなぜ優先される必要があるのか意義を説明できるようになっている必要がある。
• チーム外の人が同じコンテキストを持っている思い違いをして説明するために、理解がすりあわず衝突してしまうことは多々ある。現在のチームのタスクの至急性が理解されていないとき、より明確にコミュニケーションをとらなければならない。
• 組織が大きくなるとコミュニケーションは非常に難しくなる。著者の体感として、大体の場合本当に理解が得られるまでは3回同じことを繰り返す必要がある。

Senior Peers in Other Functions

• peerとマネジメントスタイルや意見が合わない場合、それが自分のチームに影響しない限りは、干渉しないようにする。相手の専門性を尊重し、反対しつつも違うアプローチがあることを許容する姿勢を持つ。

The Echo

• 難しい判断を迫られたとき、ストレスを和らげるため社内の誰かに相談をしたくなることがあるかもしれないが、リーダーシップポジションではそれは慎むべき。相談相手にとっては、手の打ちようがない問題を打ち明けられただけで、リーダーシップポジションへの不信につながる。リーダーシップポジションではなかったときと違って、その手の情報共有はチームにとって大きな不安の元となる。

9. Bootstrapping Culture

• カルチャーを作るにあたって、自分にとって、会社にとって、また会社の増えゆく同僚達にとってなにが重要となるかという感覚が必要になる。会社の成長とともに知識や仕事をスケールさせる枠組みを見据える。

Assessing Your Role

• 失敗から学ぶ。失敗の全ての要因を洗い出し、チームストラクチャーの発展に活用する。

Cross-Functional Teams

• 目的の達成のためには関係する全てのチームを巻き込んで臨む。”us versus them”パターンに陥らないようにする。（自チームのスコープ外のタスクについて無関心で丸投げ状態となること。） Conway’s Lawにあるように、プロダクトデザインは組織のコミュニケーション構造をコピーしたものになる。

  Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

• プロジェクトのスコープが単一チームを超えるとき、cross-functionalチームを立ち上げるのも一つの方法である。 cross-functionalチームでは、各メンバーのレポートラインは変えないが、タスクの割り当てについてはそのチーム内での判断で決定される。