カミーユ・フーニエ リーダーシップスタイル：テクニカル・マネジャーのプレイブック

重要事実：カミーユ・フーニエ

• 前CTO、Rent the Runway（2013–2017）
• マネージング・ディレクターとプラットフォーム・エンジニアリング・ヘッド、Two Sigma
• 著者、「The Manager's Path」（O'Reilly、2017）。ベストセラー・エンジニアリング・マネジメント本
• 貢献者、「97 Things Every Engineering Manager Should Know」
• Apache ZooKeeper コミッター。分散協調サービスのコア貢献者
• 初期キャリア：ゴールドマン・サックスのマネージング・ディレクター（インフラストラクチャ・エンジニアリング）

The Manager's Pathはビジョンまたは文化についてのビジネス本ではありません。これはマニュアルで、チャプターごるに、テック・リードからCTOまで、各段階の管理で実際に何が必要かについてです。2017年に出版され、シリコンバレーで最も推奨されるエンジニアリング・マネジメント本になりました。他のどの本もが質問をしていなかった質問に答えたからです。あなたの最高のエンジニアがマネージャーになりたいと思うとき、おそらく彼らはそうすべきではないときはどうしますか。あなたのダイレクトが管理者でもあるとき、スキップレベル会話をどのように管理しますか。Director と VP of Engineering の間の実際の違いは何ですか。

カミーユ・フーニエは経験から書きました。彼女は2013年から2017年までRent the Runwayの最高技術責任者でした。当時最も急速に拡大しているファッション技術企業の1つ。その前に、彼女はゴールドマン・サックスでマネージング・ディレクターとしての時間を過ごし、大規模なチームを実行しているインフラストラクチャ・エンジニアリングを管理しました。世界で最も技術に依存している金融機関の1つ内で。初期のキャリアでは、彼女は分散協調サービスであるApache ZooKeeperの主要な貢献者でした。彼女は後にTwo Sigmaで大規模でマネージしたインフラストラクチャ・システムの多くを支える。彼女はビジネス・スクールで管理理論を学びませんでした。彼女はゴールドマンでエンジニアを管理し、Rent the Runwayで消費者技術会社をスケーリングし、Two Sigmaで手動技術作業に戻ることによってそれを学びました。

その組み合わせは、実際にエンジニアリング組織を実行する人々の彼女のフレームワークを着陸させます。

リーダーシップスタイルの分析

55/45の分割はフーニエが個人的な管理遷移の中頃の人々に最も価値があることを意味します。個別の寄与者からチーム・リードへ、チーム・リードからマネージャーへ、マネージャーからディレクターへ。彼女のフレームワークは最終目的地についてより遷移についてより重要です。ウィル・ラーソンフーニエのラダーが終わるところをピックアップします。彼の「Staff Engineer」型は、「The Manager's Path」が意図的に左側のICトラックをアドレス指定します。

主要なリーダーシップ特性

カミーユ・フーニエを定義した3つのフレームワーク

The Manager's Path（フーニエ・エンジニアリング・リーダーシップ・ラダー）

The Manager's Pathは、また、個々の寄与者を通してエンジニアリング・マネジメント・キャリア・トラックのフーニエ・エンジニアリング・リーダーシップ・ラダーと呼ばれます。テック・リード、マネジャー、シニア・マネジャー、ディレクター、VPオブエンジニアリング、CTO。各ラングは異なる主な関係、作業単位、そして名前付き失敗モードを指定します。最も一般的には、前のレベルの仕事の代わりにして現在のものをすること。ラダーは最新のソフトウェア組織でのエンジニアリング・マネジメント・キャリア・パスの支配的な参照モデルです。

管理ラダー

「The Manager's Path」の中央フレームワークはシンプルです。エンジニアリング・マネジメント階層の各レベルは異なる仕事を持ち、最も一般的な失敗モード各レベルで前のレベルの仕事をしています。

フーニエは特にラダーマップします。個別寄与者、テック・リード、個別寄与者のマネジャー、シニア・マネジャー（マネージャーのマネージャー）、ディレクター、VPオブエンジニアリング、CTO。各レベルは異なる主な関係と異なる作業単位を持ちます。テック・リードの主な関係はコードとチームとです。マネージャーの主な関係は個別寄与者です。ディレクターの主な関係は彼らのマネージャーです。VPの主な関係は組織的なシステムと採用パイプラインです。CTOの主な関係は会社の技術戦略とボードです。

各レベルでの失敗モードは明確に定義されます。マネージャーになるテック・リードはコードをすべて書き続け、彼らのエンジニアを改善させることに投資しません。シニア・マネジャーになるマネージャーは、マネージャーを構築するのではなく、個別寄与者すべてで1対1をしています。VPになるディレクターは個別チーム・レベルの決定を続け、組織構造を設計するのではなくします。これらの失敗の各々は実践で認識可能で、彼らの名前を付けることは何が修正可能かについてです。

