新任プリンシパルエンジニアへのアドバイス
(eugeneyan.com)- Amazon出身のエンジニアが、Principal（主席）エンジニア／サイエンティストの役割について、ロールモデルたちから観察し学んだ内容を31の助言として整理した文章
- プリンシパルは実質的に、製品・デザイン・エンジニアリング・文化全般を扱うマルチロールの担い手であり、判断力によって幅広い業務を遂行する
- 核心はコーディングよりも技術ビジョン、設計フィードバック、組織連携にあり、以前の役割で中核だった作業は今では副次的な業務になる
- 組織が価値を置いていないものに価値を教えることが大きな割合を占め、単に正しい判断をすることよりも、他者が共感し行動するように促す説得力が重要
- プリンシパルがいなければ起きない作業カテゴリに集中し、自分で実行することより他者をつなぎ育成することのほうが、より価値が高いことがある
- 自律性と責任は表裏一体であり、組織が集中すべき問題を自ら見つける必要があり、クリティカルパスから外れて隣接する位置へ移ることが長期的には効果的
1-3. 役割の本質とスタイル
- 1つ目: プリンシパルにはそれぞれ異なるスタイルがある
- 1つの分野を深く掘り下げるタイプ vs 水平的な影響力に優れたタイプ
- 技術的先駆者タイプ vs 複雑さを明快にするタイプ vs 複数組織を共通ビジョンで整列させるタイプ
- 自分の強みに合ったスタイルを見つけるべきであり、どのスタイルも他より重要ということはない
Amazonでは、プリンシパルがhands-onで働くこと（直接関与）が明示的に求められており、長期間hands-onでない場合は失敗する可能性が高い
- 2つ目: 以前の役割で中核だった作業は、今では副次的な業務になる
- 直接コードを書くことが時間の最善の使い方ではないかもしれないが、仕事とのつながりを保つために依然としてコーディングは必要
- 中核となる役割は、技術ビジョン、設計フィードバック、スポンサーシップ、ビジネス・製品・技術コンテキストの提供、新しい問題の発見、接続など
L7+ロールでよく知られた話: 時間の80%をコーディングに使っていても、最もインパクトが大きい部分は、あらゆる人をより効果的にすること
単一プロジェクトの実装に集中することから、すべてのビルダーがより良く作れるよう影響を与えることへとマインドセットを転換する
高品質なコードをリポジトリに貢献し、コードに語らせるだけでなく、設計提案へのフィードバック、技術ガイドの作成、長期ビジョンの主導など、ほかの取り組みのほうがより効果的な場合がある - 3つ目: 技術におけるパートタイムPMであり、実際にはあらゆることのパートタイマー
- 製品、デザイン、エンジニアリング、科学、QA、採用、財務、文化など、すべての領域
- 「あなたの仕事でないものはない」
- 高い判断力によって専門領域の外にも出ていける
4-7. コミュニケーションと影響力
- 4つ目: あなたの役割には、より多くのコミュニケーション、影響力、適切な人をつなぐことが含まれる
- プロジェクトは一般にスコープが大きく、ディレクターやVPをまたぐチームを含む
- 効果的なアラインメントと協業なしには成功できない
- 組織図をそのまま顧客に渡すような状態にしないよう注意が必要
- 5つ目: 正しいだけでは半分にもならない
- 自分が正しいと他者を説得し、さらに重要なのは、行動するだけ十分に気にかけてもらうこと
- モメンタムの作り方、スポンサーの見つけ方、やり切る方法を把握する必要がある
ときにはプロジェクトを始めて価値を示すことで、それを得られる
プリンシパルは模範を示すべきであり、人々が委員会を待たずに問題解決へ積極的であってほしい
「プリンシパルこそがその委員会なのに、誰を待っているのですか :)」 - 6つ目: 組織が価値を認めていないものに価値を教えることが、仕事の大きな部分を占める
- 対象読者は、役員から現場のIC（Individual Contributor）まで含まれる
- 最も難しい作業であり、しばしば失敗するが、未来を見てより広い視野を持つ人として、それでもやらなければならない
- メンターは、10本の文書提案のうち約3本が実行されれば素晴らしい結果だと見なしている
日々のチームレベル業務を担うICと違って、L7+の役割には、会社をより広く長期的な視点で見る余地がある
インパクトをより客観的に評価でき、そのレベルで貢献することが最も価値を生む - 7つ目: プリンシパルがいなければ起こらない作業カテゴリが存在する
- 一般に、自分が本当に関心を持ち、かつ卓越していることの交差点にある
- 迅速なプロトタイプを作ってリーダーシップに新たな顧客体験を共有すること、組織間あるいは業界の他の実務者との橋を築くこと、3年ビジョンを書くことなど
- このカテゴリの仕事に集中すべき
- キャリアが進むにつれて、より深く狭くなっていく
8-11. 他者を通じた拡張
- 8つ目: 最も価値のあることは、自分で作業することではなく、つなぐこと
- その作業に取り組もうとしているチームを、すでに取り組んだチームとつなぎ、再利用や学習につなげる
- 作業を実行でき、その過程で成長できる適切な人を見極めることも含まれる
- 9つ目: 一人でできることには限界がある
- 他者をコーチしメンタリングして、より効果的にできるように時間を投資するほうが、組織にとって有益
- 毎週数時間（オフィスアワーや定期Sync）を割く
- 育成したい1〜2人のICを見極め、どう支援するか目標を設定する
他者を通じた拡張が核心: PE（Principal Engineer）の成功は、組織がPEと同じ意思決定をできるようになったときに成立する
PEは別の曖昧な問題へ移り、正しい結果を達成する文化を築く皆を助けたい気持ちはあっても、長期的には自分の役割を置き換えられる人を育てることにエネルギーを集中すべき
そうした能力を示すすべての人に集中的な時間を投資し、彼らが今度は、現時点では潜在力が見えにくい別の人を助けられるようにする必要がある - 10つ目: 他者を作業に参加させることから、その作業を彼ら自身のものにすることへ切り替える
- 誰かに、自分が今の位置に到達する助けになったような仕事をする機会を与える
- 支援し、成功できるように場を整える
- 顧客にとって重要な問題や興味深い機会のバックログは無限にあるので、心配する必要はない
週に1〜2時間を誰かと過ごし、その人が自分の洞察のもとで40時間分の仕事を達成できるように拡張することこそ、真のプリンシパル・スケール
- 11つ目: 他者に仕事を渡したら、それはもうその人のもの
- コンテキストやガイドは提供できるが、最終的に方向を定めるのはその人の役目
- 自分なら取らないアプローチを取ることも許容する必要がある
- うまくいかなければ皆が学べ、うまくいけば自分が学べる
- ただし、プロジェクトが裏目に出かねない高リスクの一方向ドアに向かっている場合は介入が必要
12-15. 会議と関与の管理
- 12つ目: 会議で他者のための余地を作る
- ときに会議室では最もシニアな人の意見や決定が期待されるが、質問を通じて他者のための余地を作れる
- 参加していない人が見えたら、その人の強みに合う話題でやわらかく引き込む
- 議論に必要な誰かが会議から漏れていたなら、次回の会議に加える
- 13つ目: いつも価値を証明する必要はない
- 最も効果的なプリンシパルは、会議のあいだずっと沈黙していたり、文書レビューでほとんどコメントを残さなかったりする
- チームと議論がうまく回っているなら、それは素晴らしいこと
- 作業フローから一歩引いて、別の場所にエネルギーを集中できる
注意: 出席して沈黙していることは暗黙の承認を意味しうるため、マルチタスクや出席の意味には注意
- 14つ目: 役員との会議で、議題のすべてのトピックを扱う必要はない
- 役員がトピックに深く入り込み、意味のある質問をし、彼らにしかできない決定を下したり障害を取り除いたりできれば良い会議
- 15つ目: 幅広い役割で働くと、1週間全体が流れ込んでくるあらゆるもので埋まってしまうことがある
- レビュー、エスカレーション、メール、支援依頼などを含む
- 組織に長くいるほど大きな問題になりやすく、多くを知っていたり信頼を得たりして「go-to」な人になる
- 結果として、あらゆる会議の「必須」参加者になってしまう
- 時間を守る方法を学ばなければ、本当に関心のあるアイデアを前に進める時間がなくなる
- すべての会議に出る必要も、すべてのアイデアに意見を持つ必要もない。重要なものだけでよい
メンターが共有したこと: 考える時間は絶対に必要であり、会議から会議へと移動していると処理も先読みもできない
次の大きなものを見つけるために、質の高い思考時間を予定に入れ、会議から切り離される必要がある委任の方法を見つける必要がある。別の人をその役割に立てて時間を確保することは、自分を自由にするだけでなく、新しい人が成長できる範囲を作ることにもつながる
16-19. インパクトとコミュニケーション
- 16つ目: 今取り組んでいることに、なぜプリンシパルが必要なのか説明できないなら、間違ったことに取り組んでいる可能性がある（L6にも当てはまる）
- 17つ目: 地位ゆえに、ときには比較的少ない労力で結果を改善できる
- タイトルは組織上の特権を与え、関係性やコンテキストへのより大きなアクセスをもたらす
- 経験と組み合わさることで、先をよりよく見通せる
- そのため、かなり少ない労力の投入でも、プロジェクトの成功確率や結果を意味のある形で改善できる
- ROIが高く、この種の機会を見つけたら行動すべき
- 18つ目: タイトルは、持つべきでない場面にまで信頼性のオーラを与えることがある
- ときに人は、自分の即興的なコメントを過剰に解釈する。特によく知らない分野ではそうなりやすい
- その結果、自分の何気ないコメントのために多くの作業が発生する可能性がある
- 時間と労力の無駄になりうる
- したがって、自分が知っていること、知らないこと、依頼していること、単にコメントしているだけのことを明確にすべき
- 19つ目: 「何を」だけでなく、「なぜ」そう考えるのかも共有する
- 他の人がより良い意思決定をできるよう助ける
- 他の人が「プリンシパル<名前>がこう言ったから、私たちは……」と言って、十分に理解しないまま追従することを減らせる
L7の入力が必要な問題は、たいてい相当な不確実性のもとでの意思決定を含む
重要だが難しいのは、メンタルモデルを明確に表現すること。つまり、すべての情報がない中でどう判断に至るのか、なぜ特定の知識が他のデータポイントより重要なのかを示すこと
20-24. 組織とのつながりを保つ
- 20つ目: チームとのつながりを保つための仕組みを見つける
- 設計レビュー、週次デモ、近くに座って耳を傾けること、チームランチ、気軽な廊下での会話など
- 組織の脈を保ち、主要な問題や機会がどこにあるのかを把握する助けになる
- 21つ目: チームが大きな絵を見続けられるよう助ける
- 実務レベルが仕事の厚みや日々のデリバリーに集中すると、ときにより大きく長期的な問題や機会を見落とし、局所最適にはまり込むことがある
- 自分が持つコンテキストを通じて、チームにそれを思い出させる手助けができる
- 22つ目: 実用的であること。大局を見ることとローカルな解決策を受け入れることのバランスを取る
- 細部については実務レベルの人に相談し、耳を傾けるべきで、彼らこそ現場の専門家
- 23つ目: 一緒に過ごしたのが1〜2時間だけの人について、レビューや昇進フィードバックを求められることがある
- 行動全体のごく小さなサンプルに基づく質の低いフィードバックを出すくらいなら、断ることもできる
- 24つ目: インターンとメンターと関わる時間を作る
- インターンシップ期間中の数回の接点が、画期的なものになりうる
- 初期チェックイン（必要なら方向修正）、デモデーへの参加などを含む
- メンター、インターンとともに、インターンシップ後も価値を持ち続ける成果物へ向けて取り組む
- 製品1-pager、動作するソフトウェア、技術文書などを含む
25-28. プリンシパルとしての移行と責任
- 25つ目: プリンシパルに到達するには、自分をクリティカルパス上に置く必要がある。プリンシパルとして効果的に働き、その先へ進むには、意識的にそこから自分を外す必要がある
- 以前は「go-to」な人だったが、必須から隣接へ移る必要がある
- 組織はますます自分から恩恵を受けるべきだが、効果的であるために自分へ依存してはならない
- 自分がしている貢献を、他の人もできるようにどう権限委譲するかを考える
クリティカルパスのプロジェクトに自分を注入しすぎないよう注意。注力が別の優先事項に奪われやすいため、クリティカルパスから外れているか、そこにいるなら本当に厳格に固定する必要がある
- 26つ目: プリンシパルに昇進したなら、それはすでにしばらくの間プリンシパルとして振る舞っていたから
- 通常は1年以上
- したがって、タイトルに伴う期待の高まりを過度に心配する必要はない
- 今までやってきたことを続け、ほかのプリンシパルと交流し、自分のスタイルを把握し、リーダーシップと協力して注力領域を見つける
- 27つ目: 大きな自由には大きな責任が伴う
- 何に取り組むかを選ぶ自律性はあるが、責任とインパクトへの期待も存在する
- 自由とは好きなことをすることではなく、最もレバレッジの高い問題を見つけて解くオーナーシップに関するもの
- 何をやるべきか教えられることや、何らかのガイドが与えられることを期待してはいけない
- 組織が集中すべきことを見極める役割を期待されている
- 28つ目: リーダーシップとチャーターを定義し、整合させる
- 1つの方法は、仕事を3つのバケットに分けること: (i) オーナー、(ii) スポンサー、(iii) コンサルタント
- コンサルタント: レビューに参加し、ガイダンスを提供し、システムや製品意図について高レベルの理解を持つ
- スポンサー: 上記に加え、アイデアを組織の優先事項にし、アラインメント構築と意思決定の推進のために動き、ステークホルダーと関わる
- オーナー: 上記すべてに加え、システムの専門家であり最初の連絡窓口であり、設計・実行・インパクトの成功に対してほとんど執着に近いレベルで向き合う
- 本人は通常、1〜2件のプロジェクトをオーナーとして持ち（時間の>50%）、2〜3件のプロジェクトをスポンサーし（時間の約20%）、残りの時間をコンサルティングに充てる
29-31. 個人の成長と持続可能性
- 29つ目: プリンシパルであることは孤独になりうる
- あらゆるチームの一員でありながら、同時にどのチームにも完全には属していない
- オープンに話せる同僚ネットワークを築く
- 同じ会社やドメインで働いているかどうかは、おそらく重要ではない
- 30つ目: 自分のニーズを無視しないこと
- 学習、成長、ウェルビーイングを支えるプロジェクトのための時間と余地を作る
- 短期的には利己的に感じられるかもしれないが、組織の中で燃え尽きてしまうよりはるかに望ましい
- 自分を健康で幸せに、成長し続けられる状態に保つ活動を積極的に探せば、組織もその恩恵を受け、組織にとっても自分を維持しやすくなる
- マネージャーと協力してバランスの取り方を見つける
- 31つ目: 学び続けること。業界は速く動いている
- 何も教えてくれない、あるいは少なくとも仕事と関係のないことしか教えてくれないプロジェクトを引き受けるなら、後退しているのと同じ
- ときには避けられないが、そうしたプロジェクトが来たらタイムボックスを設定する
- 学びは仕事の中からだけ来る必要はない
- 論文や技術教科書を読み、週末にプロトタイプをハックして新しいアイデアや技術への理解を深める時間を見つけているPEもいる
その他のリソース
- Amazon Principal Engineering Community Tenets
- Staff Engineer: Leadership Beyond the Management Track
- The Staff Engineer's Path: A Guide for ICs Navigating Growth and Change
- The job behind the job [of a high level IC]
参考: Amazon/GoogleのPrincipal Tech ICは、**「管理職に準ずる戦略的役割を担う最高レベルの技術リーダー」**という点で、日本でいう「主席エンジニア」よりもさらに上位の概念に近い
1件のコメント
「すべての情報がない状態でどう判断に至るか、なぜ特定の知識がほかのデータポイントより重要なのか」を見極められるなら、本当にすごいことだと思います