エンジニアが信頼する昇進・評価面談の進め方

以前関わったチームのシニアエンジニアが、「期待超過」の評価を受けた翌週に退職しました。評価の内容が原因ではありませんでした。2日後に昇進資料がキャリブレーションで却下され、それが五分五分の結果になり得ると誰も(EMも、skip-levelも)警告していなかったのが理由でした。彼は18ヶ月にわたって「完璧にこなしている」と言われ続けていました。退職後に知人へ語った話は単純なものでした。「マネージャーは知らなかったか、知っていて言わなかったかのどちらかだ。どちらにしても最悪だ」と。

半期サイクルは、6ヶ月分の言葉にされなかったシグナルを45分の会話に圧縮します。記録しなかったことは起きていないも同然です。5月に言及しなかったことは、キャリブレーション準備中に思い出したからといって10月に持ち出せません。このPlaybookは、すべてのエンジニアが評価後に自分の結果を紙の上にある成果物から自分自身で予測できるよう、エンジニアリングマネージャーを支援するためのものです。

昇進基準は意見ではなく証拠リストとして

エンジニアの信頼を失う最も確実な方法は、昇進の判断を形容詞で正当化することです。「強力な技術的リーダーシップ」「優れた部門横断的なインパクト」「卓越した当事者意識」。こうした言葉のどれひとつも、却下された昇進資料を手にしたエンジニアには何も意味を持ちません。彼らが求めているのは成果物です。

昇進は、shipした仕事に紐づいた4列のルーブリックで運用してください。

ルーブリックに含まれていないものに注目してください。雰囲気、勤続年数による年功序列、「部屋にいるとStaffエンジニアのように感じた」といった表現です。それらはキャリブレーションの議論で負ける要因です。上記の列が勝つための手段です。

資料を書く段になると、問いは「PriyaはStaffの準備ができているか?」から「Priyaは組織全体に採用された設計ドキュメントを3件持ち、2つのサービスをエンドツーエンドで担当し、四半期に5人以上のエンジニアのブロックを解消した実績があるか?」に変わります。設計ドキュメントが2件なら、まだ申請の準備ができていません。4件あってP0のインシデント対応も担っていれば、根拠があります。

具体的な事例と名前で基準を示してください。「Staffでは、MarcoのPayments Rewrite RFCやLinのRetry Budget Frameworkのような仕事を期待します」。Wikiの汎用的なレベル説明は証拠ではありません。実際に承認された昇進資料こそが証拠です。

この記事の関連資料はスタッフソフトウェアエンジニアの職務記述書です。昇進ルーブリックの担当範囲・インパクト・レバレッジの言葉は、そのJDとそのまま一致している必要があります。ルーブリックが「アーキテクチャの意思決定を主導する」と書き、JDが「複数サービスのシステム設計を担当する」と書いているなら、エンジニアたちは2つの異なる基準でキャリブレーションしていることになります。

6ヶ月間の可視性計画

ほとんどの昇進資料が失敗する理由は、エンジニアが成長していないからではありません。成長が誰にも知られていないからです。素晴らしい仕事をチーム外の誰も名前を知らない社内チケット3件でshipしたStaff候補者は、キャリブレーションで資料が否決されるStaff候補者です。可視性は成果物のひとつです。

半期サイクルの1ヶ月目に、今後12ヶ月以内に昇進候補となる各エンジニアと一緒に座り、6ヶ月間の可視性計画を共同で作成してください。4つの成果物、署名と日付入りで。

1. ひとつのストレッチプロジェクト。名前のある役員スポンサーと、shipできる表面積を持つもの(以下の落とし穴について詳述)。
2. ひとつの部門横断的な成果物。別のチームが利用したRFC、別のEMが名前を挙げられる連携、2つ先の組織の技術的負債チケットをクローズした移行作業。
3. ひとつのメンタリング成果。昇進したジュニア、90日ではなく30日で立ち上がった新入社員、彼らが主導した採用ループ。
4. ひとつの設計ドキュメント。レビューを通過し、6ヶ月以内に直接のチーム外の誰かに引用されるもの。

