今月からエンジニアリングチームのマネージャーになりました。エンジニアからエンジニアリングマネージャーになると何が変わるのかを書いてから、数週間後のことです。誰も事前に教えてくれなかったのは、何もかもが緊急に見えるということです。新しいチーム、新しい会社、そして自分が来る前から積み上がっていたTODOリスト。全部を一度にやるのは無理なので、まず3つに絞って取り組むことにしました。

チームを知る

#

全員と1:1を組んでいます。スプリントの話ではなく、その人自身の話をする時間にしたいと思っています。キャリアで何を目指しているのか、最近何にモヤモヤしているのか、明日変えられるなら何を変えたいか。この場での私の仕事は、ほとんど「黙って聞くこと」です。信頼は最初の1週間では築けませんが、最初の1週間で失うことは十分ありえます。

働き方も人それぞれです。細かい指示がほしい人もいれば、任せてもらったほうが力を発揮する人もいます。この見極めを間違えると、お互いに不幸になります。Camille Fournierの『The Manager’s Path』がこのあたりをよく書いています。結局のところ、共感してちゃんと聞くことがマネジメントの大半なんですよね。

「なぜ今こうなっているのか」を学ぶ

#

プロセスにも、ちょっと不思議なアーキテクチャにも、過去の意思決定の痕跡が残っています。何かを変える前に、これまで何が試され、何が失敗し、会社が本当に大事にしているものは何かを知っておきたいのです。

どの会社にも、意思決定が実際どう回っているかという暗黙のルールがあります。これを早くつかむほど、チームのために動ける範囲が広がります。Andrew Groveが『High Output Management』で書いているとおり、全体像を自分で理解しないまま、チームの仕事をそこに合わせることはできません。

コードを読む

#

もうチームで一番コードが書ける必要はありませんが、アーキテクチャ、痛いところ、技術的負債がどこに埋まっているかは把握しておくべきです。なのでコードを読み、デプロイパイプラインを眺め、「1週間まるごと自由に使えたら何を直したい？」とメンバーに聞いて回っています。この質問の答えは、たいてい一番正直なロードマップになります。

もうひとつの効果もあります。プロセスだけでなく、仕事そのものに関心があるのだとチームに伝わることです。

あとは邪魔をしない

#

土台ができたら、やることはシンプルです。コンテキストを整え、目標を共有し、技術的な判断はチームに任せる。マネージャーの仕事はすべてのPRを承認することではなく、チームに必要なものが揃っていて、正しい方向を向いているかを確かめることです。Gene Kimの『The Phoenix Project』も同じ主張をしています。自分たちで意思決定できるチームは、上の承認を待つチームより速く動き、良いソフトウェアを作ります。

新任エンジニアリングマネージャーにおすすめの本

#

本文で触れた3冊を、ここにまとめておきます。

ほかに、新任EMが読むべき本としてよく名前が挙がるのが、Will Larsonの『An Elegant Puzzle』とLara Hoganの『Resilient Management』です。前者はチームの規模、計画、組織設計といった仕組みの側を扱い、後者はチームを知る、期待値をはっきりさせる、きちんと伝えるといった人の側を扱った、短く実践的な本です。

半年後にどうなっているか、また書きます。