ケルシー・ハイタワー のリーダーシップスタイル：Kubernetes を人間らしくした開発者アドボケート
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
ケルシー・ハイタワー はキャリアを通じて「VP Engineering」または「CTO」をタイトルに持っていませんでした。彼は Principal Engineer と Staff Developer Advocate の役割を保有していました。それでも、彼はクラウド インフラストラクチャの歴史で最も影響力のあるデベロッパー アドボケートとして広く引用されています。
「Kubernetes the Hard Way」は彼が書いた無料の GitHub チュートリアルで、ほとんどの $50,000 企業トレーニング プログラムより多くの実際の学習インパクトを持っています。2016 年の KubeCon ライブ デモでは、彼は YAML なしで Kubernetes を展開および管理しました。カンファレンス伝説になりました。Google Cloud で 2016 年から 2023 年まで、彼はプラットフォーム エンジニアの世代全体がその仕事についてどのように考えているか を形作りました。
2023 年 7 月に 42 歳で Google から引退したとき、献金は従業員の離職よりも創業者の別れのように見えました。彼は決して会ったことのないエンジニアが、彼のチュートリアルがキャリアをどのように変えたかについて書きました。これはあなたに、教育者ファースト リーダーシップが組織に何をするのか、そして業界全体に何をするのかについて何かを伝えます。
主要事実：一目でのケルシー・ハイタワー
- 役割： Principal Developer Advocate、Google Cloud（2016～2023）
- 引退： 2023 年 7 月、41 歳で、テクノロジーで 25 年間
- 署名貢献： マーケティングではなく教育を通じた Kubernetes 導入の先駆者
- フラッグシップ作品： 「Kubernetes The Hard Way」— エンジニアをブートストラップ Kubernetes マニュアル、コンポーネントごとに案内する無料の GitHub チュートリアル
- 既知： 明確な技術コミュニケーションと「人間第一」のエンジニアリング支援
- 以前の役割： CoreOS、Puppet Labs—常に実践者アドボケート、決して幹部ではない
ハイタワー クラリティ原則
ハイタワー クラリティ原則は、技術的影響は上部に構築された抽象化を所有するのではなく、その不可約なコアで複合化することを保持しています。リーダーの仕事は、午前 3 時に操作する必要があるエンジニアに複雑なシステムを理解できるようにすることです。その明確さはタイトルまたは任期ではなく、構築、失敗、および公開で教育することによって获られます。
リーダーシップスタイルの分析
| スタイル | 重み | どのように現れたか |
|---|---|---|
| 教育者ファースト | 65% | ハイタワーの主要な運営モードは常に次のとおりです。「これを理解できるようにするにはどうすればよいですか？」Puppet、CoreOS、Google Cloud では、彼の本能は販売する前に教育することでした。「Kubernetes the Hard Way」が存在する理由は、エンジニアが Kubernetes を手動でビルドした場合（ブートストラップ証明書、etcd の構成、コンポーネントを 1 つずつ立ち上げるため）、彼らは抽象化レイヤーが提供できないレベルで彼らが運営しているもの を理解するためです。基礎への忍耐—抽象化が利用可能な場合でも—教育者本能です。それは遅いです。マーケティング メトリックスのために最適化されていません。しかし、それはスケーリングする理解の種類を構築します。 |
| 謙虚さ駆動アドボケート | 35% | ハイタワーのクレジットは、本物の技術的深さと、それを実証することについてのエゴの欠如の特定の組み合わせから来ています。彼は、彼が知らないことを認めるのと同じくらい快適です。彼は知っていることを実証するのと同じくらい。同じグランドレベルのクレジットは、Amazon で Werner Vogels の公開ライティングを通じて実行されます。CTO は、実践者の座から分散システムの トレードオフについてブログを書き続けました。エグゼクティブの抽象化に後退しません。有名な「no-code Kubernetes」ツイートは自己否定的でした。彼は本質的に、彼の固有のコミュニティがそのツーリングを過度に複雑にしたことを認めていました。ほとんどのアドボケートはプラットフォームを使用して雇用者の製品を増幅します。ハイタワーは彼のプラットフォームを使用して、製品を不必要に複雑に見えた場合を含め、彼が見た真実を伝えました。 |
65/35 の分割は、ハイタワーが製品マーケティングではなく技術コミュニティ構築を理解したい人々から研究されている理由を説明しています。彼の教育者モデルは信頼を生み出したもので、信頼は彼のアドボケーシーが着地したものです。
主要なリーダーシップ特性
| 特性 | 評価 | 実践においての意味 |
|---|---|---|
| 複雑なトピックの過激なシンプルフィケーション | 例外的 | Kubernetes は、モダンなソフトウェアで最も複雑な分散システム インフラストラクチャの 1 つです。ハイタワーの才能は、不可約なコア、このもので何を操作する必要があるか、およびツーリング、抽象化、既にそれを理解している人々のために書かれたドキュメンテーションによって追加された複雑さなしでそのコアを提示する能力です。「Kubernetes the Hard Way」は Google のドキュメンテーションと同じ方法で Kubernetes を説明しません。経験したエンジニアが後輩の同僚に説明する方法で Kubernetes を説明します。あなたが実際にやっていることとなぜです。これは完全なドキュメンテーションを書くより難しい才能です。 |
| コミュニティ信用対企業権限 | 例外的 | ハイタワーの影響は組織的なことはありませんでした。彼は Google が彼らに言ったので Kubernetes を導入するようにエンジニアに伝えることができませんでした。彼らがそれの価値があると説得する必要がありました。説得はデモンストレーションから来ました。ライブ デモでは、物事がうまくいかなかったし、彼はリアルタイムで彼らを修正しました。無料のチュートリアルは見返りを求めていません。コミュニティの問題をアクティブに認めました。その種のコミュニティ信用は何年もかかります。単一のトランザクション移動で破壊する可能性があります。ハイタワーはその移動を決してしませんでした。 |
| 教育ツールとしてのライブ デモンストレーション | 非常に高い | 彼の会議デモは伝説的になりました。彼らは本当に危険でした。彼は事前に焼きた結果の安全ネットなしで段階的にライブ システムを実行しました。物事が壊れた場合、彼は公開でそれらをデバッグしました。その選択は何か具体的に通信します。私はこれを十分に理解し、あなたの前で失敗するのを恐れていません。その自信は、それ自体が教育信号です。聴衆に習熟度をはじめて問題を持つことについてではないことを示します。それは問題が生じたときに問題をナビゲートする方法についてです。 |
| 知識で公開的な寛大さ | 高い | 「Kubernetes the Hard Way」は無料で、GitHub で公開されており、意図的に金銭化されていません。ハイタワーは数百のイベントで会議の話をしました。彼は彼のレベルの多くのエンジニアが迷惑に思わない方法で、ソーシャル メディアで初心者とやり取りしました。その寛大さは意図的なリーダーシップの選択です。リターンは、ペイウォールされたコンテンツとゲートコミュニティが到達できないスケールで信頼と影響力です。 |
ケルシー・ハイタワーを定義した 3 つの決定
「Kubernetes the Hard Way」を GitHub で無料で公開する
ハイタワーが 2016 年に「Kubernetes the Hard Way」を公開したとき、Kubernetes は新しく、複雑で、恐ろしかったです。既存のドキュメンテーションはほとんどのエンジニアが持っていなかったコンテキストを想定しました。彼の位置にあるほとんどの企業は有料トレーニング プログラムを構築するか、深い技術的知識を組織内に保つでしょう。
ハイタワーはそれを GitHub で公開し、無料で、ペイウォールなし、電子メール キャプチャなし。チュートリアルはエンジニアに Kubernetes を完全に手動でブートストラップさせました。すべてのコンポーネントが手動で構成され、彼らは抽象化するツールで機能する前にシステムを理解しました。
長期的な効果は重大でした。「Kubernetes the Hard Way」を通じて仕事をしたエンジニアは、彼らが操作しているものを理解した実装者になりました。彼らは彼らのチームに Kubernetes を推奨した人になりました。エコシステムに貢献しました。次のジェネレーションを訓練しました。ハイタワーは彼らのお金が必要でしませんでした。彼は何か多くの価値のあるを得ました。彼らの信頼と、その信頼の複合ネットワーク効果は、彼らが働いた各組織を通じて広がっています。Linus Torvalds は数十年前に Linux カーネルで同じ計算をしました。メーリング リストで無料でソースをリリースし、独占配布ができないことはコミュニティ導入をさせました。
オペレーターが知識配布について考えている場合、レッスンは寛大さへの戻りについてです。ほとんどの企業は技術的知識を保護される競争資産として扱っています。ハイタワーの賭けは、知識を自由に配布することで、それを希少に保つより多くの影響と導入が戻されることでした。賭けはスケールで払われました。ペイウォールされたトレーニング ビジネスを構築した方のエンジニアでも調整する必要があります。
「No-Code Kubernetes」ツイート
2018 年に、ハイタワーはフォロワー カウントをはるかに超えてスプレッドツイートを公開しました。Kubernetes は実質的に YAML 構成なしで実行されている、コミュニティがシステムの周りに蓄積していた多くのボイラープレートを皮肉で強調しています。
ツイートは技術的でしたが、メッセージは組織的でした。システムの周りに構築するツールは、システム自体より複雑になる可能性があります。すべての YAML 抽象化、すべての Helm チャート、すべてのオペレーター パターンは、実際の問題を解決するために追加されました。しかし、蓄積した複雑さは Kubernetes をより簡単に操作してもらいました。難しくしました。
ツイートが着地したのは、自己批判的だったためです。ハイタワーは Kubernetes エコシステムの構築に役立ちました。彼は彼が создал構築することの一部である何かを批判していました。その種の公開的な自己批判は、コミュニティの中央の人物から珍しく、正確にはそれが信頼できるようにしたものです。彼はコミュニティの外から指を指す批評家ではありませんでした。彼は彼がいくつか所有している仕事の失敗モードを認識する中心人物でした。
リーダーが公開通信について考えている場合、ツイートはマーケティングと誠実さの違いについてのケーススタディです。マーケティングは Kubernetes 2.0 がもっとシンプルであった方法についてのブログ投稿を公開していました。ハイタワーはコミュニティが自分自身を笑い、複雑さについてもっと硬く考えさせるツイートを公開しました。後者が広がります。前者は無視されます。
42 歳で Google から引退する
2023 年 7 月に、ハイタワーは 42 歳で Google から引退しました。彼は強制されていません。彼は別の企業に移っていません。彼は選択によって引退し、彼のプラットフォームはおそらくそのピークであった瞬間に、スピーキング、ポッドキャスティング、選択的アドバイスを追求します。
決定は本当に珍しいため分析する価値があります。ハイタワーのレベルの影響を持つ人々は 42 で引退しません。彼らはエグゼクティブ役割、ボード、またはレイズ ファンド。インセンティブ構造は蓄積を指す。より多くのタイトル、より多くの権限、より多くの資本。
ハイタワーは制約の異なるセットを選びました。彼の公開説明は完全性と意図についてでした。彼はその企業のレベルで企業雇用が伴う義務なしに、彼が気になったことに取り組みたかった、彼のスケジュール、。これは異なるセットの制約です。彼が設定した計算 from Jeff Dean は Google の深い内で数十年間滞在し、基礎的な研究をシップし続ける計算を設定します。しかし、両方の選択肢は同様の基本原則を反映しています。仕事が重要です。タイトルではなく。
彼のポストリライアント影響が時間の経過とともに劣化するかどうかは開いている質問です。彼の公開の存在は Google を去ってから不頻繁でした。しかし、決定自体は彼が働いている方法について何かを通信します。タイトルなしで、より難しい。教育者モデルは彼が Google で構築したものの 1 つで、機関プラットフォームとは独立した所有です。
ケルシー・ハイタワーがあなたの役割ですること
あなたが CEO であれば、ハイタワーのコミュニティ信用モデルは技術市場で会社のブランドについて考える方法に適用可能です。デベロッパー コミュニティは企業を信頼しません。彼らは時間をかけて技術的信用を実証したり、物事が機能しなかったときに正直だった人々を信頼しません。技術コミュニティで企業にクレジットが必要な場合、投資はマーケティング コンテンツ機能を発表するエンジニアではなく、公開の深さを実証できるエンジニアにあります。これらはさまざまな予算とさまざまな戻り時間です。
あなたが COO であれば、ラジカル シンプルフィケーション 特性は、内部ツーリングとプロセス設計について考える方法に直接役立ちます。あなたの組織が構築した複雑なすべての内部システムはそれが開始されたときシンプルでした。複雑性は段々と蓄積され、各添加が実際の問題を解決し、システムがそれをサポートすることになった基礎的な仕事より難しく操作するまで。ハイタワーの本能、定期的に最初の原則に戻し、不可約なコアが実際に何であるかを尋ねること、は蓄積したプロセス複雑さを管理するオペレーション リーダーのための有用な慣行です。
あなたが製品リーダーであれば、ハイタワーの教育者モデルは製品オンボーディングにマップします。ほとんどの製品は既に使用しようとしている人々のためにドキュメント化されています。ハイタワーのチュートリアルは、まだ彼らが製品をすべても使用する理由を理解していない人々のために設計されています。これは異なるコンテンツ目標です。欲を構築する前に理解を構築しています。この権限を得ているチームは、アクティベーション メトリックスのために最適化するチームより異なる種類の顧客ロイアルティを構築します。
あなたが営業またはマーケティングであれば、「Kubernetes the Hard Way」レッスンば ゲートコンテンツとゲートなしコンテンツの違いについてです。ゲートコンテンツがリードを生成します。アンゲート コンテンツは信頼を構築し、より広くスプレッドします。ハイタワーのチュートリアルは、共有するための障壁がなかったため、エンジニアリング コミュニティを通じてスプレッドしました。彼を通じて仕事をしたすべてのエンジニアは、学ぶ必要のある別のエンジニアと共有しました。無料の教育コンテンツの ウイルス係数は鉛キャプチャ コンテンツのウイルス係数より多くです。時間の経過とともに複合する信頼について構築します。
Rework でハイタワー クラリティ原則を適用する
明確さ駆動の技術的リーダーシップは、ops の複雑さが チームの読む能力を上回る瞬間に分解します。ほとんどの運営スタック は「蓄積 YAML」 の失敗モード ハイタワーがコールアウトされた方向へ漂います。CRM はリード ルーティングにボルトされ、チャット ツールはプロジェクト タスク、ファイナンス システムが売上承認にボルトされ、それぞれが実際の問題を解決しますが、個別に彼らが運営する方が難しくなります。彼らサポート作品より。ハイタワー 本能は、その スタック をその不可約なコアに定期的に削減し、毎日の仕事を行うエンジニア、担当者、またはマネージャーに読める再度にすることです。Rework はその翻訳仕事のために構築されています。1 つのコネクティッド ワークスペースで CRM、リード管理、チャット、クロスチーム ops は統合データ モデルに対して生きています。取締役が見るオペレーティング画面は、マネージャーおよび個別の貢献者が見る画面です。$12/ユーザー/月 CRM と Sales Ops、Work Ops で $6/ユーザー/月 開始すると、ポイントは価格ではなく、チームは 5 つを調整する代わりに 1 つのシステムを読んでいます。
注目すべき引用と教室外の教訓
ハイタワーはさまざまなインタビューで、開発者アドボケートが彼らの仕事がマーケティングの変化についてマーケティング生成関数を提供するようにマーケティング になるときに失敗することを述べました。失敗モードは予測可能です。アドボケートが鉛と言及のために測定されるとすぐに、コミュニティが営利的として即座に認識しているコンテンツを生成し始めます。技術的コミュニティは無認証を検出する最速の中にあり、クレジットが失われたら、それは戻りません。
謙虚さと技術的信用についての関係、彼は一貫しました。技術コミュニティで最も敬意を持つエンジニアはほぼ正しい最も信頼できる主張を作成しないです。彼らは事をはっきり説明し、彼らが知らないことを認識し、彼らの仕事を通じて彼らの言及ではなく示しています。ライブ デモ慣行はその信念の物理的な現れです。彼は自分の理解の深さについて公開に失敗できるため、デモを実行しました。
彼はまた教育者パスの限界についても直接的でした。個別のレベルまでスケール化されていません。ハイタワーは何百万人のエンジニアに影響を与える可能性がありましたが、Google で単一の製品の決定を作成することはできませんでした。彼の影響は完全にコミュニティでした。組織ではなく。オペレーターがどのような種類の影響を構築するか考えている場合、これは重要な区別です。コミュニティ信用と組織権限は異なるもので、異なる方法で構築され、異なる方法で劣化し、異なる種類のレバレッジを与えます。
このスタイルが失敗するところ
ハイタワーの教育者モデルは本物の深さが必要です。アドボケーションをしている人が実際の実践者がない場合は機能しません。彼のモデルをレプリケートしようとする企業は、エンジニアが表面レベルとして即座に認識するコンテンツを生成し、モデルが依存する信頼を破壊しますが、実際のコンテンツを実装するより低い技術の深さが必要です。前提条件は本物の専門知識です。単純なコミュニケーション スキルではなく。
彼のスタイルはまた、コミュニティの忍耐を想定しています。聴衆が遅く学び、深さが時間に価値があることを信頼しようとします。高速製品ローンチ サイクルでは、「遅く教えて信頼を構築」は「素早くシップして注目をキャプチャ」と直接競争しています。 即座の市場インパクトが必要な組織はハイタワーのモデルを助成しています。リターンは本物ですが、四半期ではなく年数で複合化しています。Google から引退してから、教育者主導の影響が機関プラットフォームを持つ必要があるかどうかを維持するかどうか、本当に開いています。
ケルシー・ハイタワーのリーダーシップについてのよくある質問
ケルシー・ハイタワーは誰ですか？
ケルシー・ハイタワーは、2016 年から 2023 年までの Google Cloud の Principal Developer Advocate として最もよく知られているアメリカのソフトウェア エンジニアとテクノロジストです。彼は、Kubernetes 導入とクラウド ネイティブ インフラストラクチャで最も影響力のある声の 1 つとして広く考えられており、2023 年 7 月に 41 歳で、完全な技術作業から引退しました。
ハイタワーは Kubernetes 導入にどのように貢献しましたか？
ハイタワーはマーケティングではなく教育を通じて Kubernetes を普及させました。彼は無料の「Kubernetes The Hard Way」チュートリアルを書き、Kubernetes なしで段階的で YAML なしで会議デモを実行し、数百のイベントで話しました。彼の明確な説明は、自分たちの企業で導入するのに十分な深さを理解するプラットフォーム エンジニアの世代全体を支援しました。
「Kubernetes The Hard Way」とは何ですか？
「Kubernetes The Hard Way」はハイタワーが 2016 年に GitHub で公開した無料のオープン ソース チュートリアルです。エンジニアに Kubernetes クラスタを完全に手動でブートストラップさせて、証明書を生成したり、etcd を構成したり、各コンポーネントを手動で立ち上げたりします。彼らは高いレベルのツールが抽象化するもの を理解します。彼女は意図的に速度に最適化されていません。包括性のために最適化されています。
ハイタワーは 2023 年になぜテクノロジーから引退しましたか？
ハイタワーは 2023 年 7 月に 41 歳で Google から引退し、テクノロジーで約 25 年。彼は出ていなく、別の企業に移っていません。公開コメントでは、彼は完全性と意図の周りに決定をフレーム化しました。彼は彼のスケジュールで彼が気分を悪くしたことに取り組みたかった。彼は企業の雇用が彼の専門レベルで来ることなく。
ハイタワーのコミュニケーション スタイルは何ですか？
ハイタワーのスタイルは教育者ファースト で人間第一です。彼は複雑なシステムの不可約なコアを識別し、官立ドキュメンテーションが実行する方法ではなく、上級エンジニアが後輩の同僚に説明する方法で説明します。彼は滑らかなスライドより生デモンストレーションを好み、彼が知らないことを認め、彼が構築するのを支援した Kubernetes を含むエコシステムの複雑さを公開的に批判する意欲があります。
エンジニアリング リーダーはケルシー・ハイタワーから何を学べますか？
エンジニアリング リーダーは、技術コミュニティ信用が実証されたディープ、公開の知識の寛大さ、正直なコミュニケーション—タイトルまたは企業権限ではなく。ハイタワーのキャリアは、明確な教育、ゲートなしコンテンツ、および公開の失敗をいとわない意欲が、単一の雇用者またはプロダクト サイクルを超える影響に複合化することを示しています。
技術コミュニティ構築とエンジニアリング リーダーシップについての関連読書については、Linus Torvalds リーダーシップ スタイル、Werner Vogels リーダーシップ スタイル、Camille Fournier リーダーシップ スタイル、Jeff Dean リーダーシップ スタイル、Martin Fowler リーダーシップ スタイル、Will Larson リーダーシップ スタイルを参照してください。
