エレナ（Elena）の3回目の昇進には、より大きな役職名（タイトル）、より高額なボーナス、そして毎週14個もの追加ミーティングがついてきた。
その6カ月後、彼女はより小さな役職名の職に就くために退職した。
私たちは、他社がもっと高い給与を提示したのだろうと思い込んでいた。
だが、違った。
他社が約束したのは、「もう一度コードを書かせてあげること」だったのだ。
エレナは、誰もが名指しで仕事を依頼してくるエンジニアだった。
彼女は20人が騒ぎ立てているインシデント対応の場に入ってくると、2つの質問を投げかけるだけで、他の全員が見落としていた前提条件を瞬時に特定することができた。チームの基準からすると彼女のコードを書くスピードは遅かったが、トラフィックの急増、急ごしらえの移行作業、そして5年間も本番環境に残り続けた「一時的な」ビジネス要件などにも耐え抜く堅牢さがあった。
ジュニアエンジニアたちが彼女を信頼していたのは、彼女が自分の知性を誇示するために相手のミスを利用することが決してなかったからだ。プロダクトマネージャーたちが彼女を信頼していたのは、彼女が「この納期は危険だ」と言うとき、その危険が具体的にどこに潜んでいるかを正確に説明できたからだ。他のシニアエンジニアたちが彼女を信頼していたのは、新たな証拠が示されれば素直に自分の考えを改める柔軟さを持っていたからだ。
彼女をシニアエンジニアからリードエンジニアへと昇進させるのは、当然すぎるほど妥当な判断に思えた。
新しい役割には、プロジェクトの調整、デリバリーの進捗報告、そして週2回の計画ミーティングが加わった。それでも彼女は依然としてシステムを設計していた。難しい部分のコードも自ら書いていた。問題に没頭し、チームが想像していた以上の成果を携えて戻ってくるだけの、まとまった中断のない時間もまだ十分に確保できていた。
彼女は追加の業務もうまくこなした。だから私たちは、さらに多くの業務を彼女に与えた。
それこそが、私たちが気づくことのできなかった負のパターンだったのだ。
彼女の2回目の昇進により、彼女は3つのチームに対して責任を持つことになった。
彼女は、エンジニア間の意見の相違を解決し、経営陣に向けて技術的リスクを翻訳し、アーキテクチャ提案をレビューし、採用面接を行い、採用計画を承認し、ロードマップが遅延した理由を説明する担当者となった。
彼女のカレンダーは30分刻みのブロックで埋め尽くされた。
当初、エレナは金曜の午前中をエンジニアリングの時間として死守していた。その枠は「設計と構築（Design and Build）」と名付けられていた。しかし、それが続いたのはわずか3週間だった。
やがてステアリングコミッティ（運営委員会）がその枠に入り込んできた。その後は採用のキャリブレーション会議が入った。さらに次は緊急のロードマップレビューが入った。最終的にその定期ブロックがカレンダーに残り続けたのは、それを削除してしまうと「何かを認めて敗北した」ような気になってしまうからに過ぎなかった。
彼女のプルリクエストは小さくなり、頻度も減っていった。私たちはそれを「適切な権限委譲の成功」と解釈した。
彼女のチームの成果物は増えた。私たちはそれを「リーダーシップによるレバレッジの効果」と解釈した。
彼女は仕事について熱っぽく語らなくなった。私たちはその変化をまったく測定していなかった。
エレナの価値は、他の誰よりも多くの会議に出席できることなどでは決してなかった。
それは「判断力（Judgment）」だった。
彼女は、クリーンに見える抽象化の背後にどのような運用リスクが隠れているかを見抜いていた。彼女は、ある要望が「もう1週間の検討」を必要としているのか、それとも単に「決断を下す勇気を持つ誰か」を必要としているだけなのかを知っていた。彼女は、設計の議論が「誰も触れたがらない別の問題」の身代わり（プロキシ）になってしまっている瞬間を直感的に察知できた。
そうした能力があったからこそ、彼女はより広範な責任を担う準備ができているように見えたのだ。
しかし、私たちは彼女がその能力を発揮できる領域を広げる代わりに、その領域を「調整業務」で置き換えてしまった。長年のエンジニアリングの実践によって培われた資質を、あろうことか「彼女がエンジニアリングに費やす時間を減らすべき根拠」として使ってしまったのだ。
私たちは彼女のキャリアを築き上げてあげていると思い込んでいた。
彼女自身は、自分がそこから徐々に排除されていると感じていたのだ。
新しい役職名は「エンジニアリング・ディレクター（Director of Engineering）」だった。
経営陣は即座に承認した。彼女の報酬は増額された。彼女の担当範囲は2倍になった。全社へのアナウンスでは、この昇進が彼女の「並外れた技術的貢献」に対する評価であると説明されていた。
しかし、彼女の新しい責務には、技術的な貢献などほぼ皆無だった。
彼女が担当することになったのは、人員計画、人事考課、予算申請、四半期コミットメント、ベンダー交渉、そしてもはや深く理解する時間すら失ってしまった業務に関する延々と続くステータス報告ミーティングの数々だった。
昇進から1カ月後、私は彼女に新しい役割の感触を尋ねた。
「忙しいですね」と彼女は答えた。
私はそれを「多忙で圧倒されている」と聞き違え、優先順位付けのサポートを申し出た。
彼女が意味していたのは、「空虚だ」ということだったのだ。
過重な労働によってもたらされる疲労もある。しかし、成功を収めた結果として、自分にエネルギーを与えてくれていた仕事そのものから切り離されてしまうことによってもたらされる、全く別の種類の疲労もあるのだ。
エレナが疲弊していたのは、1日が長かったからではない。
どの日も、自分のための日だと感じられなくなってしまったからだ。
これこそが、私たちが見落としてしまった理由だ。
エレナは新しい役割で失敗したわけではなかった。むしろ、見事にそれをこなしていた。
離職率は低下した。ロードマップに関するコミュニケーションは改善された。経営陣はより明確な回答を得られるようになった。彼女の傘下のチーム間での優先順位の対立は減少した。あらゆる指標が、この昇進は大成功だったと告げていた。
人事評価面談で、私たちは彼女が「より高い視座（Higher Altitude）」で物事を動かせるようになった能力を称賛した。個人のプレイヤーとしての実行を超えて、見事にステップアップしたと伝えた。そして翌年には、さらに別の組織を彼女に任せる可能性について話し合った。
彼女は私たちに感謝の言葉を述べた。
その2週間後、彼女は退職届を提出した。
最も危険な退職は、パフォーマンスの低下から始まるのではない。本人が決して望んでいなかった職務に対して、本人があまりにも優秀に適応し、成果を出せてしまったときに始まるのだ。
彼女の新しい役割は「スタッフ・ソフトウェア・エンジニア（Staff Software Engineer）」だった。
直属の部下（ダイレクトリポート）はゼロ。予算権限もなし。四半期ごとの人員計画スライドを作る必要もない。その役職名は彼女が去ろうとしているポジションよりも下位に位置し、提示された報酬もほぼ同額だった。
私たちは、そこにどんな隠された旨味があるのかを探そうとし続けた。
そして、一つだけ見つかった。
採用面接の過程で、彼女の未来の上司は、1週間のうち何パーセントの時間を「システム構築」「設計レビュー」「エンジニアへの直接の指導・メンタリング」に費やしたいかを尋ねていたのだ。そして、そのパーセンテージを職務定義書（ロール定義）の中で厳格に保護することを確約していた。
私たちは3回の昇進を通じて、エレナが「あとどれだけの重荷を背負えるか」ばかりを問い続けていた。
彼らは1回の面接の中で、彼女が「どんな仕事を自分の手元に残したいか」を問うていたのだ。
それこそが、はるかに魅力的なオファーだった。
私たちのキャリアラダー（評価等級制度）には、書面上は「マネジメント」と「個別貢献者（IC: Individual Contributor）」という2つのトラックが存在していた。
しかし現実には、ステータスは一方向にしか流れていなかった。
最も高い給与レンジ、経営陣への最も近いアクセス権、そして最も目に見える影響力を持っていたのは、ますます大きな組織を率いるマネジメント層だった。シニアの個別貢献者も存在してはいたが、エレナの可能性に関するあらゆる議論は、最終的には常に「彼女が何人の人間を率いることができるか」という話へとすり替えられていった。
私たちは、「規模（Scale）」と「距離（Distance）」を混同していたのだ。
彼女の影響力を拡大する唯一の方法は、彼女を現場の実装から遠ざけることだと思い込んでいた。しかし、エレナの影響力は、現実のコードや現場に十分に密着しているからこそ、机上の計画書が削ぎ落としてしまったリスクに気づけるという点から生まれていたのだ。
彼女はリーダーシップを拒絶したのではなかった。
彼女を慕って人々がついてきてくれた源泉である「職人技（Craft）」を捨てることを要求するような、そんな偏ったリーダーシップの定義を拒絶したのだ。
過去の昇進を取り消すことはできない。しかし、同じ過ちを繰り返すのをやめることはできる。
現在、私たちの昇進に関する対話は、かつてエレナに問いかけるべきだった一つの質問から始まる：
「役職名が変わった後も、あなたの現在の仕事のうち、どの部分が絶対に変わらず維持されるべきですか？」
私たちは、マネジメントと同等の報酬と影響力を持つシニアテクニカルロールを新設した。技術的な卓越性に対する既定の「ご褒美」としてピープルマネジメントへの移行を扱うのをやめた。最も優秀なエンジニアをチームから永久に引き抜いてしまうのではなく、技術リーダーが交代制（ローテーション）で経営陣の会議に参加する仕組みへと変更した。
また、私たちは昇進後にカレンダーをレビューするようになった。
職務記述書（Job Description）は、その役割がどうあるべきかを語る。だがカレンダーは、組織がその役割を実際にどう変えてしまったかを如実に物語る。
もしエンジニアが「技術的な判断力」を評価されて昇進したにもかかわらず、その6カ月後にその判断力を行使するためのまとまった時間がカレンダーに一切残っていないとしたら、会社はその判断力をスケールさせたのではない。
単に、会議の招待状の下にそれを埋もれさせて殺してしまっただけなのだ。
私たちはキャリアを「梯子（はしご）」として例えがちだ。梯子という言葉は、上へのあらゆる移動を進歩のように見せてしまうからだ。
しかし、より高いポジションが進歩と言えるのは、本人がその到達先を望んでいる場合に限られる。
エレナの役職名は3回大きくなった。彼女の報酬、管轄範囲、そして社内での知名度も同様に上がった。外から見れば、彼女のキャリアはまさに絵に描いたように順調に進んでいた。
だが彼女の椅子から見れば、昇進するたびに、彼女がエンジニアリングという道を選んだ理由の欠片がまた一つずつ剥ぎ取られていたのだ。
彼女が退職届を出したとき、私たちは企業が「相手を大切に評価している」と証明するために使うほぼすべてのものを、すでに彼女に与え尽くしていた。
ただ単に、彼女自身が価値を感じていた「その仕事そのもの」を与えることをやめてしまっていたのだ。
あなたの組織の最高のエンジニアが必要としているのは、より大きなチームでも、より立派な役職名でも、さらに重層化された責任のレイヤーでもないかもしれない。
彼らが本当に求めているのは、彼らが愛している仕事そのものを、「いつか卒業しなければならない通過点」として扱うのを経営陣が今すぐやめることなのだ。
シニアエンジニアリングとは、単により多くのコードを生み出すことではない。障害、ボトルネック、そして長年の技術的負債へと繋がる意思決定を見抜くことである。The Production Engineering Library は、バックエンドシステム、データベース、メッセージング、Kubernetes、パフォーマンス、インシデント対応全般において、そうした判断力を培うための実践的なコレクションである。
あなたはこれまで、自分が一番得意だった仕事から、昇進によって引き離されてしまった経験はないだろうか？