大きなチームから社員を引き抜いて、チームが0-2人になるまでって感じ。

自分の経験から言うと、再編成や離職の補充を制限すると、こういう変な状態になることがあるよね。最初は合理的な数の部下を持ってたのに、時間が経つにつれて崩れていくことがある。

その規模のチームだと、マネージャーは人の管理に半分くらいの時間を使って、残りの半分はチームの仕事に直接関わってるって想像するよね。マネージャーにちょっとしたレバレッジを与えるのが目的ならいいけど、逆にマネージャーが特に何かをうまくやる時間がない可能性もある。あと、こういうパートタイムのラインマネージャーは、チームをしっかり見守るための組織的な権限が足りないことが多い。何回かその体制を試してみたけど、みんながエンジニアの小さなポッドを作って、全てのポッドが専任の人事マネージャーに報告する方がいいと思う。

Googleの社員じゃないけど、経験上これは通常、後で人員を増やす期待を持って誰かをマネージャーに昇進させる楽観的なプロモーションだと思う。でも、後でそれが実現することはなくて、離職と重なって、結局まともな管理範囲に達しないことが多い。

個人的には、0人を管理するのが最高だと思う。もっと多くても少なくても管理するポジションにはつかないつもりだけど、実際に独立しててあまり管理しなくていい人を1人だけ見るのは妥協できるかな。

3人未満？それはほとんど意味がないよね。Googleがそれを整理するのは正しいけど、そんなナンセンスが発展するのを許したリーダーたちにはたくさん質問があるよ。あと、35%は本当に3人未満なら低すぎる。95%のシナリオを排除するくらいが妥当だと思う。

ある状況では、効率を失う代わりに速度を得る効果的な方法になることもある。基本的に、大きなタスクはチームで開発しても個人より早くはならない（神話のような人月）から、根本的に直列的であって並列的ではない。こういう場合、並列のサブタスクがあることが多いから、1人がプロジェクトの唯一の存在のように先に進むことでスピードを得られる。そして、並列化できるサブタスクのためにチームを巻き込む。決定やコミュニケーションのオーバーヘッドを減らすために、チームリードが「ジャンプ」と言ったらみんなが飛ぶって感じで、これがパフォーマンスをソロプロジェクトより遅くさせないステップになる。こういう構造のチームリードは楽しいけど、チームメンバーでいるのはエゴに厳しいし、速度を上げるためにはものすごいスキルが必要だよね。だから、プロジェクトが直列フェーズのときはほとんど何もしていなくても、異常な報酬が必要になる。2012年のGoogleが利益を上げられたのは信じられるけど、2025年のGoogleは無理だと思う。

マネージャーが管理業務だけを持っていたら非効率的だけど、ほとんどのケースではそうじゃないと思う。

私が始めたとき、L5で昇進する簡単な方法の一つはマネージャーになることだと言われた。どれだけ真実だったかは分からないけど、こういう局所最適化の結果かもしれない。今は、グランドファザー制度がない限り、L5でマネージャーになることすら許可されてないんじゃないかな？

5人のマネージャーを見るたびに、毎日30分のスタンドアップ、金曜日の“まとめ”ミーティング、週1の1対1、その他のノンワーク関連の活動があるんだろうなって思う。5人のチームがフルタイムのベビーシッターを必要とするってことは、そのグループに大人がいないってことだよね。

10人に行くと、物事を把握するのが不可能になる。1日は限られた時間しかないし、管理には時間がかかる。実際、従業員とマネージャーの比率が高い方が、いい経験をしたことがある。マネージャーがすべてに関わることができないと、手放さざるを得なくなって、委任したり、管理の雑務を省いたりするから。最悪の経験は、2-3人の従業員に対して1人のマネージャーがいる会社で、さらに上のマネージャーも関わることが期待されてた時だった。会議の連続で、毎週1時間の1:1が何人もいて、目標設定や個人の成長のためのエクササイズ、そして増え続ける予定の気晴らしリストで、時間が埋まってしまった。マネージャーは自分の役割を正当化するために仕事を作る必要があると感じていて、結局、会議や活動が多くて、ポッドキャストや本で聞いたことをやってるだけのように思えた。

大きなチーム（10人以上）では、非常に独立していてやる気のある個人が必要か、信頼できるラインマネージャーが必要だよね。俺が数年間いたAppleの内部ハードウェアチームもそうだった。官僚主義や中間管理職の無駄を防ぐために、できるだけフラットな組織が優先されてた。

大体5時くらいになると、マネージャーが自分の存在意義を示すために、みんなに余計な仕事を作ることが多いんだよね。

TLM役割の成功や価値について、何か意見ある？

うちでも似たようなことやったけど、別の名前で呼んでた。ほんとにクソみたいなもので、こういう役割がもっと伝統的な形に戻るのも全然驚きじゃないね。