エンジニアリング外のオペレータに、ラダー・フレームワークは管理階層の任意の組織に適用します。毎回の昇進での質問は。新しい仕事が古い仕事がしなかったことを要求するのは何ですか。あなたが明確にこれに答えることができなければ、彼らはスキルで昇進したロールを埋めるかもしれません。ロールが必要とするスキルではなく。

1対1監査

フーニエは1対1が何のため、そしてそれらが何のためではないかについて具体的です。それらはステータス・ミーティングではありません。彼らはプロジェクト進捗の確認ではありません。彼らは、早期警告で、タレント・リスク、キャリア不満、チーム・ダイナミクス問題のマネージャーが持つプライマリ・ツールです。他のどのフォーマットでも表面化しません。

彼女が推奨する具体的な議題には3つの部分があります。キャリア。この人は何のために仕事をしていますか、そして彼らの現在の作業は彼らをそれに向かって移動しています。現在の課題。今何が彼らの方法で得ているのか、そしてあなただけが削除できるものはあります。チーム・ダイナミクス。彼らの周りの人々とはどのようにしているのか、そして表面に到達していない摩擦ポイントはありますか。

ほとんどの1対1がステータス・ミーティングになった理由は、マネージャーはプロジェクト・ステータス議論がキャリア満足のグループ・フリクションについてダイレクト・コンバーサーションを持つよりも快適ですること。ステータスは安全です。実際の1対1議題はマネージャーが所有して修正する必要があるかもしれない問題をサーフェス。不快さは情報です。ダイレクトが1対1で問題を上げるのを停止する瞬間、あなたは早期警告システムを失いました。彼らが辞表に伝えている時点までに、あなたはすでにそれを修正するウィンドウを失いました。

テクニカル・デッドビジネス決定

フーニエは、エンジニアリング・リーダーの最も一般的な失敗モードについて広く書き、話してきました。技術的懸念を予算を得ることができる言語に翻訳することができません。

技術債の工学フレーミングは品質志向です。「コードは混乱しており、機能を追加するのが難しく、バグのリスクが増加しています」。そのフレーミングは真実ですが、資源配分決定をするCFOまたはCEOに無用です。ビジネス・フレーミングは異なります。「この技術的制約は、私たちが参照すべき場所に対して大ジャンプ速度を25〜30%低下させています。市場の変化に応答する私たちの能力を遅くします。そして、ここに、次の2四半期で対処しない場合のリスク・プロフィールはどのように見えるかです」。

フーニエの議論は、その問題を修正する予算を得ないCTOはできません。つまり、債務は複合化します。つまり、ベロシティ・ペナルティは成長します。つまり、次の予算議論はさらに硬く勝つ。翻訳は複雑な技術問題を簡略化することではありません。これらビジネス結果にそれらをリフレーム。時間、リスク、ベロシティ。これらは3つの通貨エグゼクティブは実際に割り当てます。ジーン・キムは操作側から同じ問題をアドレス指定します。彼のDevOpsの最初の方法は展開ボトルネックをフローとして再フレームし、エンジニアだけでない流約制約問題をCFO と COOが参加できます。

彼女もCTOがこの議論をすることができないときに何が起こるかについてダイレクトです。債務はビジネスに見えません。エンジニアリング・チームは正当な技術的懸念が無視されることに不満です。そして、組織はなぜ彼女が遅くなっているのか理解なしで遅くなります。

あなたの役割でカミーユ・フーニエは何をするでしょうか

あなたがCEOなら、フーニエが提供する最も有用なことはあなたのエンジニアリング組織の管理品質のための診断です。「良いエンジニアがいますか」ではなく、質問。「私たちのエンジニアリング・マネージャーは何が彼らの仕事であるかを知っていますか」。答えが「いいえ」なら、SDRチームを構築することはあなたの不確実性を増幅し、解決しません。SDRモデルはすでに機能しているモーションのためのスケール・メカニズムです。モーションを見つけるやり方ではありません。

あなたがCOOまたは売上高操作リーダーなら、フーニエの1対1フレームワークは管理階層を持つすべてのチームに適用します。あなたのマネージャーに尋ねる質問。いつ最後にダイレクトが辞任であなたを驚かせましたか。答えが「最近」または「定期的に」ですなら、あなたのマネージャーはステータス・ミーティングを実行していません。1対1。1対1はタレント・リスクのための唯一の早期警告システムマネージャーは。彼らがそれを使っていないなら、あなたは視察なしでも実行しています。タレント・リスク。人々が出て行ったドアまでの保持まで。

あなたが製品リーダーなら、フーニエの技術債フレームワークは直接有用です。あなたはエンジニアリングが技術債を削減する時間を望みながら、製品機能を望む最も一般的な組織的葛藤の1つの側です。その紛争が解決しない理由はどちらの側も他の言語を話すことです。フーニエのフレーミング翻訳債は速度とリスクに、あなたに共有決定フレームワークを与えます。「エンジニアリングはテクニカル・デッドを削減する時間が必要です」対「製品は機能を必要とします」ではなく、あなたが聞きます。「この対応コストはこれらの機能を遅くするのを超えている、そしてそれは超えますか」。その質問は双方が参加できます。