この文書を共有フォルダに入れてください。2人で署名します。これで次のサイクルで何が評価されるかについて曖昧さがなくなり、エンジニアは評価当日ではなく3ヶ月目と5ヶ月目に自分で進捗を確認できます。

4つすべてをshipすれば、資料は自然に書けます。4つ中2つのshipに留まれば、4ヶ月目(評価当日ではなく)に資料の準備ができていないことが分かり、軌道修正するか6ヶ月の延期を受け入れる機会があります。裏切りとは感じません。

難しい評価面談：SBI + 要求 + コミット

ほとんどのEMはサンドイッチ手法を使います。褒め言葉で始め、真ん中に批判を入れ、励ましで終わります。エンジニアは真ん中を聞きません。「うまくやっている、少し細かいことがあるが、うまくやっている」と聞こえます。そして10月に不意打ちを食らい、友人に話します。

サンドイッチをやめてください。SBI + 要求 + コミットを使ってください。4つのステップ、無駄なし。

状況 (Situation)。 具体的な時間、場所、文脈。「3月12日のauth-serviceの再設計レビューで」

行動 (Behavior)。 当人が行ったこと、観察可能な形で。あなたが推測した心理状態ではなく。「あなたはレビュアー4人中2人の質問に答えることを断り、『後で考えよう』と言いました。」

影響 (Impact)。 チームや仕事にかかったコスト。「レビュアーがその後私に報告を上げてきました。脅威モデルのやり直しでリリースが1週間遅れました。」

要求 (Ask)。 次回に具体的に何を変えてほしいか。「レビュアーが設計ドキュメントでセキュリティ上の問題を指摘した場合、答えが『これは先送りにする、理由は○○』であっても、48時間以内にドキュメント内で回答することが必要です。」

コミット (Commit)。 日付とチェックポイント。「4月9日の1:1で振り返り、次の2つの設計レビューがどうだったか確認しましょう。」

そのまま使える2つのスクリプト例を示します。

コードレビューがチームをブロックしている場合。「sprint 23で、あなたのコードレビューのうち3件が4日以上かかりました。うち1件はCheckout Revampのリリースを1sprint丸ごとブロックしました。チームがあなたを避けてルーティングし始めており、コードベースの文脈を失い始めています。24時間以内にレビューを返すか、対応できる人に再割り当てすることが必要です。15日の1:1で確認しましょう。」

設計ドキュメントの厳密さが不足している場合。「直近の2つの設計ドキュメント(Queue MigrationとRate Limiter Rewrite)には障害モードのセクションとロールバック計画がありませんでした。アーキテクチャレビュー委員会が両方を2回目の審査に差し戻し、それぞれ2週間のロスになりました。Staffレベルでは、設計ドキュメントは少なくとも70%の確率で最初のレビューで通る必要があります。次に書くドキュメントには、ARCに提出する前に障害モードの表とロールバックのセクションを含めてください。22日の提出前に一緒にレビューします。」

何が抜けているか気づいてください。「他はとても良くやっています」という文言がありません。その言葉はあなた自身の気持ちを楽にするためのものであり、相手のためではありません。どうしても言いたければ、コミットの後、ミーティングの終わりに取っておいてください。

PIPのシグナル：いつ始めるか、いつ使わないか

業績改善計画(PIP)はツールであり、罰ではありません。EMAが犯す最大の失敗は開始が遅すぎることで、たいていの場合は6ヶ月間サンドイッチを続けていたからです。2番目の失敗はパフォーマンスの問題ではなく、適性の問題のときにPIPを始めることです。

次の3つすべてが当てはまるときにPIPを開始する：

1. その行動がエンジニアに書面で伝えられている(相手が読み返せる1:1ノートに)。
2. 少なくとも2サイクルまたは2ヶ月にわたって行動が繰り返されている。
3. 少なくとも2件の書面による1:1ノートで指摘し、SBI面談を少なくとも1回行ったにもかかわらず行動が変わっていない。

1:1ドキュメントからこの3点を示せなければ、PIPの根拠がありません。フィードバックのギャップがあるのであり、PIPはHRと同僚EMにキャリブレーションで異議を唱えられることになります。

パフォーマンスの問題ではなく適性の問題のときはPIPを使わない。

