- Honeycomb初のVP of Engineeringは2020年2月にDirector of Engineeringから昇進しており、この道のりは計画された役員キャリアというより、会社の成長の中で生まれた空白を埋めていく過程に近かった
- 初期のHoneycombでは共同創業者のCharity Majorsがほぼ全員をマネジメントしており、哲学は似ていても背景やスタイルの異なる2人がR&Dのマネジメント責任を分担していった
- 昇進は一度の大きな転換ではなく、小さな担当範囲の拡張の積み重ねであり、スタートアップで新しいプロセスと責任を作っていくことが中核的な経路になった
- 役割にふさわしい準備には、会社全体を見る思考、ゼネラリスト志向、複数の抽象化レベルを行き来する能力、責任感、システム思考、メンバーの成長支援、幅広い関係性が必要だった
- 優れたVP of Engineeringの姿は標準テンプレートで決まるのではなく、会社が今抱える問題、既存のリーダーシップやICの構成、技術課題、成長段階によって変わる
計画された役員キャリアではなかった出発点
- Honeycomb初のVP of Engineeringは2020年2月にDirector of Engineeringから昇進した
- 最初にHoneycombへ加わった目的はエンジニアとして働くことであり、必要であれば再びマネジメント職に戻るという前提があった
- 参加時点ではおよそ12人目の社員であり、初期スタートアップでは会社が成功するほどさまざまな段階で多様な仕事を担うことになると理解していた
- 特定の職務に強く固執する姿勢は、個人にも会社にも役立つより妨げになることがあると考えていた
- Honeycombを選んだ理由は、チームが賢く親切そうで、学べることが多そうであり、前職で欲しかったのに見つけられなかった製品のように見えたからだった
- 特定の役割へ素早く成長したいならSeries B以降のスタートアップ参加のほうが効率的かもしれないが、HoneycombにはSeries A段階で加わった
マネジメント責任が移っていったやり方
- 初期には共同創業者であり当時CEOだったCharity Majorsが、役員から個々のエンジニアまでほぼ全員をマネジメントしていた
- 2人はマネジメント哲学ではおおむね一致していたが、背景と強みは異なっていた
- Charity Majorsはインフラ、オペレーション、データベース、バックエンドエンジニアリングの経験が深かった
- 昇進した人物はデザイン、フロントエンド、プロダクトエンジニアリングから出発しており、プロダクトマネジメントやUXデザインとの協業を楽しんでいた
- メトリクスやモニタリング技術の経験は2人ともあったが、向き合い方は異なっていた
- Charity Majorsはそれをあまり好まなかった
- 昇進した人物は強い愛着を持っていた
- 仕事のスタイルの違いも大きかった
- 昇進した人物はルールとプロセスを重視し、日常業務でも趣味でも計画やリスク管理を多く行う
- Charity Majorsは直感的で即興的なスタイルで、危機的状況で特に力を発揮し、チェックリストを嫌い、ルールやプロセスが役に立たないときにそれをすばやく見抜く
- Honeycombの成長とともにR&Dのマネジメント業務は増え、それぞれの背景がより適した領域を中心に責任を徐々に分担していった
昇進は小さな担当範囲拡張の積み重ね
- VPへの道のりには、明確な単一のマイルストーンよりも無数の小さな段階があった
- 途中の肩書き変更は、振り返れば進展を示す目印としては有用だったが、通常は新しい会議が追加される以外に業務範囲が大きく変わる合図ではなかった
- 成長するスタートアップでは、プロセスや責任の隙間が絶えず生まれ、一見小さな漏れに見えた問題が、時間と注意を大きく奪う課題へと膨らむことがある
- 新しい問題を引き受けてレベルアップする機会は常にあるが、会社がそれを新しい肩書きや役割として認めるかどうかは別問題だった
- Honeycombの2人の共同創業者は、本人だけでなく他のメンバーに対しても、社内昇進と影響力の承認を積極的に支援していた
- 今後ほかのスタートアップを探すなら、高業績者を社内昇進で育てた実績があり、役割の範囲を超えてすでに影響を出している人を素早く認めて報いる経営陣や創業チームを探すだろうとしている
ICのマネジメントからマネージャーのマネジメントへの移行
- 全体の旅路でもっとも興味深い転換は、ICだけをマネジメントしていた状態からマネージャーもマネジメントするようになった時点だった
- この転換を望む人には、新しい会社で試すより、すでにチーム・技術・ビジネス上の課題を理解している会社で経験するほうがよいと考えている
- 既存のラインマネジメントのスキルの多くは移転可能だったが、追加されたマネジメント階層を通じて組織全体を効果的に「見る」方法を身につけるには時間がかかった
- 特に、組織内で摩擦が起きている箇所や、より多くの支援が必要な箇所を把握するのが難しかった
- エンジニアリング組織の人と問題を直接経験していたおかげで、マネージャーたちと一緒にチーム状況を評価する習慣と技術を作るまで持ちこたえることができた
外部VP候補の探索と社内昇進
- 会社の流れがやや揺らいでいた時期には、外部からVP of Engineeringを採用する案も検討された
- Charity Majorsはこれを率直に共有し、適切な人を探して選ぶ過程にも参加させた
- 何人かの優れたエンジニアリングリーダーと話したが、当時のHoneycombに合わない人もいれば、Honeycombを次のステップとして選ばなかった人もいた
- その後会社には新たな問題が生まれ、解決不能に見えていた以前の問題はより扱いやすくなった
- その時点ですぐに昇進したわけではないが、外部採用の検討は中止された
- ある水準以上のリーダーシップ昇進は個人ではなく会社に必要なものを基準にすべきであり、HoneycombにふさわしいVP of Engineering像を一緒に思い描く過程が役立った
その役割にふさわしい人になる助けとなった特性
- 全体論的な思考が重要な特性として機能した
- チームだけでなく、Honeycombという会社全体がより成功する方向に自然と焦点を合わせていた
- 部門・チーム・個人より会社全体の利益のために行動することが報われる環境でよく力を発揮した
- ゼネラリスト志向も役に立った
- ソフトウェア企業のほぼあらゆるビジネス課題とドメインに興味を持っていた
- スタートアップであらゆるピースがどう噛み合うかを見られることを好んでいた
- 必要であれば目立たない地味な仕事も引き受けることに抵抗がなかった
- 複数の抽象化レベルで仕事ができた
- 下位レイヤーを完全には理解していなくても、上位レイヤーの概念をすばやくつかめた
- 必要なときには細部まで入り込むことも楽しめた
- 強い責任感はスタートアップで役立つが、制約も必要だった
- 重要な仕事が機能横断の隙間に落ちやすいスタートアップでは有用だった
- ただし、仕事を抱え込みすぎたりチームの成長を妨げたりしないよう、やり切るか他の人に渡す努力が常に必要だった
- 人と技術システムの両方に関心を向けるシステム思考も重要な要素だった
- チームメンバーの成長を心から楽しむ姿勢も重要だった
- 次の段階に進む準備ができた人と、その人の能力の縁で解くべき重要な問題を結びつけることをエネルギー源にしていた
- 会社のあちこちに良好な関係を持っていることも必要だった
- 社内外の人々が外部候補に期待するよりも、その人物がその役割を担うことに強く期待を寄せる必要があった
役立った業務経験
- さまざまな段階と規模のスタートアップ、とくにB2B SaaSスタートアップでの経験が役立った
- B2CとB2Bのスタートアップは比較的異なる種類の問題を扱い、それぞれ独自の問題解決手法を発展させてきた
- 両方の領域を見るのもよいが、B2BまたはB2Cのどちらかに専門性を築くことにも価値がある
- 市場参入の方法、組織構造、エンジニアリング課題、スケールの課題はB2BとB2Cで異なることがある
- スタック全体で働いた経験も助けになった
- もっとも深いエンジニアリング経験はフロントエンド技術にあった
- ペアプログラミングを行い、DevOpsマインドセットを適用する複数の組織で初期経験を積んだ
- バックエンド、インフラ、プラットフォーム、運用エンジニアから学び、彼らがどう考え、どの問題を重視するのかを理解した
- すべてのエンジニアリング領域の専門家である必要はないが、複数チームへの共感と高いレベルでのドメイン理解は大いに役立つ
- 開発者ツールとモニタリング領域での経験もこの役割に合っていた
- 3社続けて開発者ツール企業で働いた
- Honeycombの製品を心から気に入っており、オブザーバビリティ、モニタリング、開発者ツール領域のさまざまな製品にも愛着を持っていた
- ドメイン知識とツールへの情熱は同僚の助けとなり、落胆しうる状況でのエネルギー源にもなりうる
運とチーム構成が生んだ適合性
- その役割にふさわしい人になれた背景には運も大きく作用した
- Charity Majorsと相互補完的なスキルと経験を持っていただけでは不十分で、初期のシニアICたちが重要なエンジニアリング課題をうまく処理していたことも重要だった
- フロントエンド出身のVP of Engineeringは比較的珍しい。スタートアップの最重要技術課題は通常、スケーラビリティ、信頼性、バックエンドアーキテクチャにあるからだ
- 継続的な障害、スケール問題、クエリやストレージエンジンの大きなアーキテクチャ課題が続いていたなら、より深いバックエンドや運用経験を持つ人物が選ばれていた可能性が高い
- Ben Hartshorne、Ian Wilkes、その他の優れたICたち、そして創業チームの堅実な設計判断のおかげで技術的な余裕があり、当時のリーダーシップの最優先事項はプロダクト戦略の実行とユーザー体験の向上だった
- 役員陣にはすでにgo-to-market機能で経験豊富な外部採用の役員がいた
- 社内で成長したリーダーと見なせるChristineとCharityも、以前の会社で創業者またはリーダーシップ経験があり、CharityはHoneycomb創業前から優れたマネージャーとして知られていた
- 役員陣が新任役員や社内昇進者により多く偏っていたなら、もう1人の役員を育てる余裕はなかったかもしれない
VP of Engineeringは会社の文脈によって変わる
- 最大の学びは、優れたVP of Engineeringの姿が文脈依存だということだった
- 以前は、優れたVP of Engineeringを形作る標準的な特性を列挙できると考えていたが、会社ごとに基本テンプレートがほぼ同じだという見方はそれほど正しくなかった
- ほとんどのソフトウェア企業でやるべき基本的な仕事は似ているが、それを率いる役員のあり方は、組織が現在抱える問題と、すでに存在する役員・マネージャー・ICの構成によって大きく変わる
- 役割に就いた後も、求められるものは固定されない
- 成長する会社では、他のスタートアップの役割と同様に、VP of Engineeringという役割も時間とともに形を変えていくことがある
1件のコメント
Hacker Newsの意見
このくだりが面白かった: 「Charityはもっと直感的で即興的なスタイルで、危機の中で最も輝き、チェックリストを嫌う」というのは、ほとんど何気なく口にした認識のように見える
言い換えれば、創業者は部下たちがリーダーシップのポジションに必要だと考える資格や特性を備えていない、という意味でもある
会社を立ち上げれば自動的にCEO、CTOなどになり、今では大企業になった会社の創業者たちも同じだ
創業者は肩書きを正当化する特定の資格を必要とせず、自分でリーダーになったあと友人たちを最初の従業員として選ぶ
採用が正式化されるのはずっと後で、階層構造をどれほど能力主義だと信じたくても、その始まりが明らかに混沌としていたのは確かだ
階層的で服従的な考え方はいつも奇妙に感じられたし、前職の上司たちが自分より「優れている」と思ったこともない
会社のはしごを上ることは本質的に政治に近く、「シニアエンジニアとは何か」のような終わりのない文章も、階層を正当化しようとする企業化された思考から出ているように見える
だが時間がたてば、会社を潰さず成功させることでその地位を正当化しなければならない
これは多くの場合、どんな評価よりもはるかに正直で過酷な能力測定の方式だ
Googleのような大企業は、無能で怠惰なVPが1人いる程度では倒産しないので、評価制度が必要になる
https://gwern.net/backstopと比較してみるとよい
私は完全に実行型だが、共同創業者にとって理想的な特性は自分と正反対だと早くから学んだし、ここで見えているのもその違いだ
描写されている人物は典型的な非典型リーダーで、即興的であちこち飛び回り散漫になりうるが、同時に優れたイノベーターであり人を動かすモチベーターでもある
成功するスタートアップには非典型的な人物と実行型の人物の両方が必要だ
Rocket Fuelを勧めたい: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
異なる2つのスタイルが存在するという率直で友好的な認識に見えるし、そうした違いを認めるのは健全なことであって、階層への暗黙の訴えではない
むしろ「部下」「上司」のような表現を使い、会社の設立を階層の設立と同一視している点で、階層を疑っているという言葉とは裏腹に、コメント全体が階層を強化している
知識産業では管理者はリーダーではなく支援要員だ
最高のソフトウェア管理者や役員は、実際のリーダーや専門家、つまり仕事をする個人貢献者が働きやすくなるよう支える役割だと理解している
経営陣の支援機能の1つは、そうした期待を自らの行動で示すことだ
スタートアップが大企業に買収されると、そのスタートアップのメンバーの誰一人として、その会社のHR基準では採用されなかっただろうという事実が明らかになると、かなり面白いことになる
そして突然、そのスタートアップのチームメンバーたちが、HRが承認した学歴の良い大企業社員たちより先に昇進したりもする
多くの人がアメリカ式企業の指揮命令系統に洗脳されていて、ある肩書きを持っていれば実際にその肩書きに見合う資格があると想定してしまうことがあまりに多い
肩書きインフレはどこにでもあり、体感として肩書きは能力の承認ではなく、給与引き上げや勤続の評価の手段として使われることが多い
アメリカだけに限った話をするつもりではなかった
私の経験では、社内昇進の事例を探してみるという基準はかなり珍しい
ほとんどのスタートアップでは、階層上の新しい段階が必要になったり既存の人が去って席が空いたりすると、基本は外部採用になる
みんなが必要な仕事をうまくこなしているなら、わざわざいじらない方がよいという理屈のようだが、正直かなりやる気をそがれる
同僚が昇進して自分が押しのけられるよりもずっと気が抜ける。昇進と成長の文化があるなら、次には自分にも公正な機会があると信じられるからだ
だが常に外から採るのなら、この会社での自分のキャリアは入社時のポジションのままだ
その論理は、肩書き以上の成果を出せる賢い人たちを、できるだけ安く引き留めることに近く見える
転職には従業員の側に実際のコストがあり、景気が悪いほどそのコストは大きい
それでも去る人もいれば、静かに手を抜く人もおり、ただ耐える人もいる
私の経験では、彼らは適応を拒んだ結果、去るか解雇されることが多かった
10人のチームを管理できるからといって、100人の組織、まして1000人の組織を管理できるとは限らない
この事例が必ずそうだというわけではないが、場合によってはピーターの法則を避ける正当な理由になる
その欠点に耐えてきたか、そもそも見えていない人たちが昇進するからだ
そうした欠点を見抜く経験を持つ数少ない外部採用者なら、かなりつらい時間を過ごす可能性が高い
最高リーダーシップの大半は社内昇進で上がってきており、ときには個人貢献者からVPまで上がった人もいて、その影響が見て取れる
複数の組織でその規模を経験した人が入ってくれば、組織には明らかに役立つと思う
実際に何をしてきて、今のVPの役割で何をしているのか把握しづらかった
きれいな言葉は多いのに、今一日の大半を何に使っているのかは明確ではない
「デザイン、フロントエンド、プロダクトエンジニアリング出身」という言い方もあまり多くの情報を与えない
自分もスケッチからFigmaレイアウト、SvelteKitのフロントエンド・中間層、FastAPI API構築までやる、まさにそういう人間だが、何が評価されてVPになったのか、現場を離れた今は何をしていて何をいちばん恋しく思っているのかが分からない
文章はものすごく長いのに、何を言いたいのかよく分からない
今日のFAANGより小さい会社で期待される役割や、エンジニアが管理職トラックに上がっていく経路を見るなら『The Manager's Path』は参考になる
役員レベルのリーダーシップに行くほど仕事はずっと戦略的になり、直接手を動かすことはまれになると思っていたが、この記事では自分を良いVPにしたという戦術的な経験や資質が多く並べられている
技術周辺部の貧しい人間として、会社で何か書けと強要された例をたくさん見てきたが、いつもこんな感じだった
キャンパス採用のときに検索結果へ最近の記事が出るよう、社内の人たちにこういう文章を一つ二つ書かせる
適度なおべっかと潜在応募者の持ち上げという二つの目的を同時に果たしている
https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
この記事は基本的に生存者バイアスとその合理化の例だ
欠けているのは、VP職に至る内部異動と外部採用のあいだにある統計的な観点だ
スタートアップであれ大企業であれ、社内からVPへ移るのは極めて難しいと思う
スタートアップは成功しなければならないし、大企業では何年も持ちこたえつつ良い政治的関係を築かなければならない
いちばん簡単な道は、下積みから始めると考えず、人生の早い段階で高い役職を狙い、ずっとそうし続けることだ
既存の会社で頂点まで上がれないなら、自分で作ればいい
下積みから始めるとそこに居続けることになるが、その種のスキルは最高レベルのリーダー職では価値がないからだ
試みてはいたが結局そうはならず、価値判断もなかった
優れた候補者を見つけられず、最終的に筆者が昇進したように見える
自分の前のスタートアップでもVPを探していたが、結局社内昇進にしたし、統計的に見ればそういうことは確かに時々起こる
筆者は「下積みから始めるとずっとそこに留まる」という最後の一文には同意しない気がする
会社のインフラが拡大中も安定して維持されたのは「下積みの人たち」が仕事をうまくやったからで、そのおかげで自分はより戦略を考える余地があったと言っている
上下の問題というより、どのタイプの問題をうまく解けるかに近いように見える
計画、管理、戦略が好きなら、上・中間・下のどの役割であってもその能力を使えるポジションを狙うのがよい
たとえば卓越したくないならJavaScriptの仕事で安住すればいいが、本当に競争的な場所へ自分を押し込み、本当に良いプログラマーになりたいならOCamlで呪われたコードを書くべきだ
ベンチャー投資を受けたスタートアップのCTOとして見ると、高い地位にいる人たちはたいてい賢く、狡猾さも同じカテゴリに入る
ただし同じくらい賢くても高い地位にいない人は多く、その理由は機会がなかったからだ
自分で事業を始めれば機会は増えるし、他社のVP職を得るために起業する人はいないにしても、有力な代替ルートにはなる
あるいは適切な人々を知るネットワーキングが必要で、普通は前述の起業ルートとセットになっている
Googleのような有名企業で働いたあと、もっと小さい場所へ移って大きな魚になるという方法もある
あるいは上司とそのさらに上の上司の目に留まり、直属の上司が辞任したときに次の任命候補になる必要がある
一つ学んだのは、会社が能力以外の理由で役員を昇進・採用しているのを見たら、新しい仕事を探し始めるべき時だということだ
面接の時点では分からなかったが、前の会社のVP以上のポジションは、資格とは無関係にCEOとつながりのある人たちがほぼ独占していた
実力で昇進した人や、買収の過程で自然に上がった人も何人かいたが、時間がたつにつれてCレベル役員の友人、さらには家族に席を譲るよう、着実に交代させられたり降格させられたりした
一緒に働きやすかったあるCレベル役員はVPに降格され、CEOの長年の友人がそのCレベルの席を手に入れた
降格されたその役員は業界トップ企業で何年も経験を積み、この役職のために家族を連れて全米を横断する引っ越しまでしたのに、後任者にはその業界の経験がまったくなかった
そのVPは、CEOの長年の友人が仕事を覚えて引き継げるよう残ってほしいと頼まれ、ストックオプションを維持することを「許可」された
一部の会社で縁故主義と忠誠心がどう機能するのか、目が開かされた
この引用が特に目に留まった
フロントエンド出身のエンジニアリングVPが比較的珍しい理由は、スタートアップで最も差し迫った技術的課題がたいていスケーラビリティ、信頼性、バックエンドアーキテクチャにあるからだ、というくだり
以前、リーダーが皆バックエンド・インフラ側出身で、フロントエンドが低く評価される会社で働いていたが、そうしたバックエンド開発者たちのコード品質がかなりひどいケースを見たことがある
リーダーシップの代表性とエンジニアリングの才能の間に逆相関があるのか気になる
私はフロントエンドエンジニアからテックリードになった人間だが、開発者は個人の志向や重視する価値に応じて焦点を選ぶのだと思う
フロントエンドを選ぶ人とバックエンド開発者は、たいてい志向が異なる
ひどいコードとは何か
書式に一貫性がない、あるいは見た目が整っていないのか、変数名が説明的でないのか、コードが見やすく分割・構造化されていないのか
フロントエンド開発者は表面的な価値でコードを判断する傾向があるように感じる
特にエンジニアリング中心の組織では、問題を解決することで評価される
多くのチームは中核となるフロントエンド担当者がいなくても十分回るが、強いインフラやバックエンドエンジニアが1人、さらには複数人いなければ揺らぐことが多い
それが現実だ
フロントエンド開発はしばしば女性的にコード化され、重要度が低いものと見なされる
例: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
技術業界では、リーダーシップを男性的にコード化された特性と結び付ける傾向もある
だから、リーダーシップとフロントエンドの経歴がどこか噛み合わないものと見なされるのは、まったく不思議ではない
同じジェンダー力学はコードにも関係している
私にとって良いコードの一部とは、他人にとって良く、協業に向いたコードであることだ
だが、マッチョでアルファナードなテックブロのように振る舞うなら、1人でカウボーイコーディングをしながら天才性を誇示できる
そのときの目標は、チームと密に協業して一緒に作ることではなく、経営陣の目に強く留まる驚異的な個人貢献者になることだ
エンジニアリングVP は、会社間で標準化して比較できる役職ではない
現在の会社では、ディレクターが最大500人規模の組織を担当することが多く、VPは通常1000人以上、ときには3000〜5000人を担当する
50人規模の組織のスタートアップVPと、1000人以上の組織のFAANG VPを同じだと見るのは無理がある
どちらが優れているという話ではなく、必要なスキルが明確に異なる
実際、小さな会社でVPのタイトルを得た人たちがこの違いを理解せず、FAANGに応募してマネージャーやシニアマネージャー職を提示され、衝撃を受ける様子を見たことがある
まったく理にかなっていなかった
私の経験では、そのVPは大きな組織の基準で言えばインターン並みの経験しかなかったが、早く入社した人だった
ディレクターはさらにひどく、直属の2人は有能だった
Honeycomb の社員たちには、ブログ記事を書く代わりに、製品を目に見えて改善することに少し時間を使ってほしい
会社で Honeycomb を使うという不運を経験したが、いくつかのサービス以上と相互作用するシステムでは、まったく使い物にならなかった
なぜこの会社にこれほど 過剰な期待 が集まるのか理解できない
Honeycomb のVPは大手テック企業の シニアマネージャー に近い、という事実を念頭にこの記事を読んでいる
大企業の基準ではディレクターに相当する
私の経験では、個人貢献者は製品を作り、マネージャーは人を作り、ディレクターはプロセスを作り、VPは ポリシー を作る
その上の全員は予算要求の承認段階だ
ポリシーと戦略は同じではないと考えるなら、なおさらだ
もし誰も戦略を作らない、という微妙なジョークなのだとしたら、いいジョークだ