あなたが営業またはマーケティングなら、管理ラダーはあなた自身の組織に適用します。最高担当者であったために昇進されたすべての営業マネージャー。彼らが実際に管理しているのかチェックする方法を与えるフーニエのフレームワークがあります。彼らのチーム、開発代表人を通じてパイプラインを構築し、戦い。マネージャー個人的な取引を反映するチーム・レベルの判断ではなく、予測。失敗モードは同じです。昇進に有効なスキルのため昇進。新しいレベルが必要とするスキルで装備されていない。

Rework がフーニエ・ラダーを操作する方法

フーニエのラダーはマネージャーがすべての彼らのレベルに一致するユニット・オブ・ワークを見ることができるのでのみ作動します。Rework はその可視性のために構築されます。Reworkの仕事管理パイプライン（月額1ユーザー6ドルから）はテック・リードとマネージャーが彼ら自身の高さで配信をトラッキングさせます。IC はタスク、マネージャーを見る、チーム・スループット、ディレクターは同じビューに誰もが強制なしでチーム・フロー。キャリア・ラダー・テンプレートは役割ごとの構造化チェックリストとしてモデルできます。1対1 と昇進レビューの間に「このレベルが実際に何を要求するか」質問は構体的な答えエンジニアとマネージャーが参照する背があります。

テック・リードのために、Reworkはフーニエが説明する正確な遷移をサポートします。チーム・オプス・ダッシュボードはサーフェス・リードがコードの多くを持つかどうか対。彼らのエンジニアを開発。クロス・チーム・ビジビリティは、ディレクターがマネージャーがレベルをスキップするのを見ることができるとき。ICの仕事をするのか、プロジェクト自体を通じて実行するのではなく彼らのチームを通じて。Reworkの CRM/Sales Ops（月額1ユーザー12ドルから）は販売管理に同じラダー・ロジックを適用し、フーニエのポイントに一致するのはモード失敗は管理階層全体でジェネラライズです。

注目すべき引用と教室外の教訓

フーニエはさまざまなトークで言いました。「最高のエンジニアリング・マネージャーは、彼らが責任がない明確に言うことができる人です」。それは反直感的なステートメント。ほとんどの管理アドバイスは責任の拡張についてです。彼女のポイントは明確さについてです。自分の役割の境界を特定できないマネージャーは役割を彼ら快適に行っている何かで埋めるロールします。通常、彼らが持った仕事です。

「The Manager's Path」から。「マネージャーとして、あなたの仕事は可能な限り少なくしていることです」。彼女はすぐに明確にします。少しが可能な限りは最小限の努力を意味しません。マネージャーの仕事は、エンジニアが彼らの最高の仕事をすることができない条件を作成することです。彼ら自身のため。強いエンジニアのプレート彼らが扱うことができるのを取ったすべてのタスクは学習機会を逃し、マネージャーの増加依存性。目標はあなたが存在しないときうまく実行されるチームです。

彼女もビジネス執筆で本の限界について公開されているされて。「The Manager's Path」は安定したエンジニアリング組織で製品会社のために書かれました。彼女は、ラダーモデルが非常にマトリックス組織や報告行と変数プロジェクト・スコープが定期的に進むコンサルティング・ファームで複雑化されることを認めた。それは免責事項ではありません。フレームワークを適用するときと、それを適応させるときを知るための有用な境界です。

リーダーシップスタイルが壊れるところ

フーニエのラダーモデルは安定した管理階層を持つ製品会社でクリーンに運び。ディレクター・レイヤーを持つにはエンジニアリング構成でその十分な大きさ（ですが、複数の競う報告構造を持つ組織チャートは十分な大きさではないため、または非常に大きくない）。マトリックス組織の相談で、また、報告線がプロジェクト・スコープすべてのプロジェクトシフトで変数するエージェンシーでは、「ここが何のために仕事があるのか」フレーミング、フレームワークの苦労ですが、仕事が安定していないため正確にはできません。説明。

そして本の深さは個々の管理遷移で、最も重要な組織設計問題を曇らせることができます。CTO レベルで重要：チーム・トポロジー、プラットフォーム対製品エンジニアリング分割、ビルド対提供決定。「The Manager's Path」ですべてのレベルの下で CTO レベルでより良いマネージャーを作成します。CTO レベルで、問題は、良い人々をマネージングから、彼ら作品システムのデザインに移動します。これは異なる本です。

---

エンジニアリング・マネジメント技術リーダーシップについて関連読みについてのため、ウィル・ラーソン リーダーシップスタイル、ジーン・キム リーダーシップスタイル、マーティン・フォウラー リーダーシップスタイル、ジェフ・ディーン リーダーシップスタイル。