「適性の問題」とはこういうものです。エンジニアは技術的には問題なく、仕事もshipしているが、チームのドメインと合っていない(プロダクトチームに配属されたインフラ専門家、プラットフォームチームに配属されたプロダクト専門家)か、会社のステージと合っていない(10人規模の手探り状態が好きなのに800人規模で採用された)。エンジニアは失敗していません。ポジションが間違っているのです。

適性の問題にPIPを強制すると、激怒した退職を招きます。エンジニアは反論し、技術的には正しい主張をし、結局去り、不当に追い出されようとしたと周囲に話します。コスト：6ヶ月分のチームモラルとより広い市場でのあなたの評判。

代わりに、段階的な移行を提示してください。率直に、誠意を持って、日付を明確に。「あなたはプラットフォームチームのほうが活躍できると思います。Mariaに話したところ、空きポジションがあります。4週間かけての移行をサポートしたいと思います。外部を探したいのであれば、6週間の猶予と強力な推薦状を提供できます。」エンジニアはこれを尊重します。彼らの友人もこれを尊重します。あなたの採用パイプラインも恩恵を受けます。

PIPの判断フロー、簡略版：

明確なPIPは60日以内に解決します。実際の改善か、スムーズな退職かのいずれかで。4ヶ月目に入ってもまだ続いているなら、エンジニアのパフォーマンスではなく、あなた自身の不快感を管理しているのです。

同僚EMとの昇進キャリブレーション

キャリブレーションは昇進の意思決定が実際に行われるミーティングです。あなたが書いた資料は入場券です。4〜6人の同僚EMとDirectorと一緒に過ごす90分間で、支持者と反対者のダイナミクスが結果を決定します。

1ページの事前資料を持参してください。キャリブレーションの2日前に、候補者ごとに1ページを同僚EMに送ってください。

• 氏名、現在のレベル、目標レベル
• 上位3つの成果物(設計ドキュメント、RFC、インシデントretroへのリンク付き)
• 担当範囲・インパクト・レバレッジの証拠をそれぞれ短い箇条書き3点で
• 最も強い反論とそれへの回答を1段落で

最後の箇条書きが、エンジニアを昇進させて退室できるEMとそうでないEMを分ける要素です。事前資料で反論を先回りしておくことで、部屋での反発は書面上でもう対処済みのものになります。先回りしなければ、反論する同僚が最初にそれを枠組みする権限を持つことになります。

オーバーセールスなしに境界線上のケースを守ってください。境界線上とは、エンジニアが3つの評価軸のうち2つで基準に達し、3つ目に近づいている状態を指します。「完全にStaffです」とは言わないでください。「担当範囲とレバレッジでは基準に達しており、インパクトは近づいています。Q3までにギャップを埋める進行中の仕事がここにあります」という言い方をしてください。それがDirectorの精査に耐えられる言葉です。境界線上のケースをオーバーセールスすると、次の2サイクルにわたって信頼性が損なわれます。

同僚EMが自分のエンジニアを守るためにあなたのエンジニアをブロックしようとするとき(評価がスタックランク制か予算が制約されているときに特に起こります)、その場では争わないでください。負けますし、関係を壊します。代わりにオフラインで取り上げてください。「PriyaのRFC基準についてのご懸念をきちんと理解したいと思います。今週一緒に彼女の3つのRFCを確認できますか?」十中八九、キャリブレーションの場を離れると抵抗は消えます。

「ストレッチプロジェクト」の落とし穴

私が見てきた失敗した昇進資料の半分は、目に見える仕事をshipする見込みがなかったストレッチプロジェクトによって否決されました。パターンは常に同じです。EMは書面上では素晴らしく聞こえるストレッチプロジェクトをアサインします。エンジニアは4ヶ月間それに取り組みます。プロジェクトは優先度が下がり、担当範囲が削られるか、役員スポンサーがチームを異動します。エンジニアは外部から見える成果を何もshipしません。キャリブレーションの場で「Priyaはこの半期に何をしましたか?」と問われ、EMには指し示すものがない。

アサインする前にストレッチの担当範囲を事前検証してください。3つの確認事項、すべて必須。

