エンジニアリングマネージャーの1日: 求人票には書かれていないこと
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
午前8時47分。on-callのエンジニアが午前3時14分にPagerddutyからPagerDutyを受けました。Postgresのレプリカの問題で、午前3時22分には自己回復しました。つまり彼女は8分の睡眠で残りの夜を失いました。skip-levelは正午までにロードマップの更新を求めていて、あなたはまだNotionを開いていません。13分後にシニアICとの1:1がありますが、準備をしていません。6か月前にあなたをこの仕事に送り込んだリクルーターは「ハイパフォーマンスなチームをリードする」と言っていました。
その言葉は、夜11時に在庫確認をして常連客に注文間違いを謝っているときに「レストランを経営しています」と言うのと同じくらい正確です。それは見出しです。仕事はその下にあるすべてのことです。
これが、B2B SaaS企業で5〜12人の直属の部下を持つエンジニアリングマネージャーの実際の1日です。リアルなタイムスタンプ、リアルな中断、リアルなトレードオフ。ICからの転身を検討しているなら、これが何年も続く仕事かどうか考えながら読んでください。現役のEMで、中断ばかりで失敗しているように感じているなら、これを読んで、あなたは失敗していないことを認識してください。あなたは仕事をしているのです。
8:00am: standup準備、Slackの整理、PagerDuty
チームがログオンする前に、誰も見ていない作業をします。
PagerDutyを開く。昨夜のインシデントをざっと確認する。誰がページを受けたか、何が発火したか、本物だったか、それとも3回のsprintで修正するようフラグを立てたのと同じフラッピングアラートだったか。本物なら、on-callエンジニアは今日カバーが必要です。Slackで伝えて、standupをスキップして90分余分に寝るよう言う。ノイズなら、可観測性を担当している人へのチケットになります。いずれにせよ、standupの前に決定して、チームが混乱を吸収する代わりにあなたが吸収できるようにする。
次にSlack。6つのチャンネルにわたって47件の未読があります。内容を読んでいません。2つのことだけスキャンしています: 誰がブロックされているか、誰がフラストレーションを感じているか。ブロックされているエンジニアは午前10時までに道を開けてもらう必要があります。そうでなければ半日を失います。公開スレッドでフラストレーションを感じているエンジニアには公開返信ではなくDMが必要で、そのDMはおそらく今朝中に送る必要があります。
Linearを開く。またはJira。チームが使っているどちらかを問わず、質問は同じです: どのチケットがレビューで止まっているか、チーム外の依存関係にブロックされているか、「進行中」に見えるが4日間動いていないものはどれか。最後のカテゴリーが危険です。4日間チケットを動かしていないエンジニアは、ブロックされていて言いたくないか、あなたに伝えていない何かに取り組んでいるか、静かに他の仕事を探しています。金曜日までにどれかを把握する必要があります。
3週間コードを書いていません。かつてはコーヒーとコンパイラでこの時間帯の作業をしていました。今はコーヒーと7人分のコンテキストをロードした状態で行います。「私がコードを書く」から「7人がコードを書くための道を開ける」への移行は、誰も最初に警告してくれないことの1つであり、元ICの多くが最初の6か月間静かに惜しむ部分です。
9:00am: 準備できていなかった1:1
1:1はその週で最も影響力のある30分であり、sprint計画が長引くと最初に犠牲になります。今日はシニアバックエンドエンジニアのMayaとです。彼女はここに3年います。あなたの最後の大きなマイグレーションをリリースしました。そして2週間前、彼女のLinkedInが「転職活動: 非公開」から「転職活動: 公開」に静かに変わりました。
そこから始めません。「今週どうですか?」から始めます。そして黙ります。
本当の1:1はステータス更新ではありません。ステータス更新はLinearとstandupで行われます。1:1は、チケットに収まらないすべてのことのためにあります。彼女が抱えていたフィードバック、彼女が反対しているアーキテクチャの決定、マネージャー（あなた）が彼女のリデザインを半分に削られたときに十分に押し返さなかったという事実。あなたの仕事は、難しいことを言える安全な場所を作り、彼女が言ったことに対して行動することです。
午前9時18分にPagerDutyが発火します。あなたのチームのサービスではありませんが、隣接しているので十分でSlackが明るくなります。電話を確認します。Mayaが確認するのを見ます。うまくいくスクリプトはこれです:
「うちではないですが、Slackがうるさくなりそうです。20秒でミュートにして、続けましょう。あなたの時間の方が大切です。」
そして実際にミュートします。次の12分間、Slack通知を目で追いながら半分しか聞いていないわけにはいきません。1:1は完全な注意を向けるか、キャンセルするかのどちらかです。中間はありません。中間という選択肢こそ、シニアエンジニアがマネージャーが本当は存在していないと学ぶ方法であり、そうやってMayaのLinkedInが「公開」から「内定を受諾しました」に変わります。
10:30am: PRレビュー、ただし正確性のためではない
GitHubを開きます。またはGitLab。チームにわたって14件のオープンPRがあります。正確性のためのレビューはしていません。staff engineerが正確性をレビューしていて、今の彼女の方があなたより得意です。
フローのためにレビューしています。
48時間以上レビューを待っている人は誰ですか? そのエンジニアは勢いを失い、おそらく別の作業にコンテキストスイッチしています。つまりレビューがようやく来たとき、コンテキストを戻すのに1時間かかります。レビュアーを見つけ、なぜ止まっているかを確認し、ブロックを解除してください。
同じファイルに触れているPRが2つあるのはどれですか? マージコンフリクトになりかけており、エンジニアの1人が朝をrebaseに費やすことになります。今すぐ10分の通話に呼んでください。
40行の変更に6ラウンドのnit commentがあるPRはどれですか? シニアエンジニアがジュニアに対して慎重になりすぎており、双方向の信頼を侵食しています。スレッドにコメントしません。シニアにDMします: 「変更は問題ないです。approveして進めましょう。」 その判断を下せるのはあなただけです。なぜなら、その権限を持っているのはあなただけだからです。
GitHubはエンジニアのためのコードツールです。あなたにとっては、マネジメントのサーフェスです。注意が止まっている場所、コラボレーションが摩擦を生んでいる場所、チームの開発速度がレビューのボトルネックで漏れている場所をリアルタイムで示すダッシュボードです。これをPRキュータックスと呼んでください。2日以上滞っているすべてのPRは、失われたフォーカスの形で複利コストをかけています。それに気づくことが仕事なのはあなただけです。
11:15am: sprint計画、そして中断
tech leadとの次のsprintのLinearボードの整理を始めて15分が経ちます。「認証プロバイダーの移行を調査する」というストーリーに反対意見を述べています。これはストーリーではなく、火曜の午後に見せかけた四半期分の作業だからです。
Slack: 「2分いいですか?」プロダクトVPから。
2分で終わることはありません。質問が1つで終わることもありません。「ちょっとした質問」とは「AIフィーチャーのローンチを3週間前倒しにするのですが、チームは現実的にいつまでに何をリリースできますか?」ということです。その答えにはチームのキャパシティ、既存のsprintコミットメント、AIフィーチャーを遮断している技術的負債、シニアエンジニアの来月のPTO、そして「できません」と言うのがキャリアを左右する一言であり年に数回しか使えないという政治的現実を把握している必要があります。
通話に出ます。通話の中で答えを出しません。「依存関係を確認して午後4時までに実際の数字を持って来ます」と言います。そして午前11時38分にtech leadとのsprint計画に戻ります。彼女は23分間礼儀正しく画面を見ていました。
これが求人票に載っていない役割です: コンテキストの翻訳者。あなたはエグゼクティブの戦略（「Q3までにAIが欲しい」）とエンジニアリングの現実（「認証マイグレーションがそれをブロックしており、認証を知っているエンジニアは育児休暇中」）の間に座っています。どちらにも「はい」とは言えません。あなたの仕事は、どちらの方向にも信頼を壊さない形で一方をもう一方に翻訳することです。うまくいく週もあります。うまくいかずにチームが振り回される週もあります。どちらも普通のことです。
1:00pm: 決して起きない自分だけのミーティング
ランチ後、カレンダーには「FOCUS: Q3計画ドキュメント」が表示されています。3週間ここにあります。毎日移動されています。
これは自分だけのミーティングの問題です。中断されない思考が必要な作業、つまりチームの四半期計画、人事評価、金曜日にstaff engineerからエスカレーションされたアーキテクチャの決定は、今日の締め切りが決してありません。だから常に、締め切りがある作業に負けます。on-callアラート。カバーが必要なエンジニアからのSlack DM。VPの「ちょっとした質問」。
ほとんどのEMはこの戦いで負けます。Q3ドキュメントはDirectorが月曜朝に必要だから日曜夜11時に書かれます。人事評価は締め切りの週に詰め込まれ、それが反映されます。
修正は地味です: カレンダーにフォーカスブロックを入れ、外部のミーティングと同じように扱う。重複するリクエストは断る。本物の緊急事態でブロックを失う週があることを受け入れ、それは問題ありません。ただし、デフォルトは守られなければなりません。Senior EMやDirectorになるエンジニアは、危機になる前に自分の思考時間を守ることを学んだ人たちです。
3:30pm: リアルタイムのSlackではなく、非同期のNotion
午後半ばには頭が疲れています。これは最も思考コストが低く、最も量の多い作業をすべき時間です。今日は何も変えないけれど、次の2四半期にわたって複利で積み上がるNotionのドキュメントを書く作業です。
チームハンドブックの更新。2週間前にエンジニアが依頼したon-callのrunbook。次のエンジニアが1か月tech leadに同じ質問をしなくて済むように書くことを約束した最後のsprintのretroメモ。リクルーターが待っている採用ループのキャリブレーションドキュメント。
どれも緊急ではありません。どれも重要です。複利効果とは、6か月後に新しいエンジニアをオンボーディングするとき、彼らがNotionの3ページを読んで1週間でランプアップするということです。tech leadに1か月間同じ質問をするのではなく。それが書き仕事のレバレッジです。止めるまで見えません。そして止めるとチームが何故か遅くなります。誰もその理由を指摘できないまま。
5:00pm: 昇進資料の作業
チームはログオフしています。Notionを開きます。2つの昇進資料（1つはシニア行き、1つはStaff行き）と自己評価を書いています。
昇進資料は毎日後回しにされる作業であり、人事評価シーズンがトラックのようにぶつかってきます。昇進するエンジニアは、あいまいな「インパクトの実証」という言葉で週末に詰め込んだマネージャーではなく、サイクル全体にわたって具体的な証拠を積み上げたマネージャーを持つエンジニアです。
実際に機能するNotionのテンプレートの断片:
## 昇進案: [名前] → [レベル]
### 担当範囲の変化（直近2四半期）
- [具体的なプロジェクト、エンドツーエンドで担当、測定可能な結果]
- [名前のある成果を持つ部門横断的なコラボレーション]
- [名前のあるメンティーと結果を持つ具体的なメンタリングの瞬間]
### 次のレベルがすでに起きているという証拠
- [彼らが書いたデザインドキュメントへのリンク]
- [彼らが主導したインシデントへのリンク]
- [ピア/skip-levelからのフィードバックへのリンク]
### パネルが提起するリスク（と回答）
- [リスク]: [先回りした回答]
- [リスク]: [先回りした回答]
### パネルへのお願い
- [より重視/軽視してほしいこと]
リスクと回答のセクションは、ほとんどのマネージャーが省略するものです。勝敗を分けるのもここです。昇進パネルはデフォルトで懐疑的であり、異議を先回りした資料はパネルが口を開く前に仕事の80%を終わらせています。
最初の資料を午後5時51分に仕上げます。子どもの発表会が午後7時にあります。2つ目は明日やります。ただし明日は忘れていた1:1、インシデントレビュー、候補者のパネルがあります。なので木曜日にやります。たぶん。
スケーリングの変曲点: 5人から9人へ
ここまで説明してきたことはすべて5人のエンジニアで機能します。9人で壊れます。
5人なら、すべてのPRを頭に入れられます。全員と週次で1:1できて、それでも考える時間があります。standup中の体の言語で誰が行き詰まっているか、尋ねられる前にわかります。
9人ではできません。数学が合わない。9回の30分週次1:1は4.5時間で、準備とフォローアップを含めると丸一日になります。かつてざっと見ていたPRは、あなたに届く前にtech leadのフィルターが必要になります。standupはシグナルでなくなり、声が多すぎてステータスの演劇になります。
5人では無視できたシステムが9人では必須になります: 新しいメンバーが基準を知るための書かれたチームチャーター、あなたの記憶に依存しないon-callローテーション、頭の外に存在する採用ルーブリック、そしてチームで最も経験のある人には隔週になり、最も新しいメンバーや最近シニアレベルになった人には週次のままの1:1です。
隔週に切り替えると、誰かが疎外感を感じます。直接理由を伝えてください。「以前より余裕がなくなっています。隔週が維持できるペースです。急ぎのことがあれば、Slack DMは開いていて1時間以内に返信します。」その誠実さは、失われた30分よりも多くの好意を買います。
求人票が間違っていたこと
「ハイパフォーマンスなチームをリードする」とは実際にはこういうことです:
- 集中できる環境を守る。 あなたの1日の大部分は、チームが経験しなくていいように混乱を吸収することです。
- あいまいさを翻訳する。 エグゼクティブの戦略はわざとあいまいです。チームにはフィーリングではなくチケットが必要です。
- 彼らの時間を守る。 VPの「ちょっとした質問」に断ることは、その仕事を回避することではなく、仕事の一部です。
- 誰も書かないドキュメントを書く。 Runbook、チャーター、昇進資料、retroのまとめ。
- ストレスを吸収して彼らが経験しなくて済むようにする。 これが役割の地味な核心であり、人を燃え尽きさせる部分です。
求人票には「成果を出す」とあります。実際の1日には「次の人がゼロから考えなくて済むようにNotionのページを書く」とあります。
まとめ
この記事のすべてが活力を与えてくれるように聞こえるなら（本当に楽しみにする1:1、翻訳を楽しめる混乱、誰もやらない書き仕事の静かな複利）、あなたは準備ができています。
消耗するように聞こえるなら（ミーティングを吸収するよりコードをリリースしたい、人の問題より技術的な問題を解きたい）、ICのキャリアパスは降格ではありません。シニアワークの別の形であり、業界もようやくその価値を正当に評価するようになっています。Staff Software Engineer JDがこの記事のコンパニオンである理由はそこにあります。両方読んで、その辛い部分と5年間向き合えるほうを選んでください。
正解は、悪い日でもやる価値のある仕事だと感じるほうです。
関連記事
