チームスポーツからの比喩を、リードの方法を説明するために何年も使ってきた：プレイングキャプテン。腕章をつけたままプレーヤー。ダッグアウトのマネージャーではなく、コーナーをひたすら走る純粋な個人コントリビューターでもなく — ラインを設定してからチームと一緒にそれを走る人だ。
「スポーツの比喩を使う」はブログ記事で告白するのが少々恥ずかしいことだと自覚している。受け入れる。私が見つけた中で最も正確なフレーミングだ。
実際に何を意味するか
プレイングキャプテンは特定のリーダーシップの姿勢だ。「いくつかのアーキテクチャ会議に出席するテックリードだ」ではない。「関連性を保つために少しコードを書くVP of Engineeringだ」ではない。もっとこれに近い：私はコードベースに意味のかたちで入っている。アーキテクチャ上の決定を、腕の長さのドキュメントからではなくチームがデバッグしているのと同じコールスタックから行っている。ペアリング、レビュー、非自明な機能の実装、移行の後悔になる前のデザイン問題のキャッチ。
同時に、リードの仕事をやっている：ロードマップの形成、ブロッカーの排除、周りのエンジニアの成長、クロスチームの会話の実行。
目標 — これが理想主義的に聞こえるが実際に機能するのを見た部分 — は、アーキテクチャがクリーンでよく伝達されているから、すべての決定を承認するすべての会議にいるからではなく、チームが自律的に実行できること。プレイングキャプテンは両方の失敗モードを避ける方法だ：なぜサービスが遅いかを知らない不在のテックリードと、他の誰にも判断を下させないハンズオンのエンジニア。
12人と3人でどんな様子か
AFAQではCTOとして12人チームを持っていた。締め切り内に本番コードを書くには十分小さく、守るべき人々、所有するべきロードマップ、意見を持たなければならないアップデートを求めるボードがいるには十分大きい。その規模でのプレイングキャプテンは、ほとんどの部屋で最も上位の技術的声を本当に持ち、それを速く動くために使う — コンセンサスを待つことが時々間違ってから修正するよりも遅いから、DBスキーマの難しい決定を下す。
Bytroでは、マルチスクワッドのモダナイゼーションプロジェクトのリード開発者だった。質感が違った。チームにはすでにシニアなエンジニアがいた。私の仕事は最速のコーダーであることではなく、並行して動いて同じドメインコンセプトのために四つの互換性のない抽象化を作り得るスクワッドにわたるアーキテクチャビジョンを所有することだった。どの抽象化が保たれていてどれが崩れかけているかを知るためにコードにいた。Confluenceのドキュメントからそれはできない。
auxmoneyでは信用評価プラットフォームが十分な複雑さと十分な速度を持っていて、ハンズオンであることは個人的なコントリビューションへのノスタルジアではなく、有用な技術的ガイダンスを与える唯一の方法だった。チームがトレースしているのと同じリクエストパスをトレースしていれば、レイテンシ問題を間違ったレイヤーで嗅ぎとれる。Jiraボードからは嗅ぎとれない。
反論を最大限に強調する
「エンジニアリングマネージャーはコーディングをやめるべき」は本物のアドバイスで、本物を見た本物の人々から来ている。それが説明しているパターンを見てきた：昇進して今すべての設計レビューをブロックするシニアエンジニア、なぜなら彼らはまだ部屋の最高のコーダーだと自分を考えているからだ。面白いチケットを取る人。すべてのコードレビューを自分の審美的な好みについてにする人、そして彼ら以外の誰もコードベースの所有権を感じない。
それはプレイングキャプテンではない。それはプレイングキャプテンをひどくやることだ。
失敗モードは本物だ。修正はコーディングをやめることではない。修正はチームのためにコードを書くことだ。誰も避けているから爆発半径が大きいチケットを引き受けろ、楽しいから面白いチケットを引き受けるのではなく。スタイル的にではなくアーキテクチャ的にレビューしろ。知識を移転するためにペアリングしろ、自分が役立つのを見るためではなく。
「コーディングをやめる」アドバイスも特定のチーム形状のためにチューニングされている — たいてい大きな組織で、レバレッジが人員密度、プロセス、委任チェーンにある。5〜15人のエンジニアで、特にスタートアップやモダナイゼーションプロジェクトで、それは間違った形状だ。プロセスを最適化しているのではなく、アーキテクチャの一貫性と速度を最適化している。技術的な信頼性はプレイングキャプテンにとってあったら良いものではない — それが全体の基盤だ。
プレイングキャプテンが間違った判断であるとき
プレイングキャプテンを長くやってきて、それが間違っているときを知っている。
80人のエンジニアを抱えて成長しているなら、プレイングキャプテンは複利で悪くなり始める。クロスファンクショナルな部屋にフルタイムでいる必要がある。コードレビューに費やした一時間は、技術的なものよりも速く複利する組織的問題への一時間でない。アーキテクチャビジョンを保持できる人々がいる — もっと多くの方向設定が必要かもしれない、ペアプログラミングセッションではなく。
また、不快なリーダーシップの部分を避けるために使っているときも間違いだ。パフォーマンスの会話を先延ばしにしていたとき、難しい技術的問題に手を伸ばすことが自分がその引き止めに手を伸ばしていたことに気づいたことがある。それはプレイングキャプテンではない。それはコードを慰めの毛布として使うことだ。キャプテンは依然として難しい対人関係の作業をしなければならない。コードは言い訳ではない。
正しく掴んでいること
プレイングキャプテンが正しく掴んでいるのはフィードバックループだ。コードベースにいるとき、チームがあなたに言う前にアーキテクチャが漂流しているときを知っている。どのエンジニアが多すぎる複雑さを頭の中で抱えているかを知っている。なぜならそのエンジニアが出しているPRを見てきたからだ。どちら側の抽象化にもいたから、サービス境界が間違っているときを知っている。
管理のみの技術的リーダーシップにはレイテンシ問題がある。会議、レトロ、（正しくも）すべての小さなことをあなたに持ってきたくない人々を通じてフィルタリングされた情報を得ている。何かが問題として表面化するとき、それは何週間も問題だった。
プレイングキャプテンはそのレイテンシを圧縮する。コードからのフィードバックはコードを読んでいるから速くあなたに届く。早期に軌道修正できる。つまり劇的に軌道修正する必要がない。
四社、三つの異なる技術スタック、4人から30人のチームサイズでこれを実践してきた。技術的リーダーシップのユニバーサルな理論ではない。私にとって機能してきた理論で、私が最も役立ったチームの形状だ。腕章には責任が伴う。ブーツは履いたままだ。