1. 実際の予算。 「後で考えよう」ではなく、予算項目か人員数の割り当てがある。財務部門が名前を挙げられなければ、それは存在しない。
2. 名前のある役員スポンサー。 「この半期の私の最重要事項の3つのうちの一つだ」と書面または記録されたミーティングで発言した具体的なDirectorまたはVP。ローンチメールへのCC欄ではなく、明確な発言。
3. shipできる表面積。 そのアウトプットを使用し、成果を確認できるユーザー、顧客、または内部チーム。その成果を見るのがエンジニア自身のチームだけであれば、それは普通のプロジェクトであり、ストレッチではありません。

3つのうち1つでも欠けていれば、そのプロジェクトはキャリアの落とし穴です。エンジニアが喜んでいても異議を唱えてください。「このアイデアは好きです。ただし、ストレッチとしてアサインする前に、役員スポンサーが誰で、どのユーザーが使うのかを確認する必要があります。この2点がなければ、昇進資料に役立たない仕事に4ヶ月を費やすことになります。」優秀なエンジニアは5ヶ月目に感謝します。一流のエンジニアは1ヶ月目に感謝します。

成長ドキュメントの運用サイクル

1つのドキュメント。同じドキュメント。エンジニアがチームにいる間ずっと継続します。3か所に分散した3つの別々のドキュメントではなく。

3つのサイクルがそれに情報を提供します。

月次の箇条書きが過小評価されています。5分。エンジニアがshipした内容、ブロックされた内容、学んだ内容、EMへの要求を書きます。あなたは次の1:1前に読み、書面で返答します。6ヶ月後、キャリブレーション準備が始まると、6ヶ月分の箇条書きを大きな記憶の努力なしに正式な資料に圧縮できます。

大原則：エンジニアはいつでも自分の軌跡を読める。エンジニアが「自分は今どこにいますか?」と聞いたとき、答えは「ドキュメントを開いて最後の四半期レビューまでスクロールしてください。正確な状況が分かります」です。サプライズなし。「話す時間をスケジュールしましょう」なし。ドキュメントが答えです。

エンジニアがチームを移るときや、あなたが会社を去るときにもこれが機能します。次のEMは本物のドキュメントを引き継ぎます。Slackの直接メッセージ履歴ではなく。

避けるべきよくある失敗

• 本当のフィードバックを評価日まで取っておくこと。 エンジニアが10月に初めてそれを聞いているなら、5月にあなたが失敗していたのです。
• 証拠ではなく可能性で昇進させること。 可能性は採用時に賭けるもの、昇進時ではありません。昇進はshipした成果物で判断します。
• エンジニアの頭の中で「問題ない」と翻訳される曖昧な言葉。 「設計ドキュメントにもう少し磨きをかけてもらえると嬉しいです」はフィードバックではありません。無視されるヒントです。SBIを使ってください。
• 部屋に成果物なしでキャリブレーションに臨むこと。 設計ドキュメントへのリンクを示せないなら、根拠がありません。
• 残業時間とshipしたインパクトを混同すること。 週60時間働いて2機能をshipしたエンジニアが、週40時間で4機能をshipしたエンジニアより優れているとはなりません。

成功の測定

このPlaybookが機能していれば、次のことが実現します。

• 評価当日の評価に驚くエンジニアがゼロになる。あなたと同じ成長ドキュメントを読んでいるからです。
• 昇進資料が最初のキャリブレーションで70%の確率で承認される。可能性の低いケースを博打として提出することをやめたからです。
• PIPが60日以内に解決する(実際の改善かスムーズな移行)。6ヶ月目に引き延ばされてチームを毒することがなくなります。
• エンジニアが次のレベルの基準を暗記で言える。ルーブリックを書き留め、実際の成果物を使って説明したからです。

基準はシンプルです。却下された昇進資料を手にしたエンジニアが、基準を指し示し、自分の仕事を指し示し、そのギャップに納得できる状態。もしそれができなければ、失敗したのは彼らではなく、あなたです。

関連記事

• スタッフソフトウェアエンジニアの職務記述書
• 前進をもたらすエンジニアとの1:1の進め方
• 定着するシニアエンジニアの採用
• 本音を引き出すskip-level 1:1