今月からエンジニアリングチームのマネージャーになりました。誰も事前に教えてくれなかったのは、何もかもが緊急に見えるということです。新しいチーム、新しい会社、そして自分が来る前から積み上がっていたTODOリスト。全部を一度にやるのは無理なので、まず3つに絞って取り組むことにしました。
チームを知る#
全員と1:1を組んでいます。スプリントの話ではなく、その人自身の話をする時間にしたいと思っています。キャリアで何を目指しているのか、最近何にモヤモヤしているのか、明日変えられるなら何を変えたいか。この場での私の仕事は、ほとんど「黙って聞くこと」です。信頼は最初の1週間では築けませんが、最初の1週間で失うことは十分ありえます。
働き方も人それぞれです。細かい指示がほしい人もいれば、任せてもらったほうが力を発揮する人もいます。この見極めを間違えると、お互いに不幸になります。Camille Fournierの『The Manager’s Path』がこのあたりをよく書いています。結局のところ、共感してちゃんと聞くことがマネジメントの大半なんですよね。
「なぜ今こうなっているのか」を学ぶ#
プロセスにも、ちょっと不思議なアーキテクチャにも、過去の意思決定の痕跡が残っています。何かを変える前に、これまで何が試され、何が失敗し、会社が本当に大事にしているものは何かを知っておきたいのです。
どの会社にも、意思決定が実際どう回っているかという暗黙のルールがあります。これを早くつかむほど、チームのために動ける範囲が広がります。Andrew Groveが『High Output Management』で書いているとおり、全体像を自分で理解しないまま、チームの仕事をそこに合わせることはできません。
コードを読む#
もうチームで一番コードが書ける必要はありませんが、アーキテクチャ、痛いところ、技術的負債がどこに埋まっているかは把握しておくべきです。なのでコードを読み、デプロイパイプラインを眺め、「1週間まるごと自由に使えたら何を直したい？」とメンバーに聞いて回っています。この質問の答えは、たいてい一番正直なロードマップになります。
もうひとつの効果もあります。プロセスだけでなく、仕事そのものに関心があるのだとチームに伝わることです。
あとは邪魔をしない#
土台ができたら、やることはシンプルです。コンテキストを整え、目標を共有し、技術的な判断はチームに任せる。マネージャーの仕事はすべてのPRを承認することではなく、チームに必要なものが揃っていて、正しい方向を向いているかを確かめることです。Gene Kimの『The Phoenix Project』も同じ主張をしています。自分たちで意思決定できるチームは、上の承認を待つチームより速く動き、良いソフトウェアを作ります。
半年後にどうなっているか、また書きます。