谷歌高管称过去一年已裁撤35%的小团队管理者
谷歌上周向员工透露，该公司已裁撤超过三分之一的小团队管理者，此举是公司持续推进组织效率优化的举措之一。
小团队管理者，这在谷歌被称为 TLM 角色、技术负责人/经理。你需要编写代码并管理几名初级工程师。这是公司努力让经理和工程师各司其职，而不是混合角色的一部分。
记者获得的全员会议录音显示，人力资源分析与绩效副总裁布莱恩·韦尔表示：“与去年同期相比，我们目前管理层人数减少了35%，直接下属数量也相应缩减。这表明我们在该领域取得了显著进展。”
在会议上，员工就近期多轮裁员、自愿离职计划和重组后的工作保障、“内部壁垒”以及谷歌企业文化等问题向韦尔及其他高管提问。
韦尔表示，此举旨在削减官僚机构，提高公司运营效率。
“纵观整个管理层——包括经理、总监和副总裁——我们希望他们占员工总数的比例逐步降低。”
知情人士透露，35%的削减比例针对的是管理人数少于三人的管理者。该人士表示，其中许多管理者已转为个人贡献者身份留任公司，因涉及机密细节故要求匿名。
谷歌首席执行官桑达尔·皮查伊在会议中强调，公司“在规模扩张过程中必须提升效率，避免仅依靠增加人员解决所有问题”。
谷歌在2023年裁减了约6%的员工，此后各业务部门持续实施精简措施。去年加入公司的Alphabet首席财务官阿纳特·阿什克纳齐去年十月表示，将推动成本削减“更进一步”。谷歌自今年1月起向员工提供买断方案，同时放缓招聘步伐，要求员工以更少资源完成更多工作。
关于自愿离职计划，高管们在全体会议上透露，共有10个产品部门推出了该方案。今年该计划已面向美国本土员工的搜索、营销、硬件及人力资源团队开放。
谷歌首席人力资源官菲奥娜·西科尼在上周会议中表示，上述团队中约3%至5%的员工已接受离职补偿。
“该计划成效显著，”她补充道，“我认为可以持续推行。”
皮查伊表示，公司在听取员工意见后实施了自愿买断计划，员工们表示更倾向于这种方式而非全面裁员。
“实施自愿离职计划投入了大量工作，我很欣慰我们做到了，”皮查伊表示，“这赋予员工自主权，很高兴看到计划成效显著。”
“渴望职业间歇期”
西科尼指出，员工选择买断的主要动因之一是希望暂别职场。
“观察选择VEP的人群构成颇有意思，他们多是渴望职业间歇期的人士，有时是为了照顾家人，”她解释道。
CNBC此前报道称，裁员举措打击员工士气，因为公司在缩减规模的同时，却发布了惊人财报且股价飙升。Alphabet股价今年已上涨10%，此前2024年涨幅达36%，2023年涨幅高达58%。
在另一次全体会议上，员工询问谷歌是否会考虑实施类似Meta的“充电假”政策——员工入职满五年即可获得为期一个月的带薪休假。
谷歌福利高级总监亚历山德拉·麦迪逊回应称：“我们已提供多种休假制度，其中假期制度正是为此而设——让员工得以休息与充电。”
她表示公司不会推出带薪休假制度。
“我们确信现有福利方案极具竞争力，”麦迪逊强调。
Meta暂未回应置评请求。
其他高管随即加入比较两家公司福利的讨论。
“顺便说一句，Meta应该没有终身福利计划(VEP)，”西科尼指出。
皮查伊随即反问，引发观众笑声：“那我们是不是该把Meta的所有政策都照搬过来？还是只挑几项喜欢的政策采纳？”
他继续打趣道：“或许我该尝试用Meta的全部政策来管理公司。不，可能还是算了吧。”
谷歌将这个职位称为TLM(技术主管/经理)。你既要编写代码，又要管理几名资历较浅的工程师。
这是公司推行专业化分工的举措之一，旨在区分管理岗位与技术岗位，避免复合型角色。
表面上这是为提升效率而推动的改革(为股价考量)，实则只是调整了部分人员配置——现任TLM完全专注于编程工作。
谷歌约三年前启动系统性改革，逐步取消该职位。当时我的经理是拥有4名下属的资深IC级TLM，后被强制转为EM。
过去三年间，我仅见过TLM用于协助工作过载的EM。
常见模式如下：
或许项目C刚被重组至首席执行经理麾下，也可能是某个探索性副项目。但最后三个岗位明显形成孤岛，既缺乏合适的直属主管对接，首席执行经理也难以有效管理两名中层独立顾问。项目C如同孤岛般存在，而项目A和B则占据了执行经理绝大部分时间。
因此首席工程经理任命项目C的高级独立研究员担任临时项目经理，直至情况变化足以配备专职工程经理。最终该临时经理将转正为工程经理，或引入新工程经理，或进行重组等。
我曾两次目睹本地类似案例，双方均在一年左右回归独立研究员岗位，并表示该角色感觉70%是独立研究员，70%是工程经理。
如今TLM职位已不存在，主管会将项目经理的大部分技术职责授权给该人员，使其几乎完全掌控项目C，但不会授予正式头衔。(我曾担任过项目C的资深IC。)
(格式编辑)
> 当时我的M是拥有4名下属的员工级IC TLM，被强制转为EM。
我当然不质疑您的经历，但需说明这并非标准模式。L6(员工级)强制转岗的标准模式是拥有6或7名下属(具体数字记不清了)。
> 首席工程经理
恕我吹毛求疵，谷歌工程师晋升体系中并不存在“首席工程经理”职位，因此您所指层级尚不明确。
独立工程师晋升路径为：高级软件工程师(L6)- 首席软件工程师(L7)- 杰出软件工程师(L8) (L9)
工程经理晋升路径为：EM II(L6)- EM III(L7)- 总监(L8)- 高级总监(L9)
附注：希望我对EM II/III的级别划分无误。据我所知EM I应为L5，但实际中几乎不存在。
附注二：需注意的是，IC晋升通道允许的下属数量有限制(随级别递增)。
> 我当然不质疑您的经验，但需说明这并非标准模式。L6(高级工程师)强制转岗的标准模式是6或7名下属(具体记不清了)。
当报告数更多时，则强制进入EM轨道。
我认为L6阶段4次报告仍属合理(L7阶段最多可达19次！)。
> 我不想过于吹毛求疵，但谷歌工程师晋升阶梯中并不存在“首席EM”职位，因此你所指的具体级别尚不明确。
我指的是L7 EM——不知为何写成了Principal(可能因操作过快)，现在编辑已来不及。
>>当时我的主管是拥有4名下属的员工级IC TLM，被强制转为EM。
>我当然不质疑你的经历，但需说明这并非标准模式。L6(职员级)强制转任EM的标准模式是管理6或7名下属(具体数字记不清了)。
我认为你们表达的是同一件事。所谓“强制转任EM”，B-Con的意思是该人员被赋予了更多管理职责。
这里首席EM的称谓确实容易混淆。EM I难道不该向EM II汇报吗？Meta通常是M1→M2的汇报关系。
我认为谷歌的L5经理相当于EM1，这正是Facebook所称的M零层级。因此谷歌的L6经理(绝大多数一线经理)对应的是EM II。
等等，所以你们让独立承包商同时参与多个项目，还根据项目不同向不同经理汇报？这简直是噩梦。光是管理一个经理就够呛了…
在我公司这可是标准模式。纯粹的瀑布式开发，简直糟糕透顶
简直是混乱。不过这可是2025年的标准企业管理模式。
只要所有汇报都集中到同一位经理，且该经理能直接联系到具体执行人员，通常问题不大。
有人能解释这些缩写吗？
IC——具体执行人员，EM——工程经理，TLM——技术主管经理
EM = 工程经理 IC = 个人贡献者
您是否拥有角色/层级映射表[1]？例如：
首席工程经理 – 年薪130万美元/人 https://www.levels.fyi/companies/google/salaries/software-en…
高级经理 – 66.4万美元/年 https://www.levels.fyi/companies/google/salaries/software-en…
初级IC – 55.7万美元/年 https://www.levels.fyi/companies/google/salaries/software-en…
资深独立顾问 – 41万美元/年 https://www.levels.fyi/companies/google/salaries/software-en…
中级IC – 29万美元/年 https://www.levels.fyi/companies/google/salaries/software-en…
levels.fyi似乎未使用“技术主管”一词。存在“技术项目经理”和“技术客户经理”职位，听起来类似(指技术人员转型为全职非技术岗位)。而“产品经理”和“项目经理”等职位则似乎面向目前工作完全不涉及技术的人员。
这种变化是否意味着：那些从零开始成功设计并实施过众多复杂系统的顶尖解决方案架构师，其薪酬上限被设定，仅仅因为他们没有承担“要求团队成员整天填写TPS报告”这项重要工作？
[1] https://www.levels.fyi/companies/google/salaries/software-en…
TPM与TAM是完全不同的角色。TPM本质上是跨部门的项目/计划经理，“技术”二字意味着他们对技术层面有超越表层的理解，但通常不亲自编写代码。TAM则是销售部门的客户经理，专注于为客户提供技术支持或规划系统集成等工作。
“技术主管”并非固定职位或晋升阶梯，而是指实际承担的技术职责。你可能在小型项目中担任L4级别的TL，但在大型项目中即使达到L7级别也未必担任TL。这完全取决于具体情况。
本讨论的核心在于：有些团队由经理兼任项目事实上的TL，承担直接执行职责；而另一些团队中，经理专注管理事务，另设一名或多名独立的TL。
我曾在两种架构的团队工作过，无论在谷歌内外，TLM与EM模式能否奏效取决于诸多因素：管理者是谁、其管理风格、组织优先级、项目性质等等。
> 这项变革是否意味着：那些从零设计并成功实施过众多复杂系统的顶尖解决方案架构师，因未承担“督促同事整天填写TPS报告”这类重要工作，其薪酬封顶？
FAANG企业内部其实并不存在专职解决方案架构师。系统设计与实施本就是中高级软件工程师的职责范畴。我接触过的解决方案架构师都在销售部门，负责协助外部客户优化云服务使用。当然我的经验并非全面。
我猜他们指的是高级员工IC——也就是团队领导的领导。
见鬼，年薪130万美元的话我乐意当伦德伯格。哎，就算100万美元我大概也会干——鲍勃们肯定乐坏了！
听起来那些10倍开发者的薪资还被压了100倍呢！
虽然过去几年了，但据我所知，首席工程师相当于总监级别(L8)。
前文遗漏了L7层级，该层级在工程经理晋升体系中对应高级工程经理。
L8在工程经理体系中是总监，在软件工程师(SWE)体系中则是首席工程师。
技术主管(TL/M或TLM)原属SWE体系。
参考架构：
软件工程师晋升阶梯
L8 – 首席软件工程师
L7 – 高级资深软件工程师
L6 – 资深软件工程师
L5 – 高级软件工程师
L4 – 二级软件工程师
L3 – 软件工程师(应届生入职起点)
———————-
L2及以下级别仅在极少数情况下存在。
工程经理晋升阶梯
L8 – 总监
L7 – 工程经理
L6 – 工程经理(M1)
L5 – 工程经理(M0 – 该级别通常不适用于外部招聘，仅在极少数情况下用于软件工程师转入工程经理晋升阶梯)
问题之一在于大型企业拥有极其复杂的职位体系，问题之二在于它们彼此之间也存在显著差异。第三个问题是薪酬模式同样千差万别，第四个问题则是这些体系会随时间演变。
所有这些因素意味着个人面临着极端的信息不对称困境。
即便同时收到两家FAANG企业的录用通知，你可能也难以判断哪份offer更优。
是否有人曾将亚马逊、Meta、Alphabet等公司的职位名称进行映射对照，并在公开表格中整理出对应薪资区间？
顺便问下，是否有人拿到过FAANG公司泄露的(匿名化)雇佣合同副本？这样就能比较不同雇主的条款差异，并追踪其标准模板随时间的变化(我注意到这个话题在此处尚未得到应有的系统性讨论)。
考虑到开发者社区创造了开源文化，企业至今仍能将如此显而易见的信息相对保密实属意外(相较于莎拉·佩林和埃胡德·巴拉克的邮件泄露事件；-)。
谷歌与Meta/Facebook在核心软件工程师和工程经理晋升体系中，通常采用数值等效的层级划分。
这并非FAANG招聘与求职的真实写照。现实中存在极其频繁的跳槽现象，且各FAANG公司员工间存在紧密的人脉网络(还有levels.fyi和blind等平台)，因此我们对各公司的薪酬结构、雇佣协议、职级体系等了如指掌，并懂得如何进行横向比较。信息不对称现象其实很少，求职者与招聘方谈判时往往准备充分，远胜于小型企业。
> 顺便问下，有人拿到过FAANG的泄露版(匿名化)雇佣合同吗？这样就能比较不同雇主的条款差异，追踪标准模板随时间的变化。
若不存在此类资料，纯粹因其内容极其乏味。levels.fyi已涵盖所有必要信息(需注意：美国采用协议制而非雇佣合同，因实行随意雇佣原则)。
我职业生涯中已辗转多家FAANG+企业。
levels.fyi 网站有相关资料
补充更正：
L7 级对应高级工程经理(M2)
L6 级对应工程经理(M1)
其职级与软件工程师体系的L6/L7头衔等同
资深工程师与高级工程师有何区别？
高级工程师通常专注于单一项目并具备深度技术造诣，在过程中指导并培养更初级的工程师。
资深工程师则通常统筹多个项目，为这些项目提供深度技术监督与指导，并培养高级工程师。他们开始影响技术文化，积极确保团队构建的技术方案满足业务需求。
高级资深工程师负责管理产品功能模块及多名资深工程师。他们构建正确的技术文化，确保重大架构问题得到解决，积极参与技术工作与业务需求的匹配，并主动发掘技术团队可满足的业务需求并推动实现。
首席工程师通常为整个大型产品定调，确保高级工程师团队正确行事，并常参与推动战略性产品方向。
高级工程师与首席工程师往往更具政治性，但普通工程师也常被卷入此类事务。
我认为技术主管(TLM)在此层级属于独立贡献者(IC)。
TPM、TAM和PM与此无关。技术主管通常是面向IC或TLM的半正式角色，意味着其负责领导包含其他成员的项目。中级、高级或资深IC都可能担任不同规模项目的技术主管。
> 这是否意味着最优秀的解决方案架构师——那些从零设计并成功实施过众多复杂系统的人——因未承担“监督团队填写TPS报告”这类重要工作，其薪酬封顶？
并非如此。
每次看到这类图表和解释，都让我更理解马斯克为何能裁掉80%的推特员工却不影响产品。
我始终困惑于：当数百至上千人投入软件产品开发时，为何产品数年间几乎毫无进展？明明存在大量(在我看来)显而易见的改进空间，却只发布些微小的bug修复，且更新周期极其缓慢。此刻我又想起推特/X平台的案例。
偶尔会读到一些故事，讲述人们如何靠着轻松的工作就能获得相当可观的薪水。这与我认识的普通软件工程师截然不同——他们日复一日地拼命解决棘手难题。
年轻时我记得很多项目经理(当时我身边几乎清一色是女性)，她们的工作主要是四处打扰程序员，传递反馈和进度，还伴随着大量闲聊和琐碎事务。企业里往往存在大量支持岗位——健康管理专员之类的职位，这些很可能被精简。真正令我震惊的是，许多低附加值岗位竟享有高资历待遇，薪酬丰厚却几乎不需要真本事，对任何具体事务的责任或问责都微乎其微。我怀疑在科技公司里，由于其现金流与员工数量的关联度远低于非科技企业，这类现象反而被掩盖了。一台凭借巨大竞争优势/网络效应而盈利丰厚的庞大机器，足以掩盖海量的人力资源浪费。
> 我目睹数百至上千人投入软件产品开发，数年间产品却毫无进展，而诸多(在我看来)显而易见的改进空间始终未被触及
我曾任职于约60名工程师共同开发同一产品的团队，为保持理智不得不主动_不_修复小问题。每次发现小问题时，我需经历：
若涉及用户可见变更，需与UX或PM讨论(极其烦人)
修复问题(通常是简单部分)
创建PR并说明问题
请其他超负荷团队成员审阅(若来自本团队尚可接受)
收到针对琐碎细节的评论(取决于修改内容)
被要求重构相关功能——因临时方案导致修复效果不佳，或需解决根本问题(通常耗时巨大)
可能经历多轮代码审查
每次有人修改该代码模块时，总有人会破坏我的修复成果
所有这些努力都是为完成非我职责范围的工作——我的经理很可能不会注意到这些，除非我主动汇报；而即便我汇报了，经理也可能以“这是其他团队的问题”为由让我别浪费时间。
所以我通常会选择忽略问题，或者创建一张大概率会被忽略的工单。只有当改动极其简单且毫无争议时，我才会主动处理。
谢谢。这解释了安卓系统的现状。因为唯一的其他解释就是谷歌开发者根本没人日常用安卓手机，毕竟它有太多令人抓狂的蠢设计。
例如：为什么我最常连接、距离最近的厨房蓝牙设备，总会沉到蓝牙列表最底层？这意味着我无法在快捷界面选择它，必须解锁手机再切换界面(而此时双手沾满厨房油污)。我最常在淋浴和厨房使用蓝牙媒体功能，常用设备理应排在前两位，但系统永远不会这么做。安卓系统里所有功能都透着“开发者根本没实际使用过”的疏离感。我至今无法用语音启动计时器——只要在手机复述计时信息时触碰屏幕，计时界面就会消失。毁掉太多食物后，我已学会不再信任这个功能。这两项正是我手机最常用的功能，也是它为生活增添价值的领域，但在安卓系统里却毫无必要地令人恼火，让我厌恶这个平台——毕竟到了2025年，这些细节本该完善。谷歌总该有人需要用计时器做饭吧？总该有人听音乐/有声书，设备多到需要用到第二屏幕吧？感觉安卓开发者对现实世界毫无关怀之心，否则这些日常痛点早就被曝光了。
看你用安卓，我加注谷歌智能音箱。求解：为什么用蓝牙连接这些音箱如此痛苦？为什么不能当电视音频输出？延迟难道是人为限制？我买它们时以为是带助手功能的蓝牙音箱，还能流媒体播放。结果根本不是。哪个变态的产品经理设计的？
许多大型组织_出于合理意图却不经意间_构建出严重倾向于不作为的结构。
当公司考虑采购新SaaS产品时，法务团队审查合同是合理的。
若合同条款存在无法批准的内容，法务要求修改条款也合情合理。
在要求员工启用产品前，对其隐私合规性进行审查同样合情合理。
在采用新产品前征询信息安全团队的意见是合理的，我们不希望存在安全隐患的产品悄然渗入。
要求供应商提供单点登录功能是合理的，这有利于提升安全性。同时我们尽可能要求供应商符合SOC2标准，因为我们自身也在努力达到该标准。
供应商在财务数据库中留存记录是合理的，这样我们既能完成付款，又能追溯款项流向。
在批准供应商前要求其声明供应链中未使用奴工是合理的。
每笔支出都应归属于企业内部的具体项目或部门是合理的。
项目或部门预算需设负责人，重大支出须经其批准。
上述工作合理地分配给多个团队，每个团队都有待办事项队列，非紧急请求可能需要一两周处理。
但当这些合理政策叠加时，采用一款新SaaS产品竟需耗时3-6个月——这使得继续忍受低效昂贵的供应商，远比批准新供应商容易得多。
> 反观我认识的普通软件工程师，他们日复一日疯狂地解决棘手难题。
显然你认识的某些人…要么效率低下要么缺乏智慧，除非他们真心享受这种生活。刻苦工作自有其价值，但若将其作为长期默认模式，余生注定凄惨不堪，这绝非现实可避免的结局。
这等于没能管理好人生最关键的方面。若还被冷血巨头雇佣，或是投身当下那些常无道德底线的FAANG公司，更是惨不忍睹(除非目标是几年内攒够钱转战更理智的人生阶段，但即便精心规划也鲜有成功者——毕竟房贷和孩子总会找上门)。
有人为工作而活，更多人则为活出精彩而工作。
除非遭遇极端故障？他们可靠性曾一度崩溃。所幸半数用户和广告商也离场，负载大幅降低
此外他们大幅削减API接口，部分后端及广告商专属功能消失，最关键的是：我们永远无法知晓本该实现的创新。
但很少有公司能像马斯克那样持续推行变革而不流失所有经验丰富的员工和系统知识。这不过是牺牲长期收益换取短期利益。人们之所以忍受，只是因为他们认为能借此提升声望。
产品怎么可能不受影响？收购后'X'究竟上线过什么？
他唯一证明的就是：现有业务用20%的人手也能维持运转。
更甚者，大量功能被彻底删除，对讨论质量的影响…堪称灾难性。
TLM职位在我听来始终像个陷阱，我个人绝不会接受。官方宣传是50%编程+50%管理，但接触过该职位的人都表示实际要求更像是80%编程+80%管理。
TLM职位确实是陷阱，但并非指同时承担双重职责。
这不过是诱使毫无防备的工程师踏入管理层的手段。只要管理能力稍具水准，团队规模必然扩张(或被分配管理其他团队)，转眼间便沦为全职管理者。
这意味着长期担任TLM的人分为三类：管理能力欠佳者；管理着死胡同项目和死胡同团队者；或是死守工程过去、拒绝扩编团队者。从企业角度看，这三种情况都不理想，因此近期业界对TLM角色产生了抵触情绪。
> 没人指望你同时做好两份工作.
读到这句我笑出声来。我从未见过任何公司里的技术/管理双重角色员工，不被要求同时承担双重职责。至少他们_感觉_是这样，本质问题依然存在。
该岗位80%编程+80%管理的分配比例听起来相当合理。
80/80确实接近现实。
另一种解释是：即便没有压力要求，这些人的初衷就是做开发，且很可能因热爱工作而获得认可。
因此当被要求在开发与管理间分配时，除少数例外，他们会主动选择80%的技术工作。但管理职责自然不会消失，故实际至少占50%(若追求薪酬则达80%，因这是实际考核重点)
管理需要对项目全局保持鸟瞰视野，快速响应问题并向上汇报(主动管理利益相关方)。管理者的职责在于让高管层满意(传递信息/管理预期)，同时保护团队免受干扰，使其能专注完成工作(隔离)。
编程则需要相反的特质：深入代码细节并保持专注。独立开发者的职责是交付(设计并实现)既美观又实用的架构，确保功能精准落地。
我建议任何人都应拒绝将这两种角色合并的职位。需注意这并非工作量问题，而是本质矛盾(两种角色的理想人选甚至匹配不同性格特征…)
这在我公司的EM岗位上确实如此。他们承担着相当重的技术工作，同时拥有完整的经理职责。老实说，我一直以为EM就是这样的角色。
我在多家公司担任过工程师、技术主管和管理层职位。就产出而言，技术主管的标准远低于同级别全职工程师，这是事实。只有当其管理能力受到严重质疑时，才会对其工程贡献进行评估。
任何岗位都存在过度拼命却无人制止的情况，但这是个人选择。
多数人每周工作40至50小时，某些公司甚至达到60小时的极端水平。
若要准确描述，你指的是160%即1.6倍工作量，相当于每周64至80小时，而96小时才是极端情况？
我的意思是，每周64-80小时本就是预期标准，只是几乎没人能达到这个预期。
据我所知，我以前共事过一位技术经理，每周至少要工作60小时。这真的很糟糕。
我在两家大型企业担任过技术主管，经验表明根本不存在同时承担双重职责的预期——我的工作重心几乎都在管理层面，实际编码工作极少。更多是与初级员工频繁进行结对编程、代码审查等。我最后一位经理入职时就明确告知：完全不要求你参与任何实际编码工作，首要任务是确保团队高效运转并保持正确方向。
> 若管理能力不差，团队必然会壮大
必然？凭什么必然？
> 管理能力差的人
若高层能意识到不该给下属增加人手，为何不能意识到该裁减现有下属？
> 那些管理着死胡同项目和死胡同团队的人
若“死胡同”仅指“不成长”，这倒无可厚非。企业开展数千项业务时，只需其中一小部分实现增长即可。
> 那些死守工程历史、拒绝扩编的人
用“死守”形容人坚持自己喜欢的工作未免太夸张。况且若他们是TLM(技术领导者)，这并非过去式而是_当下_。渴望保住_现有_职位再正常不过。
最终目标是让扩编团队里没有TLM吗？既然要挑选新TLM接替被提拔的管理者，为何不能保留原有TLM并另设上级？
听着，我只是描述现实；你似乎期待我为这种现状辩护。但简单说：
> 为何必然如此？
因为经验丰富且高效的管理者永远供不应求，所以招聘新人或现有管理者离职时，他们就是默认选择。
况且多数人希望随着时间推移获得更高收入。而在管理轨道上，这意味着要谋求未来的总监/副总裁职位——即便这并非你儿时的梦想。
> 若高层管理能想出不增加下属的方法，为何不能想出清除现有下属的办法？
他们可以，但在大型和/或成长型企业中，绩效问题往往得不到应有的重视。这把双刃剑：放任问题固然错误，但残酷的绩效管理同样会引发员工不满。
通常意味着你需要管理下属，却无法真正影响他们的职业发展轨迹。最糟糕的是，当需要解雇某人时，你却无权执行。
这正是我担任TLM(技术领导经理)时的经历——你必须管理下属工程师，却几乎没有横向或向上决策权。本质上你只是传达上级对团队的决策，同时还要承担高级工程师的所有额外职责。
在大型FAANG式企业里，我认为那些没有“TL-”头衔的中层管理者，根本不具备你所说的这种影响力或话语权。这种情况在VP级别会有所改变，但归根结底，大多数企业管理层级不过是电子表格的苦役罢了。
这叫临时工头。
就像“临时工头说：天哪，你居然搬了16吨…”
我发现TLM制度对下属反而有害。他们无需同时证明自己作为工程师和管理者的晋升价值，因此多数人只专注优化自身技术晋升路径，管理职责纯属出于善意。
如此自私的人不该管理他人。
作为辩护方(我既不在谷歌任职也不从事类似工作)，但若技术经理与工程师的晋升要求相似，而前者必须承担管理职责，这不过是制度使然。这种情况下，我认为谴责制度比谴责个人更合理，谷歌最终也因某些原因决定取消该职位。
这基本符合我在TLM岗位的经历。身为资深/首席工程师，团队仍期待你的产出。但你同时肩负着管理团队影响力和成果的职责。
影响力与成果远比产出重要，因此你投入大量时间在此实属合理。但绩效评估时，你仍受制于产出的硬性指标。
几点思考：
(1) 作为工程师，我更希望由真正了解我工作内容的人管理指导，最好是比我更精通该领域的人。
(2) 真正理解技术的管理者往往更能为团队扫除障碍。
(3) 随着年龄增长，高级独立工程师岗位机会日益稀缺，技术领导管理(TLM)路径对部分人而言或许是可行选择。
若不要求TLM承担超出个人成长需求的独立产出，这种角色能否成立？
当你成为足够优秀的IC时，“作为工程师，我更希望由真正了解我工作内容的人管理指导，最好比我更了解”这种诉求便不再合理。此时管理者的职责是通过安排合适的岗位/项目，最大化你的影响力。
作为管理着比我更精通本职工作的团队，我的目标是协助并确保他们处于最适合的位置(对个人和组织都如此)。若雇佣知识水平低于我的下属，那才是愚蠢之举。
不明白你为何从“技术人员管理技术人员”的观点跳跃到“雇佣知识不如我的下属”，这并非我的本意。此外“作为工程师”只是修辞——我本人是管理者，距我担任工程师已逾十五年。我理解你的观点。我依然认为中层技术人员直接上级的管理者，应当具备所开发系统的实践操作能力。至于更高层级管理者，掌握工程基础知识和过往技术经验即可。
GP指出：职业生涯初期，你的上司必须比你更精通技术工作；但到了某个节点(通常较早)，这种关系会逆转——领导者不可避免地会比你更不了解具体技术工作，因为你是团队中该领域的专家。当领导3-5名初级/新开发人员时，他们不可能比所有5-8名下属都更了解技术细节。
在帖子1中，你希望主管最好掌握更多知识；有人指出这不现实；而在帖子2中，你声称不理解对方观点，却将目标转移到“具备一定实践知识”——这恰恰表明你其实心知肚明。
控制机制能防止资深IC在走廊闲逛找麻烦。
TLM(技术领导)没问题，TPM(技术项目经理)才尴尬。我不明白TPM之间存在什么层级关系(如果有的话)，他们总在四处游走指派任务。有些项目像烫手山芋般在不同TPM间辗转。有能力的TPM会留下来推动项目，但即便如此我也不明白他们如何运作——毕竟他们领导团队却没有实际下属。
这正是TPM的职责所在。他们本应作为中立第三方确保工作推进，并能向上级解释工作延误的原因。因此他们对“工作内容”或“工期长短”没有任何决策权。通常由经理和项目执行者就工作内容与进度反复协商，根据项目实际情况设定截止期限，而项目经理则负责监督双方履行承诺。
TPM岗位存在的很大原因，就是让你的经理能成为支持者而非唠叨者。唠叨的工作被转嫁给TPM，但TPM没有决策权，因此不会出现扭曲的激励机制——经理既不会耗尽人情资本逼你工作，也不会故意拖延截止日期来推卸责任。
在许多组织中，TPM还负责策划趣味活动或分发设备/礼品等福利，以此抵消其本质上扮演催促者角色所引发的负面情绪。
但团队里其他管理者都担任TLM角色吗？
我预见的问题是：一旦召开升级会议，所有非技术管理者就会坐享其成，把矛头指向TLM直到他们离职。
听起来谷歌正转向更典型的“技术主管”模式：主管拥有实质性决策权和部分指导职责，但本质上仍是执行层员工，实际管理由上级负责人承担。非正式场合下技术主管可温和批评资历较浅的开发者，但若需正式处分则必须通过主管向经理汇报。
TLM是个奇怪的角色。我理解大型科技公司有其独特文化，但无论效率如何，这种管理策略确实显得欠妥。
最初的理念是避免公司被MBA主导，因此希望通过吸纳优秀工程师来构建管理团队。
当然这种做法可能适得其反：既浪费工程人才，随着组织扩张，管理者又将更多精力耗费在文书工作而非创造性劳动上。更何况不乏那些不擅长阅读、沟通和管理人才的工程师。
但管理的核心价值在于杠杆效应。若你具备技术实力和公信力，且有明确目标，团队自然会追随你的方向。若你只是个身居IC职位的“点子王”，这种效果就难以保证。
> 管理职位的最大优势在于影响力。若你技术精湛且值得信赖，当你推动某项工作时，团队自然会认同你的观点。但若你只是个身居IC职位的“点子王”，这种效果就难以保证。
组织中存在三种权力杠杆——关系、专业知识和职位。其中职位权力效力最低。若团队不认同你的想法，或认为你是蠢货，你将寸步难行。
一位在团队内外建立良好关系、技术实力雄厚的高级信任型IC，能创造奇迹。
在我现任职的700人公司，我正推动一项重大计划——从管理层到CTO最初都持怀疑态度，但通过阐明愿景并建立人际关系，我最终赢得了支持。
我只是个普通工程师。
即便在科技巨头，我也见过L6和L7级别的IC用同样方式推动重大项目。
> 职位权力远非最有效的手段。
坦白说：听起来不错，但我认为并非如此。真正的权力在于“谁决定我的晋升”、“谁为团队争取资源”、‘谁审批我的开支’、“谁在出错时保护我”等等。
这并非为管理者开脱——若其主张有问题仍需承担责任。但当管理者具备公信力时，这种权力就是_巨大_优势。细微分歧自然消弭，团队会凝聚在你的愿景下，为之振奋并推动落地。
反观个人贡献者角色，即便能成功推动项目，始终要对抗这种动态。无论想法多么优秀，团队成员可能单纯觉得你在把他们推向更难获得晋升或认可的方向——这需要额外努力才能克服。
获得某位副总裁的公开背书固然有益，但这本质上是借用高管的影响力而非自身实力。这种做法存在弊端——我曾与多位架构师/超级团队负责人共事，他们普遍遭人厌恶和畏惧。人们认为他们出现的目的就是增加你的工作负担，却对实际成果贡献甚微。
> 获得某位副总裁的公开背书确实有帮助，但本质上是在借用高管的影响力——这不过是个人贡献者影响力的幻象。
这当然是常规操作。即便是资深经理人，若得不到上级支持也难以推动重大项目。在初创公司任职时，第一家公司的总监和第二家公司的CTO都认同我的构想，并授权我调配所需资源推进项目。
跳过大型科技公司阶段，来到现在的岗位——一家第三方AWS咨询公司。在向决策层论证市场价值后，我成功将该项目升级为公司年度重点计划之一。
但在大型科技公司里，晋升并非完全取决于你的经理。至少在AWS，你需要获得一到两位上级主管的推荐，且必须经过委员会审核。
我曾指导过两位L4员工，他们从实习生时期到正式入职后都抱怨晋升流程——尽管他们的经理都支持他们。
> 第二家公司的CTO认可了我的方案，并授权我调配所需资源推进项目。
但这意味着权力掌握在他人手中而非你。若没有这种正式权力结构，你根本不会费心说服这些决策者——正是这种权力机制迫使所有人(包括你)不断尝试周旋与配合。
所以若你身居高位，做事就容易得多——设想那是你，现在无需说服他人，直接执行即可。
任何规模的群体都存在权力结构。企业可选择其正式程度，但无法规避。
试想：与其说服总监、副总裁或首席技术官支持你的好点子，不如说服700人中的100人支持它——而与此同时，这100人正听着其他99位非你人士提出的动听方案。
我宁愿在前者而非后者中工作。
同时运用这三种权力最为有效。
呃，或许在FAANG巨头或高管层是这样，但在非巨头企业中，你可能不会注意到角色权力——因为多数带“经理”头衔的职位早已沦为监督者而非实际管理者。
我十几岁时决定夜班人数时，对资金配置的掌控力，远超如今年薪20万的高级经理。
任何能决定资金流向的职位，其权力都远超无此权限的职位。
这篇文章主要讨论基层管理者。我从未遇过哪个“经理”能真正掌控超过3-4%的加薪幅度，或对预算有实质控制权。
当我作为战略人才加入初创公司时——面试官是总监或CTO——我特意询问是否直接向他们汇报。我曾拒绝一份工作，因为发现公司对我的期望与我在汇报体系中的层级存在严重不匹配。
>本文主要讨论基层管理者
或许在FAANG公司如此。但在我2019年至今任职过的所有企业中，凡是职位名称含“总监”及以下层级的管理者，都必须具备决策权。
若你无法自主决定资金配置方向，必须获得上级批准，那你根本算不上管理者。
读到此处的管理者请自问：
“若我认定明日招聘{X}岗位能提升公司效益，能否未经许可直接发布招聘需求？”
若答案是否定的，你不过是个监督者——其决策权甚至不及2010年沃尔玛熟食区主管。
我认为这种职权分界的通用术语应是“总监”而非“经理”。
总监负责决策(包括无需上级批准即可开启招聘流程)。
经理负责管理(不包括未经审核的职位开放)。
在高效运转的企业中，两者都发挥着重要作用。
若无决策权，便谈不上管理。现代“经理”不过是监督者，负责确保总监或高管的计划按部就班推进。若需资金或增员来重回正轨，决策权仍归总监或高管所有。
我并非戏言——这些职位的决策权甚至不如沃尔玛熟食部主管。在那个职位上，我对工作方式的发言权，比在任何软件公司担任“经理”头衔时都要大。
我待过这样的公司：“高管”们任何决策都需CEO批准。即便声称“有预算”，仍需最终签字。
职衔虚高现象比比皆是，尤其在小型企业中。
据我观察，谷歌多数团队负责人在此次调整前就未设下属。技术人员担任管理层在谷歌向来常见，反倒觉得这种模式在谷歌之外并不普遍。
确实，这有助于厘清事件本质。最初看到标题时，以为是突如其来的裁员，但若本质上只是谷歌将TLM岗位调整为TL，倒也合乎逻辑。
我们公司也尝试过这种模式，效果参差不齐。几乎每次担任“TLM”的都是资历深厚的资深员工，这种角色需要有人接替，结果往往变成1-2名初级员工跟班学习，吸收TLM的经验。
若在快速发展的领域，且TLM持续参与代码维护，这种模式效果极佳；但一旦出现上述情况中的任何一种，对公司而言就是糟糕的投资回报率，对所有人来说更是痛苦的经历。初级员工永远无法晋升，因为这个小领域只容得下1位专家。TLM只需安稳守着自己的小王国，每年拿5-10%的加薪，确保领域运转良好即可。
随着下属能力提升，TLM编码量减少，但只要他们存在，下属就无法成长——因为这个利基领域根本不需要太多人。
我认为2022年后众多公司取消这类职位绝非偶然。当资金无限且人员规模激增时，这类职位才能存在，为能力优秀但未达顶尖的人才提供职业发展空间。当人员规模趋于稳定时，企业就必须效仿银行的做法——实施年度裁员，否则既无法晋升也无法招聘。
我虽不愿如此断言，但必须指出TLM角色仅适用于企业生命周期的特定阶段，许多采用该模式的公司(包括2010年后的谷歌本身)早已超越了这个阶段。
依我之见，TLM角色适用的条件是：
1.) 公司处于增长阶段，仍需在竞争激烈的市场中抢占份额，即快速准确执行至关重要。
2.) 技术项目需存在显著不确定性。TLM应主导软件架构设计，而非将团队工作塞进现有架构。
3.) 工程师与业务目标最终负责人之间管理层级不超过3级，每位管理者直接管理人数不超过6人。擅长数学者会注意到，这将组织规模上限设定为6^3=216人——或许并非巧合，这个数字与邓巴数相差无几。
4.) 技术主管需精心遴选以促进团队协作。他们应以服务型领导者自居，为团队成员厘清工程目标，而非以攀爬职场阶梯为目的的命令者。
若缺乏这些特质，将导致：a.) TLM结构的反馈优势无法充分发挥；b.) 团队外部管理者的干预过多，使TLM难以履行管理职责。但若满足这些条件，我认为TLM团队是快速高效开发软件的唯一途径。
或许并非巧合，这些条件通常与大多数初创企业的成长阶段相吻合——而这个阶段正是创造核心价值的关键时期。
恕我冒昧，请问贵团队规模为何扩大？是业务范围扩展了吗？
您应是指我之前的评论，因本文未提及团队规模。
我本想说“因为我管理得当”， 但真实原因在于：资金允许增员，上级管理层成功展示了我们的价值并夸大了需求，最终说服副总裁批准增员；而我的直属经理实在分身乏术，无法在不增设管理层的情况下与所有新成员进行一对一沟通。换作是其他经理也会如此。事实上，我加入团队时_并非_管理者，但因对管理感兴趣且资历足够推动部门政策，最终在成为管理者后半年内将团队规模扩大了一倍多。此后头一两年团队确实很忙——毕竟我们当时是通过论证团队对重大战略计划至关重要才争取到这些编制的——但之后很长一段时间里，团队规模始终超出实际需求约两倍，于是我放任大家每周只工作20小时，敷衍了事地应付日常，直到下一个大项目到来。
在企业界待得越久，我越确信成功之道在于：满足最低资质要求，满嘴胡扯，对那些靠吹牛创造机会的人说“好”，并只做最低限度的活儿以避免被揭穿。企业招聘并非因实际需要工作，而是因为手握资金——资金等于编制，而编制是管理者晋升或充实简历的唯一途径。
我曾放弃过类似机会，坚持保持团队精简。那是在疫情期间，人员流动本就频繁。你描述的情况基本准确。我的经验是，拥有能力出众的团队对创造扩张机会至关重要。
这读起来像是“赶走老员工好让我升职”。
除非你心怀偏见。不过谷歌找到了更优解：让资深员工回归独立项目负责人角色，将年轻人才重新分配到能成长的岗位，并为不愿留任者提供买断方案。
我确实心怀偏见。所谓“更优解”指什么？在我看来，大企业这类举措无非是操纵股价和巩固控制权的手段。
若职位缺乏晋升空间，初级员工会跳槽，甚至转投其他公司。待他们积累经验后，你投入的培训成本将付诸东流。
若职位缺乏决策权，资深员工也会离职，甚至转投其他公司。你为他们付出的心血终将白费。
我不明白为何你认为这是非此即彼的局面。即便不是初级员工，你依然需要管理者。
从统计角度看，你应该向公司收费。即便获得晋升，你的收入仍会低于同级别新聘员工。即使你喜欢这家公司，“回旋镖式跳槽”才是上策。
用统计数据指导个人决策很棘手。普遍规律未必适用于特定群体。我认识许多转职后境况恶化的人。
若处境糟糕就该离开，但若真心喜欢公司和岗位，切勿掉以轻心，务必深思熟虑。
这条建议与宏观统计规律一致——当样本中超过半数人处于“糟糕处境”时。
既然讨论的是科技巨头，我初步推测任何技术人员(包括高级职员)或基层管理者留在这些公司，除了追求现金和限制性股票单位(RSUs)带来的收入最大化外，别无他因。
难道有人能在同一家公司里，在同一岗位/团队待上两三年以上吗？
美军军官晋升体系恰恰采用这种机制。实际上，美军各兵种对士兵的晋升也基本如此——刻意维持高淘汰率以实现频繁晋升。
在编制固定的前提下，若不通过人员流动或允许员工定期降职，就无法实现频繁晋升。
这让我想到一个常思索的问题：为何企业职业发展路径如此偏向管理岗位？
答案显然在于管理者掌握着晋升阶梯的定义权，但这未必能完全解释现象。当技术岗位人员转任管理岗位时，难道他们不该意识到保留技术晋升通道的诸多优势？机构知识的价值往往不可估量。正是这种深度浸润造就了技术奇才——他们与代码朝夕相处，洞悉系统崩溃的潜在点位，精确掌握最佳修改切入点(以及绝对不可触碰的禁区)。但每当这类人才转入非技术岗位，这种知识便开始“腐朽”。代码持续迭代进化，而他们对代码的认知却基本停滞。
你描述的情况似乎是这种现象的极端表现——将拥有制度化知识的人员过度聚焦于单一领域。这显然不是高效利用人才的方式。虽然知识传承对企业长远发展至关重要，但若应用范围过于狭窄，同样难以发挥价值。
在我整个职业生涯中，很多公司并非如此。作为独立工程师(IC)也能晋升，职位如高级工程师、首席工程师。高级工程师和高级经理的薪资其实相当。
确实能晋升，但终究是死胡同。我曾担任杰出工程师，这已是个人职业发展的顶峰(部分公司设有院士职位，但名额极少几乎不可能获得)。若想在此基础上继续发展，管理轨道是唯一出路。
此外，从杰出工程师转入管理岗位难度更大——你基本处于高级总监级别(具体视公司而定)，却毫无管理经验。
如果你在意职业发展(当然我不是说你必须在意，沉迷于技术晋升阶梯才更有趣)，我建议当你在数字晋升阶梯达到经理级别时，就转入管理岗位。
你年薪七位数？职业发展还有什么可追求的？那时候你已经赢了职场游戏。
他们汇报对象同级吗？我见过的所有“技术路线”和“管理路线”中，高级技术人员往往向同级甚至更低级别的管理者汇报。例如：管理者可能直接管理同级或更高级别的技术人员，这种情况在管理路线中显然不存在。
虽然这些并非初级管理层，但若首席工程师无需向副总裁汇报，两条职业路径显然不平等。
汇报关系为何重要？这是不同角色和岗位，管理层级自然不同。
若我是向总监汇报的初级工程师，是否比向经理汇报的资深工程师拥有更大权限？
管理岗位性质不同，自然分级不同。
或许高级独立工程师需要短期深度参与团队工作，因此临时向团队经理汇报。
这些职位具体做什么？我所在的公司设有管理轨和技术轨，但细看职位描述会发现技术轨要么与管理轨职责重合，要么就是开发者关系岗位(实质上是管理外部人员)。
IC角色负责更广泛的项目范围，参与技术决策。他们无需撰写绩效报告或处理人事管理事务。
我认为这是好事。每次看到任何公司里身兼技术/管理双职的人，他们总是承受着巨大的工作压力，永远忙得不可开交。
我也从来不赞成让工程经理具备足够技术实力来批准/否决团队成员的技术决策，因为这存在权力失衡。即便团队领导推崇糟糕的技术方案，你也不敢强烈反对——毕竟他们还掌控着你的绩效评估、薪酬调整等关键事项。
>总是承受着巨大的工作压力，永远忙得不可开交。
这不就和公司里其他专职技术人员或管理者没什么区别吗？
>我始终不认同工程经理具备技术能力来批准/否决团队成员的技术决策，这种权力失衡令人不安。
这与其他管理者或高层决策有何不同？当你的上司或其上级执意推行某项决策，而你又身处不利的职场环境时，任何反抗都非良机。
>这与其他经理或高层做决定有何不同？
非技术经理通常不会对框架或数据库的选择有强烈意见。在工程师群体中，这类决策通常按能力主义原则进行(遗憾的是往往取决于谁最能说服人)，但若经理说“用X方案”，其分量就远超同事的提议。
我曾担任此类角色，如今正被挤出这个岗位(晋升为PE)。
我真正热爱的是这种杠杆效应。在技术领域拥有优秀核心团队时，这几乎如同经营自己的小型公司。
>这是推动专职经理与专职工程师分离、取代混合角色的举措之一。
混合角色本身就是荒谬的。这相当于同时担任机械师和会计师——需要机械师？那就雇机械师。只需兼职机械师？那就雇兼职的。但我不希望我的机械师每天因税务咨询而中断发动机维修三次。
劳动分工的根本意义在于专业化，让每个人精于所长。同时承担多个截然不同的工作，反而会降低效率。250年前人们就明白这个道理。
我在组织中曾担任技术主管(TL)，后来成为技术主管经理(TLM)，现在是工程经理(EM)。个人而言，我对此相当满意。明天我将组织一场工程峰会，由我所在团队与兄弟团队(驻场团队，来自其他地区)共同参与。我注意到大约18个月前，我本应是峰会上5场主旨演讲中4场的演讲者(作为该系统的专家/技术主管)。如今却由五位不同工程师主讲。这说明我成功培养并提升了团队其他工程师的能力，使他们全员晋升为技术领导者，进而能够主动向其他团队分享工作成果。
总体而言：这是件好事。通过在技术层面减少占用资源，我用四位实力雄厚的工程师取代了我自己。此前我同时承担技术主管和工程经理的工作，结果两头都做得半吊子，导致大量工作未能完成。
另需指出的是，工程师是唯一存在这种区别的岗位。产品经理、项目经理、销售、市场等岗位似乎都将管理职责与资历挂钩。唯独工程部门同时存在技术主管(TL)与工程经理(EM)双重层级(虽然团队技术主管通常向与团队直线经理相同的工程经理汇报，但二者行使权力的方式不同)。当技术主管与工程经理形成强有力的联盟时，这种模式在工程部门运作良好，但这种情况并非总是存在。
印度某招聘专员与我沟通职位数周后突然失联。数周后我准备好面试时主动联系，却被告知这些职位已不复存在。我追问是否已被填补，对方回复大意是：不，这些职位确实不存在了。这令人沮丧，因为谷歌是当地极少数即使求职者存在较长就业空窗期仍能提供公平面试机会的企业。那些是L7级职位(不确定TLM是否存在同类岗位)。
虽然不在谷歌，但我现在正身处类似岗位，实在厌倦至极。根本无法专注编程——总要抽身去审查代码、协助修复问题、处理初级员工无法应对的上线站点、更新关于团队工作的TPS报告、制作PPT之类。这些本就令我反感，而要推进自己负责的功能更是徒增挫败感。当我刻意忽略他人试图争取连续工作时间时，又觉得自己在忽视其他事务。真好奇谁能在这种混合角色中如鱼得水…
我采用周一三五开会，周二四闭门编程的作息。没错，有时非紧急事项就得推迟一天处理。
TLM精简并非削减中层管理。这仍是技术岗位。
你对TLM角色的成效/价值有何看法？
虽非楼主，但我认为TLM在过渡性角色中效果最佳。当你需要培养全职管理者，且计划长期发展团队时，TLM虽效率不高，却能造就深谙团队实情、逐步成长的优秀管理者。
我也这么认为。技术主管/开发者与管理者是截然不同的岗位。我认同TLM作为过渡期的有效机制，在此期间可对候选人进行管理培训或指导(而非直接扔进深水区)。但任期应控制在6个月，最多12个月。否则该角色将演变为双重职责，最终导致过度劳累。
这个角色相当尴尬，你必须在管理者日程里挤出开发者的时间[1]。正如其他人所言，它只有在为全面管理岗位做准备或放弃管理路线时才有意义。
[1] https://paulgraham.com/makersschedule.html
曾任TLM(技术领导经理)，后因下属过多被迫转为EM(工程经理)。我来自谷歌老派体系(2011年前)，当时TLM角色还是我们独特的竞争优势之一。
对此我有诸多见解。依我之见，这种调整符合谷歌当前的状态——它已成为以财务与管理驱动的大型成熟集团，核心围绕优化10-K报告、高管编制及管控体系。从“交付卓越软件”的角度看并非明智之举，但谷歌早已不再专注于此。
原因在于软件构建与管理具有反直觉性，具体实现细节往往会反哺到架构设计、团队结构和项目分配中。TLM模式下，工程实践与管理决策之间存在紧密的反馈循环：管理者与你并肩作战，亲手编写代码，当问题出现时能精准定位根源并制定应对方案。最关键的是，他们能将代码库的认知融入新方案。最终形成的团队架构将真实映射代码库运作逻辑：工程师在各自领域拥有深厚专长可快速推进变更，管理层则具备足够灵活性，能根据工程现实调整组织架构，而非强行将工程需求塞进现有框架。
如今作为一名管理着十多名下属的工程经理，我已远离技术细节，只能依赖下属的汇报来开展工作。我的职责是接收产品经理关于现有产品的十项改进建议，将其拆解为十个项目分配给十位工程师，并在他们实现原型期间确保团队保持高效协作。由于代码库极其复杂，他们将耗费大量时间英勇地复现原型 (但仅限于原型——毕竟尺寸调整行为、交互逻辑或功能关联等细节几乎不存在裁量空间，管理层也无暇追责那些未明确要求的功能)。他们编写的代码扭曲不堪，让代码库愈发复杂，却已是力所能及的极限——因为真正需要重构代码简化逻辑的人，汇报线属于另一位副总裁。但这无妨，因为我上级的管理层同样无暇核查技术细节，再上一层亦是如此。若耗时过久，我们大可申请增员来应对效率低下——反正花的是别人的钱，而当产品质量既无法保证又无关紧要时，这已然成为我们职业晋升的唯一途径。
TLM角色的价值终究在于代码、工程师与管理层之间紧密的双向反馈。身为TLM，你能根据代码本身的信息做出组织架构决策；而成为EM后，你的决策依据就变成了上级经理的指示。但在公司发展的某个阶段，代码变得无关紧要——反正没人会通读全部代码——唯一重要的只有经理的意见，进而延伸为副总裁的意见。副总裁通过数学逻辑实现最大化控制最大规模组织的方式，就是建立扁平化组织结构，让每位经理管理尽可能多的下属。因此当这成为唯一标准时，这种结构便不可避免地形成。
残酷
作为现任IC，+1。不确定谷歌全球是否如此，但在我所在部门确实如此。
这个问题让我觉得有趣，因为整个职业生涯(主要在小型公司/小型技术部门)我从未向EM汇报过。直到进入大型科技公司，“不写代码的EM”才成为常态，这让我需要一段时间适应。此前所有岗位都设有技术主管(TL/TLM)，他们既是团队领导者又是技术专家——正如弗雷德·布鲁克斯著作中描述的“外科医生模式”。
据我观察，EM的核心职能在于执行公司政策。我不确定小型企业是否真有此类岗位的必要性。
作为在员工规模从<30到>10万的企业都工作过的人，我认为EM的核心价值在于沟通。想象一家拥有m名员工的公司如同m×m矩阵：1代表常规沟通，0代表零沟通，0.5则代表走廊偶遇——CEO们总强调这种“随机重现”(RTO)的重要性。
在小型企业(假设规模低于邓巴数)，员工间自然形成紧密网络，无需EM。随着公司扩张，矩阵结构逐渐疏离——直至达到谷歌级别(18万正式员工外加同等规模的承包商)，矩阵几乎全为零。因此EM的职责在于解决沟通难题，因为信息仍需在公司内外流动——无论是“启动这个项目”、“其他团队已解决该问题”、‘这个项目是永无止境的痛苦深渊应予终止’，还是“员工24601表现卓越应赋予更多职责”。
这正是核心所在。
我听过对EM角色最精辟的描述是：“这是由众多兼职角色组成的集合体，各自拥有不同技能，共同肩负着确保项目成功的责任。”
沟通是其中关键环节——向下传达(向下属提供成功所需信息)、横向获取(从跨职能伙伴及管理层同级收集信息以协调项目进展)、向上管理(适时调整预期并寻求指导，避免高层恐慌)。
但涉及的其他技能包括：扮演心理咨询师(处理焦虑、士气问题、怨恨情绪及不当行为)； 指导(技术与人际双重指导)；将模糊的高管指令分解为子目标；优先级排序；招聘；绩效管理；处理下属提出的各类突发问题；谈判；团队架构设计；培养下属专业能力；规划其职业发展以促进晋升；确保其成就获得认可；营造办公室欢乐氛围；树立尊重文化典范；推广新产品计划；当然，还有执行公司政策。
感谢分享，这确实很有帮助：)。过去四年我担任TLM/EM，至今仍时常困惑于角色定位…更在闲暇时刻(其实很少，多数时候工作超负荷)纠结该把时间花在什么鬼地方。
谷歌情况我不清楚，但我们公司(主要做软件开发，半支团队负责固件/硬件)大致如此运作，不过更多是临时安排而非固定规则。所有团队规模都很小，所有TLM级管理人员都是从开发岗位晋升而来，因此他们仍有时间参与技术工作；具体参与程度和工作内容取决于团队——有些仍直接参与产品开发，有些则更多从事(技术)辅助任务，这类工作更容易被管理层的咨询打断，对开发进程影响较小。
我认为这种模式运作良好：TLM始终保持着与一线工作的紧密联系，能更清晰地把握产品开发动态、面临的技术难题(包括工具环境等方面)，并使他们对产品的认知保持更新。当然，以他们的技术背景而言，未必都擅长管理，但从未在管理职责上犯过重大错误。简而言之，这种模式在我们团队行之有效，但可能仅适用于本地组织架构和团队成员特质。
(个人观点)
我认为这是让员工学习管理技能的良好跳板，避免让他们突然承担十名下属的压力。但纸面上的管理层级确实显得不太理想。
十名下属对初任管理者而言确实过多，但过少也同样不利。4-5名直接下属可能是最佳平衡点——既能积累管理经验，团队规模又足以让人际关系问题相互抵消。
以个人经验而言，TLM(技术领导经理)当主管并不理想——某种程度上你与主管在技术领域存在竞争关系，而你注定会落败。
读到这段很贴切，完全道出了我的感受：当公司由一群怀揣使命的热忱者组成(关键在于这种使命必须真正自上而下贯穿)，TLM模式的弊端完全可控——组织会给予所有相关者宽容与弹性，因为他们明白TLM牺牲了部分个人执行力，其下属也失去了直接影响的空间。只要能“做大蛋糕”，通过执行弥补各自份额的缩减，一切都能运转良好。
但进入后期阶段后，这种模式就行不通了。TLM可能同时被要求达到100%的IC标准和管理标准，其下属则争相争取“影响力”，不愿与管理者竞争等等。
我完全理解为何这种模式在当今谷歌行不通。坦白说，他们意识到这点或许是积极信号。
我认为设立一线领导者的构想很有道理。必须有人代表业务工作，并能穿梭于层级体系之间。这类角色本就以非正式形式长期存在。
任何事物都有两面性，其利弊完全取决于组织内部的政治生态。
我目前实质上担任TLM角色。我们是小型公司，代码库规模不大。我管理三名初级至中级开发者，并在产品路线图规划中代表团队发声。同时我仍需编写大量代码、审核大量代码并做出架构决策。在当前规模和资源条件下，这种模式运作良好。快速推进是我们的首要任务，相比传统职责分离模式，技术领导者模式显著降低了管理开销。
我原本从未打算担任管理职位，但这次经历让我得以在无需全情投入的情况下体验部分管理职责，实属难得机遇。其他回复将此描述为过渡性角色，我认为这种说法并无不妥。从长远来看，尤其当公司发展壮大时，我或许通过专注于某条职业路径更能创造价值。不过对于合适的人选和情境，我认为无论团队规模大小，我们都可能再次培养出技术主管。
当团队规模停滞不前时这种模式就行不通——团队永远无法扩充至完整编制，而向技术主管汇报的初级工程师最终会在过于狭小的团队中沦为平级同事。
道理很简单。在增长期这套机制尚可运作，但眼下显然不是增长期。
这类角色的价值在于：既要对接官僚体系与业务层级的多重需求，又要实际参与技术工作并深谙项目细节。
若缺失此角色，管理层无人真正编写代码，也缺乏产品开发的第一手经验。一线经理最终沦为员工与高管的传声筒，因为他们仅能接收下属汇报的信息。他们自身认知极为有限。
这种损失无法在财报中量化，但其最显著的危害在于：极大削弱了实际开发团队对产品的归属感。
我从未见过哪个TLM会定期编写代码。
TLM这个职位堪称技术领域最棒又最糟的角色。
最棒之处在于TLM通常能完全掌控产品执行(甚至常能碾压产品经理)。若你对目标有清晰愿景且决心贯彻，这简直是梦幻配置。
最糟之处在于团队扩张时工作量会急剧攀升。
记得2010年TLM还被视为糟糕设计。看来这几年行业风向已彻底逆转。
> 谷歌称之为TLM角色——技术主管/经理。要求既要编程又要管理几名初级工程师。
哦——这解释了太多。我的职业生涯几乎都在二线公司度过，这些公司总想效仿FAANG/MAG7巨头的做法，却因不懂根本原理或不愿放弃权力金钱而屡屡搞砸——即便最终他们确实获得了更多资源。
总之疫情后突然所有公司都要求我担任软件工程经理时，既要管理7-10名直接下属，每周投入30小时项目管理，同时还要精通每个下属负责的项目，至少担任项目初始架构师。
我直接无视了这些要求，专注维持团队效率——毕竟这些根本无法实现。过去五年公司对此尚可接受，但既然FAANG巨头们要彻底清算这类岗位，看来我得再次转型了。
我们也搞过类似制度但冠以不同名称，简直糟糕透顶。如今这类岗位回归传统架构模式，实在不足为奇。
为何糟糕？
管理技能与技术领导力/核心开发能力本质上是不同领域。
二者各占50%的分配模式，导致任何单一领域都难以实现显著提升。
核心矛盾在于：管理需要大量“分散注意力的时间”关注环境动态，而技术岗位则需要大量“埋头苦干的时间”。这两种模式存在根本冲突。
我在初创公司尝试过这种模式，结果大部分技术工作只能加班完成。这种模式根本不可持续。
当时情况糟糕透顶，因为这些“管理者”几乎未经培训，不仅形同虚设，更在劳动法诉讼中成为公司的法律隐患。许多情况下他们甚至不属于同一直接团队，而是相邻团队，导致团队间几乎零互动。这彻底推翻了“技术/编程背景的管理者更适合作为导师”的假设——毕竟根本没有时间履行导师职责。当然公司给他们的薪资与非管理层资深开发者相同。我敢说至少50%的首批管理层在一年内离职或降职为普通资深开发者。如今公司多数部门已放弃这种模式，当初效仿谷歌才是唯一真正原因。
这是职业生涯中唯一被要求同时兼顾编程与管理的阶段，而要两者兼顾且都做到高水平实属不易。
首先他们裁掉了非技术员工。作为大型科技公司，谷歌需要专注于编程。但这还不够，于是他们又裁掉了负责管理程序员的中层管理者。作为大型科技公司，谷歌需要专注于编程。但这仍不够，于是他们又裁掉了那些担任各产品领域专家的基层管理者。作为科技巨头，谷歌必须专注于纯粹编码，任何未投入100%精力编码的人都是冗余。但这仍不够，接下来他们将裁撤资深工程师。身为科技巨头，谷歌需要专注编码，而资深工程师耗费过多时间在“架构设计”(无论这意味着什么)。但这依然不够。于是他们将裁掉普通工程师。作为科技巨头，谷歌需要专注于最纯粹的编码者——即那些根本不理解产品的初级工程师(理解产品被视为有害)。但这仍不够彻底。最终他们将裁掉所有初级员工，仅保留名为格雷格的员工，授予其“谷歌官网站长”头衔，用PHP重写整个网站。这样这家科技巨头才能真正繁荣！
它不是已经繁荣了吗？
基本如此。只不过这位格雷格其实是双子座，他们指望它能在高管们复杂矛盾的指令下全天候完美运转。
不提AI就胖成这样真厉害
在不同规模的组织工作过，我发现网络效应问题确实存在，大公司官僚作风尤其严重。
有位工程经理开玩笑说他在沃尔沃汽车的这一年就是一场马拉松会议。连当时的CEO都抱怨公司开会太多。
我还记得一位来自大型企业的初创公司同事讲过，印度同事每年都要求升职加薪。原因何在？原来印度同事的父母对他们职业发展有强烈期待，必须通过晋升或涨薪来证明进步。
公司如何应对？他们开始创设职位头衔，实质上是营造晋升的假象，而日常工作内容却未作实质性改变。
这似乎对组织架构产生了某种通胀效应——解决一个问题的同时，可能催生其他问题，即官僚主义。
据知情人士透露，35%的削减幅度指的是管理人数少于三人的管理者比例。
若管理0-2人，多数情况下效率必然低下。谷歌最初为何让这么多员工处于这种状态？难道其他65%的管理者要填补空缺来虚增团队规模？还是说让剩余65%的管理者也去管理0-2人？
对于该规模的团队，通常假设管理者仅投入约一半时间进行人员管理，另一半时间直接参与团队核心工作。若目标仅是增强管理者杠杆作用，这种安排或许可行；但同样可能导致管理者无暇深入做好任何具体工作。此外，这类兼职直线经理往往缺乏足够的组织影响力来切实保障团队利益。
基于多次实践经验，我认为更优方案是组建全工程师的小型团队单元，再由专职人事经理统筹管理所有单元。
根据我的经验：组织重组和限制人员流失后的补位，往往会导致这种尴尬局面。管理者最初可能拥有合理数量的直接下属，但随着时间推移情况会逐渐恶化。
我所在的团队仅有两人，配有专职管理者。这位管理者既不写代码，甚至不具备真正的技术背景。
简直糟透了，快派人来救救我。
个人认为管理0人最理想。我绝不会接受需要管理更多或更少人数的职位；不过若对方能独立工作且无需过多监督，我愿意妥协管理1人。
肯定有公司让经理管理虚构的复杂人物。
> 管理0人很棒。我绝不会接受需要管理更多或更少人的职位；
如果收到管理人数少于0人的职位邀请，我肯定会问一堆问题
那岂不是要你“监督不足”一到多人？cue rimshot
若你的职位是个人贡献者，管理0人固然不错。但若身为管理者却无人可管，这个职位似乎就显得多余了。
入职时曾被告知，在L5级别获得晋升的捷径之一就是成为管理者。当时不知此言几分真实，但如今看来这或许正是局部优化策略的后果。据我所知，现在除非是历史遗留人员，否则L5级别根本无法担任管理职务？
据我所知，搜索和广告部门对经理的L6要求由来已久。我曾以为某些非核心营收部门曾放宽过要求，但L6限制实际上存在已久。
顺便说一句，我在两个项目组担任过L5经理(软件工程师晋升通道)。L6要求确实存在，但实际执行相当宽松。管理层只需向副总裁证明我具备胜任能力且即将达到L6晋升标准即可(不过第一个项目组后来解散了，晋升耗时很长)。
有意思。在我任职期间从未见过L6规则的例外情况。
虽非谷歌员工，但我的经验是：这种晋升通常是乐观预估——将某人提拔为经理，预期后续会增加团队规模。但后续要么永远不会发生，要么恰逢人员流失，导致其管理范围始终无法达到合理规模。
某些情况下，这种模式能以效率换取速度——本质上存在大型任务无法通过团队协作加速完成(如同神话般的人月理论)，因为它们本质上是顺序而非并行任务。这类任务通常包含可并行子任务，因此可安排单人率先推进(视其为项目唯一执行者)，待子任务可并行时再调动团队。此时无需决策或沟通开销，团队成员只需听从负责人指令立即行动——正是这一环节确保了团队效率不低于个人项目。
在这种架构中担任团队领导固然乐趣无穷，但作为团队成员则极度打击自尊心，且需要超凡能力才能成为推进速度的助力而非拖累。因此即便项目处于串行阶段时你大多闲置，仍需支付离谱的薪酬。这种模式我认为2012年的谷歌能盈利运作，但2025年的谷歌已无力承担。
某些产品恰恰适合1-3人的团队规模；与其强行拼凑两个无关产品来凑大团队，不如让小团队独立运作。正如其他评论所述，这类TLM岗位要求管理者同时承担技术贡献。
通过从大型团队抽调员工，直至该团队仅剩0-2人。
我在一家初创公司工作，工程团队约6人，我管理着1名员工。虽然认同这种比例不够高效，但目前尚可运作。
不过我认为成熟的企业不应存在仅管理0-2人的管理者。
少于3人？这种情况几乎毫无意义。谷歌能解决这个问题固然可喜，但我对那些放任此类荒谬现象滋生的管理者有太多疑问。
若真少于三人，35%的淘汰率也过低。这类情况本应淘汰95%才合理。
只有当管理者仅承担管理职责时才算低效，而我怀疑多数情况并非如此。
文章提到他们转为IC(个体贡献者)，说明这些是TLM(技术领导者)或类似角色。标题似乎是噱头，实际被淘汰的是小型团队。
关键在于那种“既当经理又写代码”的半吊子角色。现在就是取消这种角色，让管理和工程各司其职。
这怎么能说是低效？
在某些类型的公司里，真正创造收益的是没有管理职责的员工。
以快递公司为例，司机负责配送才是公司获利的根源。管理者过多——即每名管理者负责的员工过少——会拖垮公司，因为管理者领薪水却不参与配送。
当然，这种分析未必适用于谷歌这类企业。我确信在谷歌发布广告无需人工干预，或许他们根本不存在对应“司机”的角色，导致该比例无法计算。
我认为这取决于经理还承担哪些其他职责。如果经理的工作量过少，他们可能会过度管理小团队，频繁检查工作进展，这既低效又打击士气。
若公司经理管理0-2名员工，意味着基本形成一人管理一人管理一人等层级结构。
设想一个由10个服务组成的协同系统，每个服务需要1-3人。系统负责人可任命10位技术主管负责整体服务质量，否则可能面临超过20名直接下属的局面——其中多数人向高层汇报的内容毫无价值。
我确信大型科技公司之所以过度臃肿，根本原因在于高层缺乏能清晰提炼愿景、指引下属方向的高质量领导者。
这绝非易事——但苹果至今仍依靠着史蒂夫·乔布斯的远见卓识生存发展。
2018年我对谷歌的感受正是如此。如今它在某些方面确实精简了，但CEO仍在自动驾驶模式。
高质量领导力在现实中本就极其稀缺
深表认同。更糟的是，中高层管理岗位充斥着只顾自身利益的蠢货，对发掘潜力人才并加以培养毫无兴趣。
商学院根本无法培养出合格的未来商业领袖。
这些企业如何膨胀至如此规模令人费解——这正是高层管理失序的代价。
如今高管对员工的居高临下态度读来令人沮丧。自我离开后，这种文化变迁实在令人遗憾。
我在2013至2017年任职期间，目睹了公司从始至终的剧变。
2011年前的谷歌其实是个很酷的工作场所
这时间线恰与谷歌员工发起工会运动、以及谷歌雇佣反工会人士的时间点相吻合
腐败始于高层。
技术团队一线经理的最佳人数约为5人。若扩大到10人，就无法有效掌控全局。一天只有24小时，管理本身就需要时间。
对于10人以上的团队，要么需要高度自主且积极主动的成员，要么必须配备可靠的直线经理。
> 超过10人就无法有效管控。一天只有24小时，管理本身就需要时间。
正因如此，我反而在员工与经理比例更高的团队中获得过更好的管理体验。
当管理者无法参与所有事务时，他们被迫学会放手、授权，并跳过繁琐的管理事务。
我最糟糕的经历发生在每2-3名员工配一名管理者，且要求跨级管理者也参与的公司。无休止的会议、每周与多人进行的1小时一对一谈话、目标设定、个人发展练习，以及不断增长的日程干扰清单——这些都令人窒息。
这些管理者似乎需要制造工作量来证明自身价值，于是我们的时间被填满各种会议和活动——除了让管理者因实践播客和书籍学到的管理术而自我满足外，毫无实际贡献。
深有同感。当直接下属寥寥无几时，这些“管理者”无事可做，便编造无谓事务，开始折磨真正干实干活的人。有次我反馈其他成员的工作问题，那家伙完全不接招。“我会找他谈谈”…结果什么都没做。当时我比团队所有人都有经验，包括那位“经理”。他现在已经离职了。
我也有同感。我目前带领三人团队却有两位经理。一位基本不愿过问我们，另一位则要求每小时提交活动报告——我敢肯定他从未看过这些报告。
按这个比例，技术经理本应优先参与每次代码审查，应彻底测试所有功能，更应出席设计评审会议，在问题影响普通工程师之前就发现漏洞。
管理两人时确实有时间处理开发工作，但管理4-5人就棘手了。
这个观点很有意思，虽然我以前没听过，但深有同感。谢谢
每当看到管理5人的经理，我就知道接下来会有每日30分钟站会、周五“总结”会议、每周一对一谈话等各种非工作活动。若5人团队需要全职保姆，说明这个团队里根本没有成年人。
不，5人左右才是理想状态。若团队规模如此之大你还进行微观管理，就意味着你在忽视管理者职责的其他方面。超过7人时，你将无法及时响应团队需求，也无暇处理规划和流程类任务。
两种情况都可能成立
若仅管理一个小型团队，这与我的经验也吻合。
这句口号在科技界流传至少十年了，但我逐渐产生强烈异议。管理者至少应管理10人，多数人应管理15-20人。他们应专注于管理职能，除纯管理问题外不应解决其他问题。优秀的教师轻松管理着10-30人的班级，即便在私立学校也是如此。过低的直接下属数量最终会造就权力过大、话语权过多、且有过多时间胡闹的管理者。
当管理者手下约5人时，通常会为证明自身价值而给所有人制造额外无谓的工作
> 对于大型团队(10人以上)，要么需要高度自主且积极主动的个体，要么需要可靠的直线经理。
这恰恰描述了我参与多年的苹果硬件团队——当时组织架构尽可能扁平化是首要原则，旨在防止官僚主义和中层管理者形成的领地之争。
有意思！你们团队有多少人？没有出现其他非正式权力结构吗？
我从未直接向管理人数如此之少的上司汇报过。5人左右的团队运作良好，但管理者可能同时负责多个团队。他们无需参与大多数成员的日常事务。
谷歌大概和所有公司如出一辙。他们通过将实际工作者伪装成非管理岗位来削减基层管理职位，从而压低薪资。
我在某些公司任职时，这种现象已达到荒谬程度。曾见过横向项目经理和交付主管管理多达80人，而实际向他们汇报的中层管理者却被归类为普通员工。
更可笑的是，某些公司里实际管理职责极少、却由大量拍马屁者占据的职位，反而被认定为管理岗位。
多数现代大型企业都彻底搞砸了。我们未见更多颠覆性变革的唯一原因，是监管俘获现象。
接下来：超级沮丧的前谷歌产品经理在新岗位抱怨“谷歌可不是这么干的”。
许多人对“流程”投入过深，以至于无法看到流程之外的事物。
https://www.youtube.com/watch?v=bTuLbiIVDpk
这种现象已持续十多年
无论在谷歌任职期间还是之后，与这类产品经理共事都令人极其困扰
讽刺的是，我所在的两人团队里此刻正与其中一位共事
“顺便说一句，我认为Meta没有设立VEP职位，”Cicconi表示。
此言回应其在Facebook工作五年后获得一个月带薪休假的经历。这位谷歌高管似乎认为设有“自愿买断”计划已足够优秀，足以保持竞争力。
既然如此，谷歌举办这些全体会议还有何意义？纯属浪费时间，直接向员工发送邮件告知已决议的更新政策，省去那些客套话就好了。
管理开发团队是项艰巨工作，我敬重那些能创造价值的管理者。
我认识的优秀管理者之所以出色，并非依赖周围的各种激励措施。其余管理者大多随波逐流，被动应对环境变化，结果往往是大量向上管理却鲜有实质价值——只是按时提交更多TPS报告罢了。
坦白说，作为局外人，我认为裁撤这个职位并非最关键。过去几年我与谷歌有过几次接触，我所在的公司被列为优先客户，他们希望拓展更多业务合作。
每次会议他们都派出一名工程师(通常能力尚可)和六七名电子表格追踪员——这些人要么来自麦肯锡，要么刚从商学院毕业，除了消耗会议室里的氧气外似乎毫无作用。每次开会总有新人冒出来自称是负责对接关系的人(这已成为我和CTO之间的固定笑话)。
有段时间我不再参加这些人安排在我日程表上的每周例会，结果那家伙打电话来质问原因。我解释说会议毫无价值——整场会议的目的只是让他逐页宣读一份大家早已共享的电子表格。如果我感兴趣的话(剧透：我根本不感兴趣)，完全可以自己阅读，何必浪费45分钟开会。他大为光火，不久便消失无踪，取而代之的是自称“关系主管”的另一个人。
简而言之，若他们能清除所有自称“关系主管”的客户对接人员，比裁撤TLM团队更能砍掉冗员。
“似乎除了消耗房间里的氧气外毫无功能”
我有个贴切的称呼——氧气窃贼。
我倒想知道这些人当初为何能当上管理者。更何况这种头衔在公司似乎相当普遍，毕竟他们发现35%的管理者都属于此类。要么数据纯属虚构，要么谷歌管理层真的失能了
致发布方：阅读至文章三分之二处时页面突然消失，滚动条直接跳至页脚。返回顶部后仅剩标题、核心要点及约3000像素高的Taboola广告。体验极差。
好奇TLM角色中的管理职责具体包含哪些内容？
作为前工程经理，我始终对职责划分效率低下感到惊讶。比如我担任工程经理时，大量时间都耗在后勤事务上——搬迁新办公楼时，光是座位安排就耗费了海量时间。或许谷歌这样的大公司有更多人处理这类事务，但我仍认为以下分工更合理：
1. “技术导师”角色：既参与编程，又明确负责约5名初级工程师的技能成长与技术反馈。此人_不_负责薪资/加薪谈判、晋升决策(但会提供相关建议，详见下文)、后勤事务等。
2. “指导经理”(这个名称确实不太理想，但为避免与其他“总监”或“经理”混淆而保留)。此职位明确无需任何技术技能，负责所有后勤/薪资谈判等事务。该职位通常管理约5名技术导师，即最多负责25名团队成员。例如晋升决策将由5名技术导师共同商定，确定团队中最值得提拔的人选，但最终薪资决定权归属“指导经理”。
该架构尚可调整，核心理念在于更高效地分离技术与非技术能力体系。
这不仅适用于工程师。有些非工程类经理因缺乏管理对象而被降职为IC(个体贡献者)。
早该如此。整整晚了七年。我职业生涯的大部分时间都在担任谷歌云顾问。当时有个巨型客户，我们正因前员工承诺的不可行成本削减方案而血本无归。我接手他的职位——简直是接手烫手山芋。走进谷歌办公室时，那场景令人惊叹：餐厅区提供12种不同菜系，多个游戏室配备乒乓球等设施，还有休息室，应有尽有。那体验更像是五星级豪华度假村。
当我们穿过员工工位走向会议室时，发现超过半数工位空置。我问带我们参观的同事员工都去哪了——“他们想工作时才工作！” 哇，简直是梦想！谷歌当时有项规定：员工每天可将20%的工作时间用于个人项目。但实际使用比例往往高达40%。我认为这是实现工作与生活平衡的完美模式。直到见到我们本该对接的TLM及其团队，我对员工素质的期待才彻底破灭。
这群小丑真够可以的。他们居然建议我们用Cloud Spanner——当时最昂贵的方案之一，而我们的瓶颈(和资金流失)明明来自老旧的MySQL。他甚至不知道Spanner比他们的Cloud SQL方案更贵，更别提这是完全不同的产品(它是No-SQL)。他们连何时该用Spanner、何时该坚持用SQL都搞不清楚。这明明是他们自家产品线，我们反而比他们懂行！当时我连GCP认证都没考过，这才是最可笑的。客户只是需要重构基于老旧PHP-MySQL组合的应用架构，他们连迁移目标技术栈都提不出建议！他们毫无头绪，还试图搪塞过去。会议中途，老板俯身对我说：“Neya，我觉得你比这些家伙懂行，咱们走吧。”我们当即起身离开。值得一提的是，谷歌确实提供了部分服务额度补偿，但远不足以弥补我们的损失。
回到办公室后，出于好奇我查了这些人的薪资——当时根据经验不同，轻松就能拿到12万到25万美元。那一刻我彻底对谷歌失去了信任。若是我拿这么高的薪水，绝不可能如此懈怠。后来我才明白，这些人的存在很大程度上是出于配额制度——谷歌要求各国团队维持特定人群比例，而这些技术支持专员及其团队恰好符合要求。既然没问题，何必改变呢？
我们曾经熟悉的谷歌创业文化早已消亡，这段往事至今已有七年之久。此后五年间，他们除了通过提高GCP服务价格牟利外毫无作为。记得云存储价格突然上涨时，他们毫无预兆地抽走了我们的地毯，导致成本骤增。毫无创新，空空如也。如今ChatGPT席卷市场后才推出的AI模式，本该在五年前就实现。他们完全复制了硕士课程教材中描述的模式—— 《盛极必衰》(极佳著作)，实属咎由自取。种瓜得瓜，种豆得豆。
/结束吐槽(感谢阅读！)
> “随着规模扩大，我们必须提升效率”
…谷歌已是27岁的老牌企业
…谷歌堪称当今最具价值与影响力的公司之一
我觉得“扩大规模”这个说法在此语境下不太合适
我也这么想。有评论说此举可能与股价或安抚股东有关，所以我不禁怀疑这句话是否也是在向他们示威：“我们已经很大了，而且计划变得更大”
纯粹是增加下属人数来保护自己。这不正是官僚机构的惯用伎俩吗？
这种现象循环往复。记得谷歌上次这么做(2006年？)时有“7人规则”：
任何经理下属不得超过7人
任何员工与CEO之间不得存在超过7层管理层级
这个数字怎么定的？
7人配1名管理者似乎合理。或许能扩大到10人，但这只是我的直觉。
7层管理架构对我来说太臃肿了。公司会充斥着专业的中层管理者，他们争相定义企业文化和战略。这真是初衷吗？感觉不太对劲。
有没有更科学的方法？
> 七层管理架构对我来说太臃肿了
没错，所以超过这个层级是被禁止的。规定并非要求员工到CEO之间必须有7人，而是强调两者之间不应超过7人。
禁令制定时需设定合理阈值：先选取合理层级，适当放宽后，再禁止超出该范围的不合理层级——这点你应该认同。
但要注意，大型企业(比如十万人规模)确实需要这么多层级，否则每个管理者要管的人太多。
没错，最多7层。而且我觉得实习生应该不算在内 🙂
而且那家公司规模小得多。
他们应该设定16级汇报层级，加上CEO与CEO之间8级管理层。这样就能用IP地址管理员工了。
这确实该成为行业标准。太多管理者对团队微观管理，制造的问题比解决的还多。
我始终不理解小团队的概念。管理小型团队根本无法带来中大型团队的规模效益。那些小团队经理的带宽损失或额外薪资，公司完全可以投入其他更有价值的领域。
但这类团队在FAANG公司里往往是某人扩张地盘的副产品，这对其他相关人员而言实在不幸。
该负责人还承担了大量常规开发工作。其工作量小且自成体系，既无需增设编制，也不适合并入其他团队。
我甚至认为可以组建单人团队，但因其工具效率低下且流程繁琐，导致需要额外编制。
有相关经验者能否指点迷津？我在C轮初创公司收到这类职位邀约，工作性质介于工程师与管理层之间——我感觉是50/50，对方宣称是80/20。我始终认为角色切换绝非好事。从未见过能同时胜任技术主管和管理者的技术领袖。我坚持认为技术主管或管理者岗位应100%专注——要么走技术路线，要么走管理路线。但缺乏佐证这一观点的实证依据。
我正身处这种境地。经历越久，越能总结出：
你既享受管理者部分权益，却要承担全部管理责任。当必须从两种视角审视问题时，做出明智判断变得异常艰难。本质上，你承担着双重职责。我发现极难抽身放手，让团队在没有我参与的情况下决策。技术偏见驱使我对明显错误的决策介入干预，但这种做法阻碍团队成长，更可能被视为微观管理。尽管处境艰难，这却是探索管理岗位、判断是否适合长期发展的绝佳契机。
在初创企业早期，当团队专注于产品开发且成员多为自我驱动的高级工程师或亲力亲为的创始人时，80/20法则尚可奏效。问题在于引入大量其他岗位、经验不足的新人以及日益增多的干扰因素后，核心团队的贡献率将从80%骤降至30%。
我不明白谷歌员工如何忍受上市公司的官僚作风和内部政治斗争超过两年，最终只会带着“去你的”钱退休。
我感觉这种观点在此地并不受欢迎，但那些专用于内部的职位缩写和得意洋洋的解释帖，让工作环境听起来简直是人间地狱。
我认为团队需要军士长，技术主管比经理/管理层更接近这个角色。
听谷歌员工喋喋不休地谈论他们复杂的企业架构和缩写词总是如此诡异。
这让我想起离职补偿金，还有那些彬彬有礼的小蜜蜂背诵着他们的企业传说。
谷歌是社会的毒瘤。
> 谷歌是社会的毒瘤。
当他们“扩大规模”时情况会更糟——通过减少人力提供相同服务，将更大比例的收入(直接或间接囤积)输送给股东。
我个人欢迎新的人工智能统治者。
倒不是想讨好谁，更不指望未来的人工智能管理者会记住我的好话，在我公司被接管时提拔我。
回收部分数据中心资本支出
本周我遇见一位谷歌资深员工透露，多数高管都是甲骨文出身。
谷歌距上次推出划时代产品已近二十年——自2006年以来，他们既未开发也未收购任何能像安卓、地图、搜索、文档等产品那样主导市场的创新。这很符合他们的风格。
谷歌大脑的Gemini和Transformer系列或许会说“你先喝着啤酒等我”
Gemini绝对算不上划时代产品，ChatGPT才是。这就是为什么人们会说“用ChatGPT查资料”而非“用Gemini查资料”。你出去找非技术圈的朋友确认下，我先替你攥着啤酒。
谷歌研究院/DeepMind是完全不同的存在。
产品层面Perplexity碾压他们——不过PPLX的广告变现能力(以及谷歌靠Chrome各种手段维持追踪的行为)确实无法比拟。
若所谓“胜出”只是烧钱，那确实如此。这和优步当年如出一辙：提供超凡服务直到盈利需求出现，随后服务质量便急转直下。
所以不，Perplexity的做法并不难复制。关键在于当资金链断裂时，它能否存活。
谷歌的小团队规模是多少人？
减少管理者数量同时降低其直接下属人数似乎不可能实现。若裁撤管理者，剩余管理者自然会吸收其下属。因此两者必有一项不成立——除非员工完全不向任何人汇报。
该统计数据仅指直接管理少于3名员工的经理。
> 据知情人士透露，35%的削减幅度指的是管理人数少于三人的管理者数量。
> 据知情人士透露，35%的削减幅度指的是管理人数少于三人的管理者数量。其中许多管理者以个人贡献者的身份留任公司
因此这些人中多数并非真正管理者，而是没有管理者的工程师。
但若存在仅管理一两名下属的“经理”，这确实显得多余——除非该“经理”实为全职开发者，只是被冠以“经理”头衔。
未解的问题在于：他们究竟裁撤了_人员_还是仅取消了“经理”_头衔_？
这对Oxygen项目产生了什么影响？
具体来说，合并多个团队究竟意味着什么？
直接管理少于三人的经理要么被解雇，要么被迫转岗(通常成为个人贡献者，符合整体精简管理层级的趋势)。
我目前在超大型(15+人)“游戏团队”担任“个人贡献者”。让一位管理者支撑这么多人的效率简直荒谬可笑——他们只会凭经验法则和流行术语做决策，几乎总是错的，而我们默默无视这些决定。反正他们太忙，根本不会察觉。
我多次提议解决核心问题时均遭拒绝，比如“我知道需要解决一个重大核心问题，给我增加一名工程师和一名兼职技术美术师，我们就能完成任务”。
许多大型企业仍遵循如此过时僵化的流程，奉行“工程师越多越好”的逻辑，实在令人作呕。
15人团队的管理者不该包揽决策。团队应凝聚共识，通过决策流程制定良策。管理者只需确保成员持续成长，具备相应层级的贡献能力。
我赞同你的观点。从其他人对这篇文章的评论来看，谷歌似乎并不认同我们的想法。
如果非要说的话，我主张比“两份披萨”团队规模更严格的标准：团队人数不应超过4人，其中必须包含一名薪酬极高且需达到极高标准的负责人，否则应立即解雇。
…然后用AI取代他们？
好奇谷歌现在会如何处理TVC。TLM通常还配有TVC小队。
TVC是什么？
TVC被削弱得够呛
所有远程工作的经理都被他们的Gemini版本取代了，至今无人察觉：)。
小团队管理已死。小团队管理万岁。没错。你解雇他们后，资深工程师会填补空缺。只是这并非正式流程。成本并未消失，要么由员工加班承担，要么以效率损失为代价。
我从未遇见过能创造价值的管理者。事实上，我经历过最好的工作环境是：产品负责人对技术团队的决策权极小，他们不指定具体方案，而是阐明需求背后的逻辑，让团队有机会提出更简洁的解决方案。