Could vs. Should: SREチームを初めて管理した1年目

今日までにこの記事は10回以上下書きを繰り返しました。最初に書き始めたときのタイトルは「SREマネジメント1年目の振り返り」でした（現在は2.5年目です）。しかし、その最初の1年で学んだことはすべて、次の年にとって重要なものになりました。Site Reliability Engineering（SRE）チームとエンジニアリングマネジメントの役割には、1つの重要な共通点があると私は考えていました。つまり、やれることはたくさんあるけれども、本当にやるべきことは一部だけで、どちらがどちらかを定義するのは難しいということです。どちらの役割にも膨大な文脈（これが大好きです）と、膨大な曖昧さ（これも大好きです）が必要で、時折訪れる高圧的な状況が物事を面白くしてくれます。

今、私は最初のチームに加えて2つ目のチームも管理しています。そのチームはHoneycomb Private Cloudを支えています。最初の1年で得た経験は、2つのチームを管理するという課題に備える上で非常に重要でした。この記事では、その最初の1年で学んだこと、間違えたこと（および正しかったこと）、そして始めたときに知っておきたかったことについてお話しします。

いきなり深みへ

SREのエンジニアリングマネージャーとしての最初の週は、KubeConでのエンジニアリングチームオフサイトの最中でした。半分はカンファレンス、半分はチームビルディングとロードマッピングで、私は恐怖を感じていました。「部屋に大勢の人を座らせ、何時間も彼らを楽しませる方法を考えなければならない？しかもそれは生産的でなければならない？！」数年間完全にリモートで働いていた私は、それが大惨事にならないわけがないと恐れていました。

結果はうまくいきました。みんなKubeConで疲れきっていました（私たちは二度とカンファレンスの直後にオフサイトをやらないと決めました）。そしてマネージャーの後押しもあって、私はシンプルに保ちました。基本的なアジェンダ項目で人々を話し合わせ、付箋とペンを持参し、すべてを書き留めました。アイデアのロードマップはとても長く、写真を撮るためにテーブルを横切って歩かなければなりませんでした。

（1年後、そのリストを振り返ってみると、これらのタスクをほぼその順序で取り組み、ほとんどを完了させていたことがわかりました。いつかまたその宇宙のエネルギーを活用できたらと思います。）

残りの1年は、学習のプレッシャー鍋でした。私は必死に以下を試みていました：

• 組織が私たちに何を期待しているか、そしてチームが何をすることを期待しているかを理解する
• チームと上司との信頼を築く
• 基本的なマネジメントスキル（例：コーチング、ファシリテーションなど）を習得する
• 高度なマネジメントスキル（例：チェンジマネジメント、戦略的思考など）を習得する
• マネージャーが私に何を期待しているかを学ぶ
• 「マネージャー」という言葉が何を意味するかを学ぶ。アポファティック神学を評価する私ですが、「マネージャーはコードを書く以外のすべてをする」といった否定的な定義よりも良いものを提示できます。また：2026年ではまったく真実ではありません。🙃

最初の1年の終わりには、「これに備えている。深みへ放り込んでくれ」から「なんてことだ、私は深みの中にいる」へ、そして「まあまあ、私は深みの中にいる！」へと変わっていました。しかし、問題がなかったわけではありません。

誤り、そして役立ったこと

私は多くの悪いミーティングを運営しました。 少なくとも、自分を責めたくなるようなミーティングです。参加率が低かったり、気まずいほど長い非生産的な沈黙があったりするものです。チームの視点では「まあまあ」でしたが、私はもっと良くしたかったのです。完璧な発言や完璧な演習を設計しようとすればするほど、人々は参加したがらないことに気づきました。私はミーティングのゴール（賛同？合意？技術設計？情報？振り返り？）から逆算して、完全な参加を可能にする最も軽いプロセスから始め、次のステップを明確にすることを学びました。

私はフィードバックを長く抱え込みすぎました。 それが古くなって、持ち出すのが気まずくなったり、状況が繰り返されたりして、理想的ではありませんでした。私は信頼構築をたくさん行うことで、フィードバックを持ち出す自分のハードルを下げることに集中しました。私自身へのフィードバックや、私から他者へのフィードバックに、摩擦があってほしくないのです！これに役立った演習は、全員に少なくとも一度、建設的なフィードバック（私自身またはチームのプロセスについて）を1on1の場で与えさせることでした。人々に考える時間を与えましたが、誰にも逃げさせず、それが再発するアジェンダ項目として残し、少なくとも1つ改善できることを提示させました（これは彼らよりも私の快適さにより役立ったかもしれませんが、それでも信頼を築く価値ある演習でした）。

私は技術的な意思決定への参加をやめました。 元エンジニアで今はマネージャーの人々は、かつて提供していたのと同じタイプの価値を生み出そうとして陥る罠がたくさんあります。しかし、私は振り子を振りすぎました。私はこの分野で8年以上の直接的な経験があるにもかかわらず、技術的な意思決定から完全に身を引いていました。ある意味では、ファシリテーションやチームオーナーシップを構築する方法を学ぶ上で素晴らしいことでした。しかし、それは私たちの成果には逆効果でした。一部のプロジェクトは私が指摘できたかもしれない障害にぶつかり、一部の決定は曖昧でした。私は文脈を使って、 unilaterallyに判断するのか、方向性を推奨するのか、アドバイスを共有するのか、静観するのかを決めることを学びました。チームをバイアスするのではないかと心配な場合は、私が何をしているのか、なぜそうするのかを正確に述べ、部屋に漂うマネージャーの意見という見えない重みではなく、直接その理由について話せるようにしました。

しかし全体として、私が最も努力し、最も役立ったことは、あらゆる形でフィードバックを求め、たくさん読むことでした。自分の行動の結果に注意を払わず、それらを振り返らないなら、マネージャーとして成長することはできません。

次の年

2年目には、スタッフエンジニアの突然の退職、大規模な契約交渉（楽しい社内交渉も！）、そしてSREチームを管理する特有の興味深い部分など、多くの課題がありました。次の1〜2回の記事では、AIへの急速な戦略的シフトや、2つのチームを管理することから学んだことを取り上げ、現在に追いつきます。

その間に、1年目かもしれないマネージャーや、マネジメントの基盤を築いているマネージャーへのアドバイスを以下に示します：

• 同僚やチームとの関係を、可能な限り強く、高い信頼関係で築くこと。あなたの役割はこれなしでは不可能になります。
• フィードバックを求め、フィードバックのように見えないものからもそれを見つける。
• 3人に、あなたの役割をどう見ているか、そしてチームが何をしていると思うかを尋ねる：上司、その上司、そして部下。
• 本のおすすめを人々に尋ね、それを読む。

そして最も重要なこと：命令を与えるよりも、はるかに多くの質問をする。