Googleが過去1年で小規模チームのマネージャー35%を排除！一体何が？
引用元：https://news.ycombinator.com/item?id=45045398
GoogleのTLM（Technical Lead/Manager）はコードも管理もやるハイブリッド職だったんだけど、専門職に分けるために廃止されたんだ。株価のための効率化って言われてるけど、実際はTLMだった人がプログラミングに100%集中するようになっただけみたいだね。
GOOGは3年前からTLM職をなくす動きを進めてるんだ。以前はICのTLMがEMになったり、過負荷のEMを助けるためにTLMが使われたりしてたみたい。TLMは「70% ICで70% EM」って感じだったって人もいるよ。今はTLMじゃなくて、シニアICがマネージャーの技術的責任の一部を担う形が多いみたいだね。
TLM職は個人的にはいつも罠だと思ってたんだ。50%コード、50%管理って言われるけど、話を聞くとみんな80%コード、80%管理って言うからね。絶対引き受けたくないな。
うちの会社にもTLMがあったけど、当たり外れが大きかったよ。TLMは専門知識をジュニアに伝える役割だったけど、ジュニアが成長しにくかったり、TLMが自分の領域にこもりきりになったりすることも。2022年以降に多くの会社でこの職がなくなったのは、無限の資金や人員増がなくなったからじゃないかな。
TLMは二つの仕事を同時にやる期待があるって意味じゃなく、エンジニアを管理職にスムーズに移行させるための罠なんだよ。管理がうまければチームは大きくなるし、気づけばフルタイムマネージャーになる。ずっとTLMでいる人は、管理が苦手、行き詰まったプロジェクト担当、あるいはエンジニアの過去にしがみつく人かのどれか。企業から見れば、どれも良くないから廃止が進んでるんだよね。
Googleはもっと典型的な「テクニカルリード」モデルに移行してるみたいだね。リードは権限やメンターの役割があるけど、実質はICで、マネージャーが本来の管理をするって感じ。TLMって役割は効率性に関わらず、あまり良い管理戦略とは思えないんだよね。
Principal EMからMid ICまでのGoogleの役割と給与のマッピング情報があるよ。TLMって言葉はlevels.fyiにはないけど、Technical Program ManagerとかTechnical Account Managerが似てるかもね。この変化って、優秀なソリューションアーキテクトが、管理職じゃないからって給与が制限されちゃうってこと？
[1] https://www.levels.fyi/companies/google/salaries/software-en…
https://www.levels.fyi/companies/google/salaries/software-en…
https://www.levels.fyi/companies/google/salaries/software-en…
TLMの元々の理念は、会社がMBAに牛耳られないよう、優秀なエンジニアをマネジメントチームに入れることだったんだ。でも、これってエンジニアの才能を無駄にしたり、マネージャーが事務作業に追われたり、人とのコミュニケーションが苦手なエンジニアがマネージャーになったりして裏目に出ることも多い。でも、マネジメントの大きな利点はレバレッジだよね。
こういう図や説明を見ると、MuskがTwitterの80%をクビにしてもプロダクトに目に見える影響がなかったのがよく分かるね。
マネジメントの大きな特権はレバレッジだけど、組織における力のレバーは人間関係、専門知識、そして役割の3つだ。役割の力はぶっちゃけ一番効かない。チームの賛同が得られないと何も進まないよ。高いレベルで信頼され、人間関係を築き、技術力のあるICは奇跡を起こせるんだ。俺も700人規模の会社で、CTOが最初は懐疑的だった大きなプロジェクトを、ビジョンと人間関係で説得して進めてる。俺はStaff Engineerだよ。BigTechでもL6やL7のICが同じやり方で大きなイニシアチブを推進してるのを見たね。
これって「経験豊かなベテランを排除して、俺が昇進できるようにしろ」って言ってるみたいだな。
くそ、Lundbergみたいに$1.3M/年なら喜んでやるね。ああ、$1.0Mでもたぶんやるよ — Bobたちも喜ぶだろうし！あと、10x Developersは100倍も過小評価されてるみたいだな！
なんで会社の成長パスって、マネジメント職にばかり偏ってるんだろ？ってずっと疑問に思ってたんだ。ICのままキャリアアップできるメリットは多いし、熟練したICが持つ機関知識は計り知れない価値がある。彼らがコードを長く見てるからこそ、どこが失敗するか、どこをいじればいいか知ってるんだ。でも、彼らを非技術職に異動させると、その知識は「腐る」。コードは進化し続けるのに、彼らの知識は止まったままになるからね。あなたの話を聞くと、その最悪のケースみたいだね。特定の側面に彼らの能力を過度に集中させるのは非効率的だよ。知識の伝達は長期的な成功に重要だけど、狭く適用されるだけじゃ意味ない。
「同時に2つの仕事をやる期待はない」って読んで、思わず声を出して笑っちゃったよ。ハイブリッドなテック／マネージャー職で、2つの仕事を求められてない奴なんて見たことないね。少なくとも彼らはそう感じてるし、それは同じ問題だ。80%コーディングと80%マネジメントが、その役割の現実ってところかな。
数年前の話だけど、PrincipalはDirector（L8）レベルに相当してたはずだよ。前の投稿者はL7層を見落としてるね、Engineering Manager LadderだとSenior Staff Engineering Managerだ。L8はEngineering Manager LadderのDirector、SWE LadderのPrincipalだ。Tech-Lead Managers（TL/MまたはTLMs）はSWE Ladderにいた。参考までに、SWE LadderはL8 Principal、L7 Senior Staff、L6 Staff、L5 Senior、L4 Software Engineer II、L3 Software Engineer（新卒はここから）。Engineering Manager LadderはL8 Director、L7 Staff Engineering Manager、L6 Engineering Manager（M1）、L5 Engineering Manager（M0 - これは通常、外部採用では存在せず、SWEがEM Ladderに移行する稀なケースだよ）。
俺のキャリアではずっと、多くの会社でこれは当てはまらなかったよ。ICとして昇進できるんだ。Staff、Senior Staff、Principalみたいな役職がある。StaffとSr. Managerは同じ給料だったりするんだ。
「役割の力はぶっちゃけ一番効かない」って？まあ、FAANGとか役員レベルならそうかもだけど、普通の会社じゃマネージャーって、もはや本当のマネージャーじゃなくてスーパーバイザーだよ。ティーンエイジャーの頃に閉店シフトの人員数を決める権限があった時の方が、$200k/年超えのSenior Managerの今よりよっぽど権限があったね。金の使い道を決められる役割は、それができない役割よりはるかに大きな力を持つに決まってるだろ。
何百、何千人もがソフトウェアプロダクト開発に携わってるのに、何年もプロダクトにほとんど進展がないっての、いつも本当に困惑するんだよ。Twitter/Xの例もあるし。時々、かなりの給料をもらってほとんど適当に働いてる奴らの話を読むと、日々死ぬほど難しい問題解決に励むいつものソフトウェアエンジニアたちと対照的だよね。若い頃は、ほとんどが女性のプロジェクトマネージャーたちがプログラマーを邪魔したり、フィードバックを伝えたり、おしゃべりや忙しそうにしてるだけだったのを覚えてるよ。サポート役とかウェルネス担当者とか、削減できる低価値な役職は山ほどあるはずだ。驚くのは、こういう価値の低い役職が高給をもらってたり、大したスキルも責任も説明責任もないのに高位にいることだ。とてつもない競争優位性やネットワーク効果で巨大なキャッシュフローを生み出すテック企業では、こういう人事の無駄が全部隠されてるんだろうね。巨大な機械が超儲かってるから、HRの無駄も大量に隠しきれるんだ。
技術と管理を兼務する役割はストレスが多すぎるから、廃止は良いことだと思うな。TLMが技術決定を左右するのは、評価に響くからチームメンバーは意見しづらいし、権力不均衡が問題だよ。
俺のキャリアではEMに報告したことないな。大企業に来て初めて、EMがコード書かないってことに驚いたよ。昔はTLMが専門家としてチームを率いてたんだ（フレッド・ブルックスの「外科医モデル」みたいにね）。EMの役割って会社のポリシーを強制するだけって感じだし、小規模なとこにはいらないかも。
Googleは非技術職、中間管理職、現場の専門家、シニアエンジニア、そして一般エンジニアも全部クビにして、最終的にGregって一人が「webmaster of google dot com」になってPHPで全部書き直したら、やっと本当の意味で成功するってことだよね？（皮肉）
大体そうだね。ただGregは実際にはGeminiで、経営陣の複雑で矛盾した指示にも24時間完璧に働くことを期待されてるってわけだ。
色んな規模の組織で働いてきたけど、企業が大きくなるとネットワーク効果の問題や官僚主義がひどいって実感するよ。Volvo CarsのEMは一年中会議だったって冗談を言ってたし、インドの同僚は親にキャリアの進捗を見せるため毎年昇進を求めてて、会社は役職名だけ増やして対応したんだって。組織構造のインフレだね、一つの問題解決が新たな官僚主義を生む。
35%削減って、部下が3人未満のマネージャーのことらしいね。0～2人って、さすがに非効率的じゃない？Googleってなんでそんなに部下が少ないマネージャーをたくさん抱えてたんだろう？残りの65%がその分の仕事を引き受けるのか、それとも彼らも少人数の部下を持つままなの？
小規模チームのマネージャーって、半分は管理、半分は実務に時間を使うのが普通だよね。これはマネージャーの能力を活かすにはいいけど、どっちも中途半端になるリスクもあるな。それに、パートタイムのマネージャーだと、チームをしっかり守る力がない場合も多い。だから、エンジニアだけの小さなチーム（ポッド）を作って、それを専任のマネージャーが管理する方がうまくいくと思うよ。
組織変更とか人員削減で、マネージャーの部下が変に少なくなることってあるよね。最初はちゃんと適正人数だったのに、時間と共に崩れていくんだよな。
IMO、0人管理は最高だよ。これ以上でも以下でもないポジションは受けたくないね。独立しててあまり管理しなくていいなら、1人管理くらいなら妥協してもいいかな。
きっとどこかの会社には、想像上の複雑な人々を管理するマネージャーがいるんだろうね。
0人管理は素晴らしいね。でも、0人以下を管理するポジションのオファーが来たら、質問攻めにするだろうね。
それって、一人以上の人を「undersee（監督の反対）」しなきゃいけないってこと？ジョークだよ。
もっとコメントを表示（1）
Individual Contributorなら0人管理は最高だよね。でもマネージャーの役割なのに管理する人がいないなら、その役割って無駄じゃないかな。
僕が始めた頃は、L5でマネージャーになるのが昇進の近道って言われたんだ。当時はどれくらい本当だったか分からないけど、この削減は、当時のそういう局所的な最適化の結果かもしれないね。今はL5でマネージャーになるのは、特例がない限り無理なんだっけ？
SearchとAdsでは、少なくとも僕が知る限り、L6がマネージャーの要件だったよ。収益にそこまで重要じゃない部署では、この要件が一時的に緩められた時期もあったみたいだけど、L6の制限自体はかなり昔からあったはず。
参考までに、僕は2つのPAでSWEラダーのL5マネージャーだったよ。L6要件はあったけど、僕の経験ではかなり緩かったね。VPに僕が仕事ができて、すぐにL6に昇進できるって納得させれば大丈夫だったんだ。
へぇ、興味深いね。僕がいた部署ではL6ルールの例外なんて一度も見たことなかったよ。
2人チームに専任マネージャーがいるんだ。マネージャーはコードも書かないし、技術的な知識もほとんどない。最悪だよ、助けて！
1〜3人って規模が最適なプロダクトもあるから、無理にチームを大きくするより、小さいままでいい場合もあるよ。他のコメントにもあるけど、TLMならマネージャーも技術貢献するはずなんだよね。
Google社員じゃないけど、こういうのって、将来的に部下が増えることを期待してマネージャーに昇進させる、楽観的な人事が原因だと思う。でも、結局部下は増えないか、人の入れ替わりが激しくて適正な管理範囲にならないんだよね。
記事には彼らがICに転換されたってあるから、TLMとかのポジションだったんだね。ヘッドラインはクリックベイトで、実際になくなったのは小規模チームってことみたいだ。
ある状況では、効率を犠牲に開発速度を上げる方法があるよ。チームでやるより個人で進める方が速い、本質的にシーケンシャルな大きなタスクの場合ね。並行可能なサブタスクにチームを投入し、リードが指示すれば皆が動く。こうすればソロプロジェクトより遅くならない。リードは楽しいけど、メンバーは大変。2012年のGoogleならできたけど、2025年のGoogleには無理なやり方かもね。
マネージャーがマネジメント業務しかしてなかったら非効率だけど、ほとんどのケースはそうじゃないと思うよ。
大きいチームから社員を引き抜いて、そのチームが0〜2人になるまでやるってこと。
3人未満のチームなんて、ほとんど意味ないよね。Googleが是正するのは正しいけど、そもそもそんな状況を許してたリーダーたちには疑問だわ。それに、本当に3人未満のチームなら35%削減じゃ少なすぎる。95%くらいなくすべきじゃない？
スタートアップでエンジニアチームは6人、俺は1人を管理してる。非効率な比率だけど、今はこれでうまくいってる。でも、成熟した大企業で0〜2人のマネージャーがいるのはおかしいと思うよ。
それって、コードも書く半人前の”マネージャー”って役割のことだよね。彼らはその役割をなくして、専門のピープルマネージャーと専門のエンジニアを配置する方針なんだ。
それって非効率的じゃない？どういうこと？
企業によっては、現場ワーカーが稼ぎ頭だよね。例えば宅配会社だと、ドライバーが収益を生む。マネージャーが多すぎると、給料はかかるけど現場仕事はしないから会社は傾く。でもGoogleみたいなとこにはこの分析は当てはまらないかも。広告は人間なしで公開できるし、ドライバーみたいな役割がいないから、比率も計算できないんじゃない？
マネージャーが他にどんな責任を持ってるかによるよね。もしやることが少なすぎると、小さなチームを過度に管理しちゃって、しょっちゅう仕事の進捗をチェックするようになる。それって非効率的だし、士気も下がる原因だよね。
会社でマネージャーが0〜2人しか見てないなら、それはもう「一人を一人、また一人、と管理する」って構図になっちゃうってことだよね。
10個のサービスがあるシステムを想像してごらん。各サービスには1〜3人が必要だとする。システム責任者は、10人のテックリードを置いてサービス全体の品質管理を任せるか、それとも20人以上の直属の部下を持つか。後者だと、上司に報告することが特にない部下が増えちゃうだけだよね。
大手テック企業が過度に肥大化してるのは、トップのリーダーシップが低品質で、部下がどこへ向かうべきか明確なビジョンを示せないからだと俺は確信してるね。もちろん簡単なことじゃない。でもAppleは今でもSteve Jobsの先見性でやっていけてるんだからさ。
これは2018年のGoogleに対する俺の意見だな。肥大化は少し改善されて、良くなった点もあるけど、CEOはまだオートパイロット状態だよ。
正直言って、オートパイロットのCEOって会社のリーダーシップとしては上位25%に入るんじゃないかな。CEOがあれこれ動き回っても、事態が悪くなるだけに見えるし。
質の高いリーダーシップって、そもそも本当に珍しいよな。
俺も同意だよ。もっと悪いことに、上層部や中間管理職は自分の利益ばかり考えてて、才能ある奴を見つけて育てる気がない無能ばかりってこと。ビジネススクールなんて、将来のビジネスリーダーを測るにはダメな指標だよ。これらの企業がどうしてこんなに肥大化したのか信じられないね。トップからの規律のない管理の代償だよ。
最近の幹部が従業員を見下すような物言いは、読んでてすごく気分が沈むね。俺がいた頃と比べると、本当に残念な文化の変化だよ。
俺は2013年から2017年までいたけど、その短期間でも最初から最後までかなり大きな変化があったよ。
Googleは2011年より前は、本当に働きやすくてクールな会社だったんだぜ。
それはGoogleの従業員が組合結成を試み始めたり、Googleが組合潰しの人たちを雇い始めた時期と、そう遠くないタイムラインだよな。
魚は頭から腐るんだよ。
もっとコメントを表示（2）
技術チームの現場マネージャーにとって、部下の数は5人くらいが適切だよ。10人になると全部を把握するのは無理。一日には限りがあるし、マネジメントには時間がかかるからね。10人以上の大きなチームなら、すごく独立してて意欲的な個人か、信頼できるラインマネージャーが必要になるよ。
部下10人じゃ無理って意見もあるけど、俺は逆で、マネージャー比率が高い方が良い経験をしてるよ。マネージャーが全部に関われないから、委任したり効率化せざるを得ないんだ。部下2～3人にマネージャー1人の会社は最悪だったね。会議や1対1の嵐で、マネージャーが自分の役割を正当化しようと、本で読んだような無駄な活動で俺たちの時間を埋め尽くしてたよ。
うん、俺もそう。部下が少なすぎると、そういう“マネージャー”は暇だから、くだらないことをでっち上げて、実際に仕事してる人たちをイライラさせ始めるんだよ。あるマネージャーは、俺が他のチームメンバーのパフォーマンス問題についてフィードバックしても、全く受け付けなかったな。『彼と話しておくよ』って言って、結局何もしない。俺はチームの誰よりも、その“マネージャー”よりも経験があったのにね。そいつはもういなくなったけど。
俺もまさに同じ経験があるよ。今、3人のチームにマネージャーが2人もいるんだ。1人は俺たちと全く関わりたがらないし、もう1人は1時間ごとの活動報告を求めてくるけど、多分一度も見てないんじゃないかな。
そういう比率なら、技術マネージャーは全てのコードレビューの最初にチェックして、あらゆるものを徹底的にテストして、IC（個別貢献者）の作業に入るずっと前に、設計レビューでバグを見つけるべきだよな。
部下が2人ならIC（Individual Contributor）としての仕事をする時間は十分あるよ。4～5人になると大変になってくるね。
それって面白い視点だね。今まで聞いたことなかったけど、すごく納得できる。ありがとう！
5人チームのマネージャーは、毎日30分のスタンドアップ、金曜の定例、週1回の1on1とか、無駄な仕事ばかりしてる印象だね。5人のチームにフルタイムのベビーシッターが必要ってことは、そのチームに大人なんていないってことだよ。
いや、5人くらいが理想的だよ。その人数でマイクロマネジメントしてるなら、マネージャーとしての他の側面を無視してるってこと。7人を超えると、チームが必要な時に対応できなくなったり、計画やプロセス業務をする時間がなくなるよ。
一つの小さなチームだけを監督してるなら、自分の経験とも一致するな。
だいたい5人くらいだと、マネージャーが自分の存在意義のために余計な仕事を作り出すことがよくあるんだよね。
10人以上の大規模チームだと、すごく自立したメンバーか信頼できるラインマネージャーが必要だね。自分が何年もいたAppleのハードウェアチームはまさにこれで、官僚主義や中間管理職のくだらない縄張り争いを防ぐために、できるだけフラットな組織が優先されてたよ。
面白いね！何人くらいのチームだったの？他に非公式な権力構造とかは出てこなかったの？
チームには20〜30人いたけど、みんな自分の担当分野を熟知してたから、ハードウェアや規制、業界標準の性質上、自己組織化して並行でうまく作業できたよ。これは人間の心理よりも問題領域に合ってたケースかもね。初期の頃、インド出身の人が、自分がワーカーじゃなくて、部下が欲しいってずっと不満を言ってたのが目立ってたよ。多様なメンバーがいたけどね。専門的な才能で採用された本当に多様なチームだった。
