エンジニアリングマネージャーのよくある失敗パターン（そしてどうやめるか）
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
日曜の夜。staff engineerが金曜日に開いたPRをレビューしています。「コンテキストを持っている人間がほかにいない」からです。最もシニアな直属の部下との1:1ドキュメントは6週間前と同じ3箇条のままです。組織変更以来、retroを1度も開催していません。自分はコーチング型マネージャーだと自分に言い聞かせています。チームはあなたを「いい人だけど不在」と表現するでしょう。
このガイドはそのギャップを埋めるものです。
私は上記のすべてのストーリーで悪いEMを経験してきました。説教はしません。パターンを名指しし、ダメージを定量化する数字を示し、今週何をすべきかを正確に伝えます。Lara HoganもWill LarsonもCamille Fournierも1年中読めますが、アドバイスを火曜日の朝の行動変容として体に落とし込むまでは、チームはまだそれを読んでいないバージョンのあなたに苦しんでいます。
なぜ今これが重要なのか
在職1年目のEMは2つのことで評価されます: チームのアウトプットとチームの人材定着です。ほとんどが人材定着で失敗します。失敗のパターンが誰かが辞めるまで見えないからです。その時点で3か月の後任探し、6か月のランプアップ、そして立ち去った人のコンプ、リクルーター費用、彼らが残していったチームへのランプアップ遅延を加えると、1人の退職あたりおよそ18〜25万ドルのフルロードコストが発生します。
1年間に惜しまれる退職が2件あれば、届けた生産性の向上のほとんどが吹き飛びます。見えないものは管理できないので、最初の仕事はパターンを名指しすることです。在職6〜18か月のEMで最もよく見られる7つを以下に示します。
罠1: コーチングではなくコーディング
症状。 週に3〜8件の自分のPRをクローズしています。「チームのブロックを解除している」と自分に言い聞かせています。実際には、コードのその部分に成長するべき人を特定するという、より難しく時間がかかる作業を避けています。
実際の数字。 コーディングに費やす1時間ごとに、約1.5〜2時間のチームコーチングが失われます。コーチングは中断主導型であり、今のあなたは集中しているので手が届かないからです。6人のチームでは、週に約10時間のコーチング時間が失われます。1四半期で、直属の部下の成長からおよそ130時間、つまりシニア開発時間の1スプリント分を奪ったことになります。
対策。 ICとしての貢献を週の10%に制限する。カレンダーにブロックし、「IC time」とラベルを付け、その時間が終わったら終わり。次の「これだけやっておこう」タスクを、それが成長領域に触れる部下に渡し、なぜ渡しているかを伝える: 「これはシニアになるための仕事です。担当してほしいし、始める前にデザインをレビューしたい。」その最後の一文が、handoffとdumpの違いです。
罠2: 難しい1:1を避ける
症状。 「コードをリリースするが有害なコードレビューをしている」シニアとの週次1:1が、その行動を取り上げる前に毎回「時間切れ」になります。3か月後、チームの2人がどこかで面接しています。
実際の数字。 有害だと感じるピアがいて、マネージャーがそれに対処していないエンジニアの平均在職期間: 8〜11か月。マネージャーが最初の4週間以内にその行動を名指ししたエンジニアの平均在職期間: 2.5年以上。その差は、回避の1年ごとにフルのバックフィルコスト1件分、プラス、あなたが行動しなかった様子を見ていた残りのチームへの文化的コストです。
対策。 2週間以上あるトピックを避けているなら、次の1:1の最初にそれを取り上げます。前置きなし、「週末はどうでしたか」なし。スクリプト: 「コードレビューの進め方について難しい会話のために最初の15分を使いたいです。2人のピアからXを聞きました。あなたの視点を聞かせてください。」 冒頭を和らげないでください。傾聴を和らげてください。この会話がうまくいかない最もよくある理由は、間違ったことを言ったからではありません。30秒間正しいことを言って、次の14分間それを謝り続けたからです。
罠3: 開発速度メトリクスへの過度な依存
症状。 skip-levelでstory pointsを引用します。先四半期に20%の開発速度向上を喜んでいましたが、それはシニアがbacklogを再ポイントしたからで、実際のスループットの変化は何もありませんでした。チームの状況を聞かれると「開発速度が上がっています」が最初の言葉として出てきます。
実際の数字。 ある四半期の開発速度変化の約70%は、実際の生産性変化ではなく見積もりのずれです。開発速度をターゲットにして管理するチームでは、DORA変更失敗率が2四半期以内に15〜25%上昇します。数字を良く見せるためにテストの深さとレビューの厳密さを削るからです。ダッシュボードを最適化して、下のシステムにダメージを与えました。
対策。 週次レポートの開発速度を3つの数字に置き換えます: デプロイ頻度、変更失敗率、復旧時間。組織でそれらを追跡していないなら、1四半期間スプレッドシートで自分で計測する。セットアップに約90分、週10分のメンテナンスで済みます。DORAをskip-levelに持ち込んで、pointsから移行している理由を説明する。初めてやると、skip-levelはあなたを下に見るのではなく、むしろ上に見ます。pointsの引用をやめてください。
罠4: 昇進基準のドキュメント化不足
症状。 「シニアに近い感じ」の直属の部下が1人と、「まだそこに達していない」が1人います。90秒で2人の違いを書き出すよう言われても、できません。「プレゼンス」「オーナーシップ」「判断力」という言葉が出てきて、その場の人が礼儀正しく頷きます。
実際の数字。 昇進のアウトカムは、基準が書かれている場合には約0.4の相関があり、基準が書かれていない場合のマネージャーの確信と直近性バイアスとは約0.7の相関があります。そのギャップは、キャリブレーションで「あなたの判断を信頼します」として現れます。それが声の大きい人が昇進し、静かな人が停滞する仕組みです。コストは約18か月後にチームに着地します。明確な理由なく見送られた最も優秀なICが、理由を示してくれた企業に移ります。
対策。 今週、「このチームでstaffとはどういうことか」の1ページのドキュメントを書く。3セクション: 担当範囲、インパクト、行動。それぞれに、明日昇進させたい人から引いた4〜6つの具体例を入れる。次の1:1で全員に共有する。「ここにドキュメントがあります、何か質問があれば」というメールではなく。一緒に読み進める。彼らが自分はどこにいると思うかを尋ねる。キャリブレーションでも同じドキュメントを使う。四半期ごとに更新する。ドキュメントが目的ではありません。それが強制する会話が目的です。
罠5: コンテキストからチームを遮断する（悪い方法で）
症状。 プロジェクトがリスクにさらされていること、人員が凍結されていること、顧客がv1を嫌っていることを伝えずにチームを「政治から守っています」。2週間後にSlackチャンネルで知ることになります。あなたのチームでさえない誰かから。その後彼らはあなたに尋ねて、あなたは「そうですね、言おうとしていました」のようなことを言います。
実際の数字。 情報不足を感じているエンジニアは、情報過多を感じているピアより30〜40ポイント低いエンゲージメントスコアを出します。下位四半期のエンゲージメントは、12か月以内の離職を基本率の2〜3倍で予測します。翻訳すると: 悪い遮断は1年に約4人に1人の直属の部下のコストがかかり、失う4人は選択肢を持っている4人です。
対策。 デフォルトは共有。テストは「これでストレスを与えるか」ではなく、「自分が彼らの立場ならこれを知りたいか」。週次15分のコンテキストstandupを実施する: リーダーシップレベルで何が変わったか、何がまだ不確かか、何を無視すべきか。何かが本当に機密性が高すぎる場合は、「まだ共有できないことがあります、いつ共有できるかはこの時点です」と言う。その一文はいかなる婉曲表現よりも信頼を買います。エンジニアはチームを守るマネージャーと自分を守るマネージャーの違いがわかります。
罠6: retroを開催しない（またはフェイクのretroを開催する）
症状。 最後のretroは11週間前でした。またはretroをやってはいますが、アクションにオーナーや期日が設定されないので、同じ3つの問題が毎回永遠に出てきます。誰かがデプロイがまだ辛いと言います。全員が頷きます。何も起きません。次のretroで誰かがデプロイがまだ辛いと言います。全員が頷きます。
実際の数字。 名前付きオーナー、期日、次のretroでのフォローアップを伴う本物のretroを開催しているチームは、開催していないチームより約25%多くインシデントのない四半期をリリースします。フェイクのretroを開催しているチームはゼロと同じスコアを出します。つまり、ループのない儀式は何もしないより積極的に悪いです。問題を浮かび上がらせても解決しないとチームに教えており、ゼロからやり直すよりそのレッスンを取り消す方が難しいです。
対策。 ケイデンス: 2sprintごと、60分、例外なし。フォーマット: 4列（続けること、やめること、増やすこと、ブロックされていること）。すべてのアクションにオーナー名と期日を付ける。公開のボードでアクションを追跡する。次のretroの冒頭で前回のアクションをレビューして始める。70%未満しかクローズされていなければ、それが会話であり、ブレインストーミングはスキップします。チームは最初に反対するでしょう。それでも実施する。2サイクル後、アクションをすでに名前付きで持ってきて出席するようになります。なぜならあなたがチェックすることを知っているからです。
罠7: 採用が難しいから採用を遅らせる
症状。 4か月間開いているポジションがあります。8人の候補者を面接しました。「基準に達していない」人は誰もいませんでした。その間チームは1四半期間80%のキャパシティで稼働し、最も優秀なシニアが2人分の仕事をして1:1で疲れた様子を見せ始めています。
実際の数字。 典型的なSaaSのコンプでシニアポジションが開いているコスト: 逃した産出量で月約2万〜3万ドル、プラス残りのチームにかけている負荷、これが彼らの離職リスクを高めます（罠5参照）。4か月間のポジション空きは会社に10万ドルのコストをかけており、おそらくその上に惜しまれる退職も1件買っています。あなたが維持している基準は今や、組み合わせた2件の安い採用よりも多くのコストがかかっています。
対策。 基準を書面で定義する: 必須3つ、あれば望ましい3つ。そのドキュメントに対して全ての面接ループを実施し、感覚に対してではなく。5人連続で却下しているなら、基準が問題であり市場ではありません。基準を意図的に下げてskip-levelになぜかを伝えるか、1つの高い採用が成長できる2件の安い採用に役割を分割する。コンパニオンのStaff Software Engineer Job Descriptionは、「基準」が書面でどのように見えるかの良い出発点です。チームが燃え尽きている間にユニコーンを待つのをやめてください。ユニコーンは来ません。チームこそが実際に持っている資産です。
まとめ: 30分の自己監査
タイマーを設定する。上記の7つの罠それぞれについて、1〜5点で自己採点する。正直に。skip-levelはすでに知っています。
3以下の項目: このガイドから1つの対策を選び、今週のカレンダーに入れ、静かに落とせないように1人のピアEMに何を約束したかを伝える。7つすべてを一度に直そうとしない。全部に当たって全部弾き飛ばされるだけです。最低点を選び、2週間その対策を実施し、また監査する。
これが機能して「コーチングについてもっと意識的になろう」が機能しない理由は、対策はカレンダーブロックであり、抱負ではないからです。カレンダーブロックは月曜日を生き延びます。抱負は生き延びません。
90日後の良い状態の姿
具体的な絵として。今週監査して2週間に1つの対策を約束すれば、8月には次のようなチームを持てるはずです:
- 週の10%未満しかコードをリリースしておらず、それについて罪悪感を感じない。
- 少なくとも2つの難しい1:1をやり遂げ、そのためにチームが良くなっている。
- 週次レポートはdeployの頻度と変更失敗率をリードしており、story pointsではない。
- 全員がそのチームにおける次のレベルが何であるかを書面で知っており、自分がそれに対してどこにいるかについてあなたと少なくとも1回会話している。
- チームはコンテキストをデフォルトで共有して受け取り、週次コンテキストstandupは誰も疑問に思わない習慣になっている。
- retroは2sprintのケイデンスで70%以上時間通りのクローズされたアクションログと共に実施されている。
- 書面での基準再キャリブレーションなしに8週間以上開いているポジションがない。
これは性格改造を必要としません。これらのパターンを容認しているバージョンのあなたがチームが払っている代価であると決断し、それがなくなるまで一度に1つ変えることを必要とするだけです。
関連記事
Principal Product Marketing Strategist