新任EMの最初の30/60/90日間

3週間前まであなたはシニアICでした。今日のカレンダーには14時間分のミーティングと26時間の「オープン時間」が並び、skip-levelからは「今週コーヒーでも飲みながら話しませんか」というSlack DMが届いています。あなたにはまだマージ権限があります。on-callエンジニアに通知が飛んだバグを修正するために開くファイルも分かっています。そして、それこそが罠です。

多くの新任EMがコードを書き続けるのは、コーチングよりも安全に感じられるからです。Jiraのチケットには完了の定義があります。しかし、密かに転職先を探しているスタッフエンジニアとの1:1にはそれがありません。だから新任EMは2週目に機能を作り上げ、生産的な気分になりながら、本来の仕事を6ヶ月間こなせずにいます。そしてskip-levelから「チームの開発速度が上がっていないのはなぜか、2人が辞めたのはなぜか」と問われることになります。

PRのマージ数で自分の週を計っているなら、肩書きを得ただけで、仕事は引き受けていないことになります。

30/60/90日間が重要な理由

チームがあなたへの印象を形成する期間は短いものです。45日目までに、あなたがまだICのふりをしているマネージャーなのか、それとも本当にマネージャーになろうとしているICなのか、チームは判断を下します。あなたがどのミーティングをキャンセルするか、誰の1:1を後回しにするか、参加したときに何を話すかを、彼らは観察しています。自分たちの判断をあなたに伝えることはしませんが、それに基づいて行動を変えていきます。

以下のプランは、後者の結果を生み出すために設計されています。各30日ブロックには3つから5つの具体的な成果物があり、いずれもIDEからは達成できないものばかりです。

1日目から30日目：傾聴、状況把握、出席

最初の月は情報収集です。何かを修正したいという衝動に駆られるかもしれませんが、我慢してください。以前の立場から壊れているように見えたものが、実際に壊れているのかどうか、まだ分かっていません。

最初の2週間で直属の部下との1:1を10回実施する

直属の部下が8人いれば、2週間で1日1回の1:1と、30分のフォローアップが数回必要になります。毎回同じ3つの質問をしてください。

1. 今の職場で一番良いことは何ですか?
2. 一番辛いことは何ですか?
3. もしあなたが私の立場だったら、最初の90日間で何を変えますか?

手書きでメモを取ってください。その場で問題解決をしようとしないこと。新任EMが初期の1:1で犯す最大の失敗は、不満を聞いた瞬間に解決を約束してしまうことです。そして3週間後に、間違ったことを直すか、約束を破るかのどちらかになります。「もう少し詳しく聞かせてください」「それについては考えさせてください」は、完結した返答として十分です。

2週間の終わりには30から50個の個別の観察が蓄積されます。パターンが浮かび上がるでしょう。3人が異なる言葉で同じ問題について触れているはずです。それがあなたの地図になります。

チームの開発速度とon-call輪番を調査する

直近8回分のsprintを引き出してください。確認すべき点は2つです。

• スループットの傾向。 sprint当たりのストーリーポイント完了数は横ばいか、上昇か、下降しているか? 下降しているなら、いつ始まったか? 組織再編、担当範囲の変更、誰かの休暇といったイベントと結びつけて考えてください。
• on-callの分担状況。 直近1四半期のページログを引き出し、エンジニアごとのインシデント数を数えてください。3人が全ページの70%を担っているなら、公平性の問題と燃え尽きのリスクがあります。誰も大きな声で不満を言っていないので、先週まであなたは気づいていませんでした。

調査結果を記録してください。まだ修正しないこと。この調査は、31日目から60日目に初めてのretroを開催するときに使う基準線となります。

部門横断的なミーティングに5回出席する

プロダクトプランニング、デザインレビュー、セールス向けの情報共有(そう、セールスです。なぜならあなたのチームがAEチームがdemoで使う機能を作っているからです)、サポートエスカレーションの同期、skip-levelが別組織のピアと行う週次ミーティングです。

あなたは話しに行くのではありません。外から見たチームの姿を学ぶために行くのです。standupであなたのチームを褒めるプロダクトマネージャーが、部門横断的なプランニングミーティングでは目を細めているかもしれません。サポートリードが、あなたが一度も聞いたことのない3件の顧客エスカレーションに言及するかもしれません。チームの評判は、以前は招待されていなかった場で形成されています。

それらのミーティングでチームに関するメモを取ってください。誰が言ったかを明かさずに、観察内容を1:1で直属の部下に伝えてください。

コードコミットは一切行わない

これは絶対的なルールです。重大なバグにどうしても対応が必要なら、エンジニアとペアを組み、mergeは彼らに任せてください。

最初の月にあなたがshipするcommitは、その旧職が引き続きあなたの手の届くところにあるというシグナルをチームに送ります。彼らはより速く進めるためにあなたを回避するようになります。コードに逃げる選択肢があると見えているので、厄介な人間的問題を持ち込まなくなります。あなたは生産的な気分になりながら、自分をごまかしているのです。

