- 4年間Googleのソフトウェア開発者として働いた後、2月1日に退職した背景には、昇進評価の仕組みと繰り返されるプロジェクト中止によって、キャリアを自分でコントロールしている感覚が弱まった経験があった
- 昇進は直属マネージャーではなく、候補者を知らない上位エンジニア・マネージャーの委員会がpromo packetを審査して決める方式だった
- レガシーパイプラインの改善、バグ修正、テスト、文書化、チーム支援は実際に有用だったが、測定可能な影響として残しにくく、最初の昇進審査で不利に働いた
- その後、昇進に役立つ仕事だけを選ぶようにして最高評価のSuperbを得たが、プロジェクト中止とチーム再配置が繰り返され、昇進には再び失敗した
- Indie Hackersを通じて、小規模で収益を生むソフトウェア事業という選択肢を見つけ、KetoHub、Siaベースの事業、文章執筆の収益化をそれぞれ数か月ずつ試すことにした
Googleでの最初の2年と昇進への期待
- 入社後最初の2年は、長く会社に残るだろうと思えるほど満足度が高かった
- 周囲には優秀なエンジニアたちがいて、高度な開発ツールや無料の食事も提供されていた
- 直近の評価はStrongly Exceeds Expectationsで、マネージャーからは次の段階であるSenior Software Engineerへの昇進が近いと言われていた
- マネージャーはすでにシニアレベルの業務遂行能力があると見ていたが、昇進委員会にそれを証明できる適切なプロジェクトが必要だとしていた
Googleの昇進プロセスの仕組み
- Googleでは直属マネージャーが部下を直接昇進させることはできず、投票権もない
- 昇進の可否は、その日初めて候補者を見る上位レベルのソフトウェアエンジニアとマネージャーで構成される小規模な委員会が決める
- 申請者はpromo packetを作成して提出する
- チームメンバーからの推薦状
- 自分が書いた設計文書
- 自分の仕事が昇進に値する理由を説明する短い文章
- 委員会は複数候補のパケットをまとめて審査し、1日で昇進の可否を決める
- 当初はこの方式が、偏見や社内政治を減らし、コード品質やエンジニアリング判断を公正に評価するものだと考えていた
レガシーパイプライン改善が評価に残らなかった理由
- 主な担当業務は古いレガシーデータパイプラインだった
- 長年メンテナンスモードだったが、負荷の増加により圧迫されていた
- ひっそり停止したり、誤った出力を返したりすることが多かった
- 初期の設計文書以降は文書化がなく、障害診断に数日かかっていた
- パイプラインを正常化するために、さまざまな改善を行った
- 数十件のバグを修正した
- バグ再発を防ぐための自動テストを書いた
- デッドコードや、より新しいライブラリで置き換え可能なコードを数千行削除した
- 学んだことを文書化し、知識が個人の頭の中にだけ残らないようにした
- 昇進審査では、こうした作業が定量化しにくい問題として跳ね返ってきた
- バグを発見したことで、全体のバグ数はむしろ増えたように見えた
- 異常を黙ってやり過ごさず、すぐ失敗するように変更したことで、障害件数の数値も増えた
- 開発者が障害を修復する時間は大きく減ったが、それを追跡する指標はなかった
- チームメンバーのリリースリスクを下げるために、自分のプロジェクトを数週間から数か月延期したこともあった
- チームにとっては正しい判断だったが、promo packetでは印象的に見えなかった
- 委員会には、チームメンバーのプロジェクトのほうが大きな調整を要する重要な仕事に見え、自分の仕事は容易に中断可能なものに見えた
- 最初の昇進審査の結果は、技術的複雑さに対処できる証拠と、Googleに与えた影響が不足しているという判断だった
却下後に変わった働き方
- 最初の却下の後は、同じ良い仕事をしつつ記録をもっときちんと残せばよいと考えた
- チームが誤報のようなメールアラートを大量に受け取っている状況でも、すぐに修正せず、まずアラート頻度の指標を作って過去の記録を残そうとした
- 昇進時にアラートが減ったことを示すグラフを見せられるからだった
- その後に割り当てられたプロジェクトは、昇進に有利そうに見えた
- Googleで重要分野だった機械学習に大きく依存していた
- 数百人の作業者が手作業で行っていた仕事を自動化するものだった
- ジュニア開発者を率いる必要があり、これは一般に昇進審査で評価される要素だった
年末ギフトの一件と「ビジネス関係」という認識
- Googleは長年続いていた豪華な年末ギフトの慣習をやめ、その予算で低所得層の学生向けにChromebookを購入し、見出しになった
- これに関する社員の会話の中で、ある社員はGoogleと社員の関係はビジネス関係だと述べた
- その会話をきっかけに、Googleと自分が一つの共同体というより、金銭を受け取ってサービスを提供する関係なのだと自覚した
- 昇進委員会がバグ修正やチーム支援業務を報いないのであれば、そうした仕事に時間を使う理由も改めて考えるようになった
昇進最適化と品質基準の変化
- 最初の昇進却下から得た教訓は、後になって誤っていたように思えた
- 同じ仕事をよりうまく見せるのではなく、昇進委員会が望む仕事を選択的に行う方向へ変わった
- 新しい戦略は、すべての仕事を始める前に昇進の助けになるかを問い、ならないならやらないというものだった
- コード品質の基準も下がった
- 「今後5年間メンテナンス可能か」から「昇進するまで持ちこたえるか」へと変わった
- プロジェクトのリリースを脅かさないバグは登録も修正もしなかった
- 保守責任から外れた
- キャンパス採用イベントのボランティア参加をやめた
- 週1〜2回行っていた面接を0回に減らした
繰り返されるプロジェクト中止とキャリアの主導権喪失
- 優先順位の変更により、昇進に有利そうだったプロジェクトはインドの姉妹チームに移された
- 代わりに受け取ったプロジェクトは文書化されておらず、サポート終了したインフラの上にあったが、本番環境の重要な構成要素だった
- 新しい業務は、そのシステムを姉妹チームのコードから分離し、新しいフレームワークへ移行しながら、本番運用と性能指標を維持することだった
- 昇進という観点では数か月の後退だった
- 中止されたプロジェクトはリリースされず、2か月間の作業が無意味になった
- 新しいシステムを理解するのに数週間必要だった
- 運用維持という反復作業に追加の時間がかかる可能性があった
- 6か月の間に3度目のプロジェクト途中再配置を経験し、そのたびに理由は仕事の質ではなく、上位の経営戦略やチームの人員変動だった
- Googleはプロジェクト完了前には仕事を判断できないと言いながら、同時にプロジェクトを途中で打ち切って新しい仕事を割り当て、完了を難しくしていた
- キャリアが、自分を1時間ほど審査する匿名の委員会と、自分が関与できない経営判断に左右される構造になっていた
最後の昇進挑戦と退職の決断
- Googleで3年間昇進に投資してきたため、退職前に最後にもう一度だけ昇進申請をすることにした
- 評価期間終了の6週間前にプロジェクトが再び中止され、今回はチーム全体が解散となった
- Googleではこうしたことが十分よくあるため、defragという婉曲表現があった
- チームのプロジェクトはインドの姉妹チームへ移された
- チームメンバーは社内の別領域で再出発しなければならなかった
- それでも昇進申請を行い、結果として最高評価のSuperbを得た
- この評価は各サイクルでおよそ5%の社員に与えられる
- 昇進委員会は、直近6か月間でシニアレベルの仕事を明確に示したと判断した
- その6か月は、昇進最適化のやり方で働いていた期間だった
- しかし6か月では十分に長い実績記録ではないという理由で、昇進は認められなかった
- マネージャーは、同じレベルの仕事をさらに6か月続ければ昇進の可能性が高いと言ったが、すでに2年間「あと6か月で昇進の可能性がある」と聞かされ続けていたため、去ることにした
Indie Hackersと独立開発の計画
- ほぼ同じ時期にIndie Hackersを知った
- Indie Hackersは、小さなソフトウェアビジネスの創業者たちによるオンラインコミュニティだった
- 巨大スタートアップを目指す人たちよりも、生活費を賄える小さく収益性のある事業を作ろうとする人たちが中心だった
- 以前は、ソフトウェア起業家になるにはシリコンバレー型スタートアップの道をたどるしかないと思っていた
- そのほとんどの時間を資金調達に費やし、次の100万ユーザーをどう獲得するかを心配するやり方だと理解していた
- Indie Hackersのやり方は別の選択肢だった
- 多くのメンバーは、自分の貯金や本業のかたわらのサイドプロジェクトで事業を始めていた
- 投資家に答える必要がなかった
- 匿名の委員会に自分を証明する必要もなかった
- 欠点も明らかだった
- 収入はより不安定だった
- 致命的なリスクはより多かった
- Googleで1,000万ドルの損失を出す失敗をしたなら、ポストモーテムを書いて学習機会として受け止められるかもしれないが、小規模創業者にとっては事業終了と大きな負債につながりうる
- それでもIndie Hackersの起業家たちは、自分の事業が急成長しようと数年間停滞しようと、自分で意思決定できるという点で魅力的だった
- 退職後は、数か月ずつ複数のプロジェクトを試して反応を見る計画だった
- KetoHubの開発を続け、収益化の可能性を確かめる
- 分散ストレージ技術であるSiaの上に事業を作る
- 文章執筆により多くの時間を使い、収益化の方法を探る
- Googleは良い職場であり価値ある技術を学んだ場所だったが、今後もGoogleのような雇用主は存在する一方で、自分の会社を始める自由は常にあるとは限らないと判断した
1件のコメント
Hacker News の意見
同じ著者が複数のソフトウェア事業を立ち上げようとした過程をまとめた年次レビューシリーズも興味深く公開しており、財務状況もかなり率直に扱っている
ソフトウェア事業をブートストラップで育てることに関心があるなら、読む価値は大きい:
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
成功談はよく耳にするし、成功したときは大きな声で語りやすいが、現実にはほとんどの会社は失敗することを覚えておく必要がある。この著者は3年目に収益になるものを見つけたが、大半の人には収入なしでそれだけ耐えられる余裕はない
ここまで共感でき、率直な文章を書く人は珍しい。数年来追いかけていて、すばらしいインスピレーションの源だ
どんなキャリアであれ最も重要な教訓は、「顧客は顧客ではない」ということだ。実際の顧客は昇給、ボーナス、昇進を左右する人たちである
顧客とは、自分が価値があると考える商品やサービスにお金を払う主体であり、通常はマネージャーか、元記事の例のような昇進委員会だ。その観点では、キャリアを一つの事業のように運営し、お金を価値と交換できる主体により素早く価値を届ける方向へ動くのが正しい。顧客が考えを変えたり、市場が基準を変えたり、自分が見当違いのところに集中していたと気づいたりすることは、事業でもよくある。顧客が望むものを提供できなければ、顧客は簡単に別の人へ行けるので、戦略を絶えず変え、顧客に合わせる必要がある
結局、本当の顧客は人間ですらなく、プロセスになる。人々の役に立つ優れたアイデアを情熱的に追求することが、キャリアと社会の双方にとって最もよい地点だ。原文にある「私の運命が、私に一度も会ったことのない謎めいた委員会の手に委ねられているのは当然だ。彼らはえこひいきや社内政治に染まっていないはずで、私の高品質なコードと鋭いエンジニアリング判断を見抜いてくれるだろう」という箇所が、それをよく示している
こうしたパターンは製品品質の低下とチーム力学の悪化につながる。この避けがたい流れを明示的に抑制している会社、あるいはまだそうした流れが生じていない会社を探すほうがよい。よい品質を作り、それが認められるとき、誰もがよりよい気分になれる
依頼を受けて何かを作る場合、購入者が望むものと実際に必要なものが違うことがあり、最後まで行っても満足されないことがある。上司のために働くと、上司が妨げになることもある。顧客の望む通りにするだけでは不十分で、上司が「私のやり方で」やれと言うことがあり、そのせいで顧客が望むものを受け取れなくなる場合もある。顧客が別の人のために物を買う場合にも、間接性のために失敗し得る。企業向けカスタムソフトウェアでよく起きることだ
この記事に完全に同意するのは難しい。プロジェクトが完了前に潰れるのは非常に腹立たしいことだが、筆者はそこに昇進だけのためにいたようにも見える
昇進は良いことだが、なぜそれが辞めるほど決定的だったのかは十分に説明されていない。会社に残る唯一の理由が、より良い肩書きへの期待だけなら、それは悪い兆候かもしれない。その後、Googleで4年働いて一生暮らせるだけのお金を稼ぎ、その経済的安定を元手に、ほとんどの人には耐えられない高リスクな選択をした。いずれにせよ、自分に合う仕事を見つけられたなら何よりだし、その安定を土台に、有用で影響力のあるものを作れることを願う
これらすべての要素は、以前は非常に公然と示されていて、プレゼン、スライド、文書などが山ほどあった。自分がどのレベルなのか、話している相手がどのレベルなのかが重要だった。目標は優れたエンジニアになることでも、優れた製品を作ることでもなく、名前のない委員会にその魔法の数字を上げさせるための仕事だけをすることだった。Googleにそういう理由で入社したのでなくても、最終的には何が求められているのかを学ぶことになる。残念ながら、ソフトウェアエンジニアの一世代がこの教訓を学んでしまった
影響力を作れ、疑わしい指標を改善しろというプレッシャーは終わりがなく、その間に技術的負債は積み上がる。組織再編やレイオフへの不確実性も常にあり、次の評価サイクルに関する不安も大きい。数年経ってみると、お金が主な動機のように思える。ただ、これ以上のストレスは望んでいないので昇進は望まず、他の場所でこれ以上稼ぐのは非常に難しいだろうから、この会社にできるだけ長く残りたい
人間の心理はそうは働かない。周囲の人たちと競争するようになり、その人たちが昇進していく一方で自分だけが取り残されると、幸せでいるのは難しい
スタッフ未満のレベルに長く留まることはマイナスに働きかねず、昇進できなければ、明示された期待を満たしていないという理由で業績改善計画に入れられることもあり得た。Googleは最終的にその文言を削除した。10万人規模の会社ではピラミッドに十分な席がなく、自己宣伝はしないがシステムを回し続けている人たちを失うことになると学んだからだ。記憶が正しければ、2018年にはまだそれを分かっていなかった
著者です。この記事がまた上がってきてうれしい
この記事について気になることがあれば答えられる
流れを見て、その中でいちばん良さそうな流れを選んだように聞こえるが、別の選択肢があることもよくある。ダムを築くこと、つまり地形を変えることだ。誰もやろうとしなかった、あるいはできなかったやり方で事業を変えてみることだ。振り返ると、上司が面白く影響力のある仕事を与えてくれるのを待っていた時より、自分が何をするのかを上司に伝えられた時のほうが、最も幸せで成功していた。そういう選択肢が見えないなら辞め時かもしれないが、まず試してみる価値はしばしばあった。時には泥臭い仕事を押し通して、自分の運命を作る権利を得なければならなかったが、管理体制と信頼が生まれると、その資本を使って大きく新しく面白いことを提案できた。大胆さが報われるのを見るたびに驚かされる。先週も同僚が野心的で議論を呼ぶ提案で、資金という石から血を絞り出し、今週には新チームの技術リーダーになった。行き詰まりを感じるたびに空の文書を開き、新しい設計を打ち込み始める。その時は昇進のことは考えていないが、結局どこかで昇進やより大きな機会につながった
新しいプロジェクトをやっているのか気になる。PDFパーサのファジングに関する記事は読んだが、それが新プロジェクトに関係しているのか、文脈を見落としたのか分からない
https://mtlynch.io/i-sold-tinypilot/
公開の場で文章を書き、道のりを記録してくれてありがとう。助けられたのは私だけではないはずだ。ちなみにユーザー名を見るたびに、いつもMount Lynchのように読んでしまう
この記事から得た結論は、昇進委員会に依存する構造がいかに冷淡かということだ
Googleがエンジニアリング中心の文化を作りたくて、そうした制度を置いたのは理解できる。マネージャーが認めなくても、優れたエンジニアリング作業をすれば認められるようにする意図だったのだろう。だが、定量化しにくい文化改善のような仕事ほど、こうした委員会が優れたエンジニアリングを正しく見抜けるようには聞こえない。自分がもたらす価値を理解し、その評価を昇進の決定として示してくれる相手、顧客やリーダーに出会うと、人生は良くなる。書類に依存する顔のない委員会は、構造的に本当の承認が生まれる関係を作れない。リーダーシップが自分を認めない会社に、なぜ無理に残るのか。認めてくれる場所を探せばいい。Googleが悪い管理やプロセスのせいで優秀な人材を失うことを避けられないと学べないなら、それは彼らの損失だ。そこそこ良い人事評価を活用し、ゆっくり退職計画を立てればいい。誠実で支援的な専門的関係の形成を積極的に妨げる組織で働くには、人生は短すぎる
多くの人にとって昇進は、パイ食い競争に勝ったら賞品がさらに多くのパイだった、というのに似ている。自分の利害と雇用主の利害がゆるくしか一致していないことを認め、会社が望むやり方のゲームを拒んでも構わない
昇進はもういいので、内発的動機を与えてくれる仕事、つまり意味があり、刺激的で、没頭できる仕事をしたいし、生計を維持しつつ合理的に貯蓄できる程度だけ稼ぎたい、ということ
問題は3つある。多くの会社は報酬がひどく、少し貯蓄しようと思うと昇進が必要になること、意味のある仕事そのものもユニコーンのように希少であること、そして最も腹立たしいのは、自分の役割で安定して一貫して良い成果を出している労働者であっても、米国企業では必然的に「成長」し「キャリアを開発」するよう圧力を受けるか、「取り残された人」と呼ばれる点だ。特定のレベルで一貫して優れた成果を出すことは停滞ではなく、意図的な安定であり得る。個人の文脈における無限の成長、あるいは少なくとも無限に揺さぶり続けることは、米国企業の理解しがたい狂気だ
著者の「キャリアをさらに発展させるには、より大きな範囲のプロジェクトと、より多くのパートナーチームとの協業が必要だった。しかしそれは、プロジェクトが自分の制御外にあるより多くの要因によって失敗し得ること、そして自分の人生の数カ月や数年が無駄になり得ることを意味していた」という一文が印象的
振り返って省察すれば、スタートアップの成功も制御外の100を超える要因に左右されることを認めるようになると思う。人生の時間の無駄ではない。世界がどう動いているかを学んだということだ
高成長のベンチャー投資型スタートアップなら、成功するにはいくつもの星がそろう必要があるかもしれない。だがブートストラップ事業では、基本的に成功に必要なものは1つだけだ。プロダクトマーケットフィットである。人々が欲しがる製品を作れば、他に多くのミスをしても、おおむね成功する可能性は高い。TinyPilotを始めた時は、ハードウェアも物理製品の販売もまったく知らず、数え切れないほどのミスをした。それでも、人々が喜んでお金を払う製品を見つけ、顧客の前に持っていく良い方法を見つけたので、会社は回った。うまくやったこともあったが、初年度はおおむね売上が勝手に伸び、自分はそれに追いつこうとしている感じだった。プロダクトマーケットフィットを見つけるには、依然として運が必要だ。もっともらしく見えるアイデアでも多くは失敗するからだ。それでも、複数のことが同時に幸運にかみ合うのを待つのではなく、一度だけ運が良ければいい
また悪名高い2018年式の「私がGoogleを辞めた理由」記事か
そしてそういう記事はいつも、Googleのエンジニアは世界で最も賢いと言うところから始まる。本当に洗脳された人たちだ
私もそれでGoogleを去ろうか考えている。会議に座っていて、必要な仕事を他人に押し付けようとし、ゲームをすることにはほとんど関心がないのに、自分のプロジェクトには自分が片付けなければならない小さな作業が何百もある
転職すれば年5万〜10万ドル多く稼げる。次の会社は自分の経験を実際に価値あるものと見てくれるだろうし、その経験は技術的にはGoogleにとってはるかに有用であるにもかかわらずだ
今は10万人規模の何でもやる会社ではなく、焦点の定まったプロジェクトを手がける小さな会社で、より速く効果的に働きながら、より多く稼いでいる
「マネージャーが昇進させてくれないのですか？」「いいえ。Googleのマネージャーは直属の部下を昇進させることはできません。投票権すらありません。代わりに昇進の決定は、その日初めてあなたを知った上位レベルのソフトウェアエンジニアとマネージャーからなる小規模な委員会が下します」という構造だった
私の知る限り、2022年以降はマネージャーが唯一の票を持つ方式に変わったようだ
昇進は今でも昇進委員会に上がる。ただし今は、候補者のことを聞いたことがある程度には組織に近い場所に委員会を置き、マネージャーではない、文脈をよく把握したレビュアーを会議に置こうとしている。以前のシステムから続いている点であり、こうした記事がしばしば見落とす点は、各レベルごとに、そのレベルの人が独立して遂行できると信頼される活動について明示的な期待値があるということだ。昇進の決定は、現在の仕事をうまくやったことへの報酬ではなく、次のレベルの仕事ができることを十分に示したかどうかについての決定だ。ある人が1つのレベルに長くとどまるなら、通常は次のレベルのシグナルを示せていないからだ。もちろん、次のレベルのシグナルを示す機会が不足しているチームだったり、あるプロジェクトでは影響評価に何年もかかるのに、運用上の影響が評価されるまでは仕事が認められない、といった形で不公平に感じられることはある。それでも、聞こえるほど気まぐれではない場合が多い
毎年変わるので、自分の個人的経験で2024年のGoogleを判断するつもりはないが、私がいたある年には、マネージャーは私の席がどこにあるのかもほとんど知らなかった。私のL5とL6の昇進パケットは同僚委員会が評価し、彼らがマネージャー評価を見たのかどうかも分からない。私がL5昇進委員会に座っていた時も、マネージャー評価を大きく重視しなかった。当時はマネージャーたちが、L5昇進の理由となる領域からかなり手を引いていたので、それは理にかなっていた
だがそれは謎ではなく、結局、候補者がなぜ昇進すべきなのかが明確に表れる強いパケットを作る責任はマネージャーにある。昇進に挑むこと自体がマネージャーの票であり、その後は候補者の昇進をどれだけ強く後押しするかにかかっている。昇進間の一貫性を保証する唯一の方法だと思う