エンジニアからCTPOへ:スケールでの技術リーダーシップ
エンジニアからCTPOへの道は直線的ではありません。より良いコードを書くことや、より多くの人を管理することについてではありません。問題、解決策、組織について考える方法の根本的な変化についてです。
私はこの旅をしてきました—AutodeskとKore.aiでコードを書くことから、Fyndでエンジニアリングと製品をリードすることまで。スケールでの技術リーダーシップについて学んだことをここに示します。
技術的基盤
技術的深さなしにエンジニアリング組織をリードすることはできません。しかし、技術的深さだけでは不十分です。
キャリアの初期に、私はより良いエンジニアになることに焦点を当てました。新しい言語、新しいフレームワーク、新しいアーキテクチャを学びました。これは必要でしたが、十分ではありませんでした。
技術的深さは信頼性を与えます。問題を深く理解できるようにします。より良い決定を下すことができます。しかし、組織を構築する方法、チームをスケールする方法、または技術をビジネス成果と一致させる方法を教えてくれません。
リーダーシップの変化
エンジニアからリーダーへの変化は、コーディングをやめることについてではありません。最適化する対象を変えることについてです。
エンジニアとして、次のために最適化します:
- コード品質
- システムパフォーマンス
- 技術的優雅さ
リーダーとして、次のために最適化します:
- チーム成果
- 組織的有効性
- ビジネスへの影響
これらは同じものではありません。完璧なコードを書き、完璧なシステムを構築できますが、チームが出荷できない場合、組織がスケールできない場合、技術がビジネス成果を生み出さない場合、リーダーとして成功していません。
エンジニアリング文化の構築
文化はあなたが作成するものではありません。決定の下し方、行動の報酬の与え方、組織の構造化の仕方から生まれるものです。
スケールでのエンジニアリング文化には以下が必要であることを学びました:
1. 価値としての技術的卓越性
単なる目標ではなく—価値です。技術的卓越性が価値である場合、チームはそれを優先する決定を下します。品質、アーキテクチャ、長期的思考に投資します。
しかし、技術的卓越性だけが唯一の価値であることはできません。また、以下も必要です:
- 出荷—チームは価値を提供する必要があります
- 学習—チームは実験し、反復する必要があります
- 協力—チームは効果的に協力する必要があります
バランスが鍵です。卓越性に焦点を当てすぎると、チームは出荷しません。少なすぎると、品質が低下します。
2. 明確な技術的方向性
チームはどこに向かっているかを知る必要があります。何を構築するかだけでなく、どのように構築するか。どのパターンを使用するか。どの原則に従うか。どの標準を維持するか。
これには以下ができる技術リーダーシップが必要です:
- ビジョンを明確にする—どこに向かっているか、なぜかを説明する
- 標準を設定する—良いものがどのように見えるかを定義する
- 決定を下す—技術、パターン、アプローチを選択する
- 思考を進化させる—学習し、スケールするにつれて適応する
3. 境界内での自律性
チームは速く動くために自律性が必要です。しかし、一貫性と品質を維持するために境界も必要です。
鍵は境界を明確に定義することです:
- アーキテクチャ境界—どのパターンを使用するか、何を避けるか
- 品質境界—どの標準を維持するか
- プロセス境界—どのプロセスに従うか
それらの境界内で、チームは決定を下し、速く動くための自律性を持つべきです。
チームのスケーリング
エンジニアリングチームのスケーリングは、より多くの人を雇うことについてではありません。チームが効果的に働けるシステムを構築することについてです。
採用
採用はあなたが行う最も重要なことです。悪い採用は良い採用が節約するよりも多くかかります。採用に投資してください。
しかし、採用は技術スキルだけについてではありません。以下についてです:
- 文化的適合—彼らはあなたの文化で繁栄するでしょうか?
- 成長の可能性—彼らは組織と共に成長できるでしょうか?
- 協力—彼らは他の人と効果的に働けるでしょうか?
技術スキルは必要ですが、十分ではありません。
構造
チームの構造化方法は、彼らが構築できるものを決定します。チームを以下を中心に構造化します:
- ドメイン—技術やプロジェクトではなく
- 成果—出力ではなく
- 自律性—制御ではなく
プラットフォームチームはプラットフォームを構築します。製品チームは製品を構築します。しかし、彼らは明確な境界とそれらの間の契約を必要とします。
成長
人々は成長する必要があります。組織で成長できない場合、彼らは去ります。成長を可能にするシステムを構築します:
- キャリアパス—前進のための明確な道
- 学習機会—新しいスキルを学ぶ機会
- 挑戦的な仕事—能力を伸ばす問題
しかし、成長は昇進だけについてではありません。より良いエンジニア、より良いリーダー、より良い貢献者になることについてです。
CTPOの役割
CTPOの役割は、技術、製品、ビジネスの交差点にあります。以下を必要とします:
- 技術的深さ—技術を深く理解する
- 製品思考—ユーザーと市場を理解する
- ビジネス洞察力—技術がビジネス成果をどのように推進するかを理解する
3つすべてなしにCTPOとして成功することはできません。製品思考なしの技術的深さは、間違ったものを構築することにつながります。ビジネス洞察力なしの製品思考は、重要でないものを構築することにつながります。技術的深さなしのビジネス洞察力は、守れない約束をすることにつながります。
学んだこと
技術的深さは組み合わさる
技術的理解が深いほど、決定が良くなります。しかし、技術的深さだけでは不十分です。リーダーシップ、製品思考、ビジネス洞察力も必要です。
文化は構造から生まれる
文化を直接作成することはできません。しかし、組織、プロセス、インセンティブを構造化して、望む文化を作成できます。
スケーリングにはシステムが必要
より一生懸命働くことでスケールすることはできません。チームが効果的に働けるシステム—採用システム、構造システム、成長システム—が必要です。
リーダーシップは成果について
出力ではありません。活動ではありません。成果です。チームは出荷していますか?成長していますか?ビジネスへの影響を生み出していますか?
旅は決して終わらない
目的地はありません。常に学習し、常に成長し、常に適応しています。成功する組織は、進化し続ける組織です。
厳しい真実
エンジニアからCTPOへの道は、より良いエンジニアになることについてではありません。異なる種類のリーダーになることについてです。技術的深さをリーダーシップ、製品思考、ビジネス洞察力と組み合わせるリーダーです。
この移行を行うエンジニアは、エンジニアであることをやめません。組織を構築し、チームをスケールし、技術をビジネス成果と一致させることができるエンジニアになります。
それがスケールでの技術リーダーシップが実際に何であるかです。より良いコードを書くことについてではありません。より良いコードを書き、より良いシステムを構築し、より良い成果を生み出すことができるより良い組織を構築することについてです。
旅は困難です。しかし、それだけの価値があります。スケールで解決する問題が最も重要な問題だからです。
Related Thoughts
AIによる新しい働き方:プロダクトエンジニアリングチームのための10の原則
AIはプロダクトエンジニアリングチームの働き方を根本から変えつつあります。AI時代における開発、オーナーシップ、コラボレーションを再定義する10の原則をご紹介します。
なぜAI-First組織設計がツールについてではないのか
ほとんどのAI変換は、組織設計が無視されるために失敗します。実際に機能するAI-First組織を構築する方法をここに示します。