以前、あるシニアエンジニアに「厄介な移行作業で一緒にペアを組むが、commitはプッシュしない」と伝えたとき、彼は約10分間不満そうにしていましたが、その後の四半期を通じて明らかに安心した様子でいました。彼が求めていたのは、私がリポジトリでタイピングすることではなく、他のすべての事柄について考えることだったのです。

31日目から60日目：一つを動かし、一つを直し、一つ難しいことを言う

2ヶ月目は、インプットからアウトプットへと切り替わる時期です。30日間で実際にshipできる程度の小さな成果物が3つあります。

retroを1回実施する

ファシリテーターとして初めて行います。参加者としてではなく。開発速度の調査データを活用してください。フォーマットはそれほど重要ではありません(start-stop-continue、mad-sad-glad、チームが使い慣れているもの何でも)。重要なのは、一つの不快なパターンを表面化させ、その場で皆にじっくり向き合わせることです。

例えば「チケットをクローズしているのに、22%が2sprint以内に再オープンされています。これはどういうことでしょうか?」と言ってから黙る。最初の90秒は沈黙か、かわし合いになるでしょう。それをやり過ごしてください。自分の意見でその沈黙を埋めなければ、エンジニアは最終的に本音を言うものです。

マネージャーとして初めてretroを進行したとき、30分中18分を話してしまいました。それが教訓になりました。retroでのあなたの仕事は、質問し、要約し、1つか2つのフォローアップを割り当てることです。議論を主導することではありません。

壊れたプロセスを1つ修正する

1:1で直属の部下が不満を述べていた中で最も小さく、2週間以内に解決策を出せるもの。大掛かりな組織設計の刷新ではありません。何ヶ月も全員を悩ませていたにもかかわらず、誰もシニアでも組織力もなくて放置されていたものを。

実際に機能した事例を挙げます。

• 45分かかるstandupを15分に短縮。非同期優先のフォーマットに変更し、ブロッカーがある場合のみ10分のライブ同期を実施。
• 3日のPRレビューSLAがしばしば守られていない問題には、一ページの期待値ドキュメントを公開し、Slack通知ボットを追加し、エリアごとにバックアップレビュアーを指名。
• 書面によるrunbookのないon-callの引き継ぎには、各ローテーション終了時に20分の引き継ぎミーティングを設け、共有ドキュメントにメモを残すことを義務化。

一つ選ぶ。修正を実施する。チームに「あなたたちの声を聞いた」と伝える。重要なのはプロセスの改善そのもの(それも素晴らしいことですが)ではなく、あなたが本当に話を聞くかどうかをチームが見極めようとしていて、その答えが「はい」になったということです。

難しいフィードバックを1回届ける

これまで避けてきたものです。

コードレビューで優秀だが後輩を圧倒するシニアエンジニア。見積もりを3倍外し続けるミドルレベルの担当者。意欲を失い、チームが静かに回避策を講じているtech lead。

ミーティング前にスクリプトを作成してください。状況・行動・影響・要求の構成を使います。

• 状況：「昨日のデザインレビューで、Priyaがキューベースのアプローチを提案したとき...」
• 行動：「...あなたは彼女の発言を2回遮り、なぜ機能しないのか説明せずに『うまくいかない』と言いました。」
• 影響：「他の2人のエンジニアから、早期段階のアイデアをチームチャンネルに出さなくなったと聞きました。打ち消されることが分かっているからです。私たちに必要な意見が失われています。」
• 要求：「相手が話し終えるまで待ち、反論する前に一つ質問することが必要です。それはできますか?」

声に出してリハーサルしてください。1:1で伝えること。グループの場では絶対に行わない。その後の沈黙を受け入れてください。その会話は実施中は辛く感じますが、2回目は明らかに楽になります。これは自分がこの仕事をこなせるという証明になる会話です。

61日目から90日目：成果を担い、前を向いて計画する

3ヶ月目は「新任EM」から「EM」へと変わる時期です。3つの成果物、いずれもskip-levelの目に触れるものです。

チームのOKRを担う

「プラットフォームイニシアチブをサポートする」ではなく。四半期末に評価される具体的で測定可能な成果を担ってください。

悪い例：「開発者体験を改善する。」 良い例：「Q3末までにPRレビューの中央値を38時間から12時間に短縮する。既存のGitHubメトリクスダッシュボードで測定。」

書き出す。skip-levelの承認を得る。チームに「これは私が責任を持つものであり、あなたたちのものではない」と伝える。この区別が重要なのは、多くのマネージャーがOKRをチームに押し付けて、進捗が遅れると姿を消すところをチームが見てきているからです。

skip-levelへ90日間報告を行う