うちの会社でもこれやってたけど、結構当たり外れがあった。ほとんどの場合、'TLM'は長いことその役割にいて、2人目が必要だったから、結局1-2人のジュニアがそのTLMから知識を吸収する形になってた。成長している分野にいると、TLMがコードに関わっていればうまくいったけど、誰かが失敗すると会社にとっては悪いROIで、みんなにとってもひどい経験だった。ジュニアは昇進できず、狭い分野には1人の専門家しかいなかったからね。TLMは自分の小さな王国の中で5-10%の昇給を得ながら、リラックスしてたけど、ドメインがうまく機能するようにしてた。ジュニアが成長するにつれて、TLMはあまりコードを書かなくなったけど、彼らがいる限りジュニアは成長できなかった。2022年以降にこういう役割が消えたのは偶然じゃないと思う。無限のお金と大量の人員増加があれば、こういう役割は存在できて、良いけど特別じゃない人たちにキャリア成長の余地を与えられる。でも、人数が固定されていると、銀行がやってるように年に一度のカットをしないと、誰も昇進できないし、新しく雇えない。

TLMの役割は、なんか罠みたいに感じるんだよね。個人的には絶対にやりたくない。みんなが言うには、50%コード、50%管理って売り出されてるけど、実際に関わった人たちの話を聞くと、期待されるのは80%コード、80%管理って感じらしい。

TLMの役割は、テック業界で一番良くて一番悪い役割だと思う。良い点は、TLMがプロダクトの実行を完全にコントロールできること（PMを押しのけることもできる）。自分のビジョンがしっかりしてて、それを実現したいなら最高だね。悪い点は、チームが大きくなるにつれて、仕事量がすごく増えること。

Googleがもっと一般的な「テクニカルリード」モデルに移行してるみたいだね。リードはかなりの権限とメンターの責任を持ってるけど、基本的にはICで、ちゃんとした管理は他の人がやる感じ。非公式には、テックリードがあまり経験のない開発者を優しく叱ることもできるけど、誰かを本当に懲戒する必要がある場合は、リードがマネージャーに話さなきゃいけない。TLMは変な役割だと思う。大手テック企業には独自の文化があるのは理解できるけど、効率に関わらず、管理戦略としてはあまり良くないように思える。

Googleではないけど、今そんな役割についてて、本当に嫌だな。集中してコーディングする時間がほとんど取れない。常に何かをレビューしたり、修正を手伝ったり、ジュニアが扱えないライブサイトを管理したり、みんなが何をしているかのTPSレポートを更新したり、パワーポイントを作ったりしなきゃいけないから。これらのことが嫌いなのに、自分の（期待される）機能を実現するのがフラストレーションの元になってる。人を無視して中断されない時間を持とうとすると、他のことを放置してる気がして嫌だ。こんな混合役割でうまくやってるのは誰なんだろう…。

GOOGは約3年前から役割を排除する方向に進んでる。あの時、俺のマネージャーは4人の部下を持つスタッフレベルのIC TLMで、強制的にEMに転換された。ここ3年で見たTLMは、過負荷のEMを助けるためだけに使われてる。見てきたパターンはこんな感じだね：Principal EM |- Staff EM（7人の部下、プロジェクトA） |- Staff EM（8人の部下、プロジェクトB） |- Staff IC（プロジェクトA、B、C） |- Senior IC（プロジェクトA、B） |- Senior IC（プロジェクトC） |- Mid level IC（プロジェクトC） |- Mid level IC（プロジェクトC） もしかしたらプロジェクトCはPrincipal EMの下に再編成されたのか、あるいは単なる投機的なサイドプロジェクトかもしれない。でも、最後の3つは明らかに集まっていて、良いラインマネージャーのフィット感がないし、Principal EMは2人のミドルレベルICから切り離されてる感じ。プロジェクトCはちょっと孤立してて、プロジェクトAとBがEMの時間をほとんど占めてる。だから、Principal EMはプロジェクトCのSenior ICをTLMとして任命して、専任のEMができるまで待つことに。最終的にはTLMがEMに転換されるか、新しいEMが入るか、再編成があるか、って感じ。俺が見たローカルでの2回は、どちらも1年か2年後にICに戻って、役割が70% ICで70% EMみたいに感じたって言ってた。今はTLMの役割が存在しないから、PrincipalはMの技術的な責任をほとんど委譲して、プロジェクトCのほぼ完全なコントロールを与えるけど、正式な役割は与えないんだ。（俺がプロジェクトCのSenior ICだった。）（フォーマットのために編集。）

これ、もう10年以上続いてるんだ。

2013年から2017年までいたけど、その期間だけでもかなり大きな変化があったよ。

魚は頭から腐る。