スライドは最大3枚。機能する構成は次の通りです。

• スライド1：引き継いだ状況。 開発速度の基準値、on-call分担状況、発見した上位3つのリスク、上位3つの強み。それぞれ2文。
• スライド2：実施したこと。 行ったretro、修正したプロセス、担ったOKR。skip-levelが確認できる具体的な成果物。
• スライド3：要求すること。 次の項目のH2採用計画と技術的負債の提案。具体的な要求、具体的なコスト、具体的に期待する成果。

これはその後の90日間の信頼を得るための成果物です。また、skip-levelがなぜあなたを昇進させたかを自分の上司に説明するときに引用するものでもあります。説明しやすいよう整理してください。

H2採用計画と技術的負債の計画を提案する

あなたが書いたJDを持つ一つのオープン人員数(コンパニオンのスタッフソフトウェアエンジニアJDテンプレートを参照)と、上位3つの技術的負債項目の概算コスト付きランク付きリストを作成してください。

採用計画は次の点に答える必要があります。どのポジション、なぜ別のポジションではなくこのポジションか、採用後に解放される事項、人員数が得られない場合のトレードオフ。1ページで。

技術的負債リストは各項目について次の点に答える必要があります。現在それが原因で何が壊れているか、修正のおおよそのエンジニアリングコスト(人週単位)、期待される改善(ページ数30%減、オンボーディング2週間短縮など、測定可能な形で)。3つをランク付けしてください。異論があれば根拠を示して反論してください。

提出し、守り抜いてください。人員数や技術的負債の予算が得られなかったとしても、計画を書いて守り抜くという行動自体が、あなたを「新任EM」から「自分の意見を持つEM」へと移行させます。

実際に起こりがちな失敗パターン

このプランが外れる3つの予測可能なパターンがあります。

元ICとしてコードに引き戻される衝動

手が動かせないのが辛いとき、それは弱さではなく、禁断症状です。週に90分の「エンジニアリング時間」をブロックして(アーキテクチャレビュー、mergeなしでのPR閲覧、ジュニアエンジニアとの難問デバッグ)、そう呼んでください。「コーディング」とは呼ばないこと。このラベルが重要なのは、毎回「今やろうとしていることはメンタリングか、それとも逃げているのか」と自問させるからです。

「自分はマネージャーではない」というアイデンティティ危機

6週目にまだそう言っているなら、チームはすでに気づいています。彼らはそれを「状況が辛くなったらICに戻る予定なんだ」と聞こえるため、辛いことを持ち込まなくなります。

代わりに「私はかつてコードをshipしていたマネージャーです。今はコードをshipする人をshipしています」と言い換えましょう。最初は違和感があるかもしれませんが、声に出して言ってみてください。10週目には何の違和感もなくなります。

過剰修正

1週目に3冊のマネジメント本を読み込み、月曜日に新しいフレームワーク、新しい習慣、改名されたstandupを携えて現れるEM。直属の部下はこれを嫌います。彼らは新しい運営システムを求めていませんでした。話を聞いてくれるマネージャーを求めていたのです。

まず傾聴、次に変更。30日間の状況把握はまさにこれをしないためにあります。

実際に役立つテンプレートとツール

一度作れば永続的に再利用できる4つの成果物。

• 最初の1:1の質問スクリプト。 上記の3つの質問と、3つの追加質問：「あなたにとって素晴らしい週とはどのような週ですか?」「チームの中で私が特に時間をかけて話すべき人は誰ですか?」「誰も教えてくれないけれど、私が知っておくべきことは何ですか?」
• 30日間観察ログテンプレート。 3列：聞いたこと、見たこと、まだ変えない理由。3列目が規律です。
• 90日間報告テンプレート。 スライド3枚、上記の構成、スライド当たりの字数に上限を設けてパディングを防ぐ。
• 厳しいフィードバック会話スクリプト。 状況、行動、影響、要求。印刷してください。最初の6ヶ月間、難しい1:1の前に毎回記入してください。

90日目の成功の測定

次の5つすべてが最終日に当てはまれば、90日間が機能したことになります。

1. 全直属の部下が少なくとも6回の1:1を実施しており、あなたが彼らのために取り組んでいることを言える。
2. チームの開発速度が測定されており、傾向が見えている。横ばいであっても、その理由を正確に把握している。
3. 一つのプロセスが目に見えて改善されており、チームがその功績を認めている。
4. skip-levelがチームの最大のリスクを一文で説明できる。あなたが伝えたからです。
5. 90日間コードをmergeしていないが、チームは問題なく機能している。

最後のものが本当のテストです。90日間は、まだコードを書けるという証明ではありません。やめられるという証明なのです。

関連記事

• 部下が楽しみにする1:1の進め方
• 実行から指揮へのシフト
• 元同僚のマネジメント
• スタッフソフトウェアエンジニアJDテンプレート