成为管理者的真相 — 这不是在资深工程师之上再加一堆会议

引言 — 十四条"真相"的共同点
产出函数变了 — 格鲁夫的等式
个人吞吐量这个指标停止工作的三个原因
反馈循环变慢，也变得难以判读
头六个月反复出现的三种失败
去找数字，会发现几乎没有
如何判断该不该回到IC
结语 — 把"不知道自己做得好不好"当作默认状态接受下来
参考资料

引言 — 十四条"真相"的共同点

2026年7月29日，GeekNews上出现了一条题为《成为管理者的真相》的条目，获得41分。原文是一位名叫Sofia Kodar的个人博主在6月21日写的The truth about being a manager，两天后的6月23日，它又被发到Hacker News，收获113分和64条评论。

首先有必要把这篇文章的性质说清楚。这是一篇个人经验随笔，而不是研究。没有统计数据，没有引用的论文，也没有样本。作者自述的履历（大约十一年的管理经验）是唯一的依据，而这份履历从外部也无从验证。所以标题里的"真相"，应当读作作者本人的真相。

不过，这类文章反复被顶到前列这件事本身就是信息。把十四条并排看下来，其中大部分都是从不同角度在说同一件事 — 你不再是团队的一员，随口说的一句话被当成指令，孤独，怀里揣着不能说的信息，以天为单位看不到进展。这不是在说工作量变多了，这是在说工作的种类变了。

原文并没有解释其中的原因，本文来解释这个结构。成为管理者不是在资深工程师的角色上再压一堆会议，而是产出函数本身被替换掉了。而这次替换带来的副作用，大多源自同一个原因 — 反馈循环变慢了，也变得难以判读。

产出函数变了 — 格鲁夫的等式

安迪·格鲁夫在High Output Management的管理杠杆一章中给出的定义很简单。管理者的产出，等于自己组织交出的产出，加上受自己影响的相邻组织交出的产出。

在这个定义里真正重要的不是等式右边，而是它前面那个区分。格鲁夫把活动（activity）和产出（output）分开。一天开完八个会、做出十二个决定，这是活动；产出则是那个团队在那个季度交出来的东西。两者相关，但并不相同，而且相关的方向本身也并非不言自明。

做IC的时候几乎用不到这个区分，因为活动和产出之间的距离很短。写代码这个活动，会在几小时到几天之内变成"已合并的变更"这个产出，中间介入的其他人也很少。成为管理者的那一刻，人和时间就挤进了这中间。你今天做的一次1on1，其产出不在本季度，而在下个季度出现，而且要经过别人的手。

第一个可操作的结论由此而来。要判断自己在管理岗位上做得好不好，不是把做IC时用的指标丢掉，而是必须理解那些指标为什么会失灵。

个人吞吐量这个指标停止工作的三个原因

做IC时的自我评估方式基本上就是个人吞吐量。这周合并了什么，关掉了几个故障，写了几份设计文档。这个指标对管理者来说会因为三个原因而失效。

第一，它直接与你竞争。要维持个人吞吐量，就得砍掉用来创造团队产出的时间。把1on1往后拖、把招聘面试交给别人、把跟相邻团队的协调往后推，这周的个人吞吐量就能保住。在格鲁夫的等式里，这等于为了守住左边而削掉右边。

第二，团队的学习总量会减少。管理者亲自处理的活儿，通常是最难、最有意思、学习价值最高的那部分。截止日期临近时管理者把这件事接过来，短期看是英雄，但本该从中学到东西的人却没学到。Camille Fournier把"抓着技术决策不放、不肯授权"指为新任管理者的常见失败，说的也是同一件事（不过这篇文章的正文我没有直接核实，只确认了标题和主旨）。

第三，你会变成瓶颈。个人吞吐量高的管理者，会造出一批依赖自己审批、自己评审、自己知识的路径。这些路径会在管理者休假的那一刻暴露出来。

把管理幅度的数字叠上来，画面就更清楚了。Will Larson在Sizing engineering teams（2018年7月14日）中，把一位管理者能够主动辅导并协调的上限定在6到8人。再往上，大约超过8到9人之后，他写道管理者的角色就会从教练收缩成"出问题时的安全网"。反过来，少于4人他认为与其说是团队，不如说更接近一群个体。这些数字讲的不是组织架构图的形状，而是时间预算。6到8人这个区间，接近于把主动辅导所需的时间除以工作时长得到的结果，而个人吞吐量正是从这份预算里挤出来的。

反馈循环变慢，也变得难以判读

各种副作用的共同原因就在这里。整理成表格是这样的。

维度	IC	管理者
产出单位	已合并的变更、已恢复的故障	团队在一个季度里交出的结果
反馈延迟	分钟到天（CI、评审、部署）	周到季度（招聘的结果要半年，组织调整的效果要一年）
可读性	高。测试变红就是错了	低。团队运转顺畅到底是因为我，还是因为本来就聚了一批好人，无法区分
失败信号	立刻、自动送达	延迟送达，而且通常只能通过人送达
纠正成本	低。回滚即可	高。信任是无法回滚的

这张表里最重要的一行是可读性。如果只是延迟，忍一忍就过去了。真正的问题是信噪比。团队的成果里，除了管理者的贡献，还混进了招聘市场、产品方向、相邻团队的状态，以及纯粹的运气。所以好的季度未必能证明你有本事，坏的季度也未必能证明是你的错。

学习是反馈循环的函数。循环以季度计、噪声又大，那么实际上就无法形成监督学习。第二个可操作的结论由此而来。管理者的成长不会自然发生。你必须亲手造出观测手段。具体来说，有三样东西会有帮助。

决策日志。用一行字记下自己在什么时候、基于什么依据、预期什么结果做了什么决定。季度末把预测和结果对照一遍，就能从噪声里单独看出自己判断上的偏差。
先行指标。季度结果来得晚，但像坏消息在1on1里往上传得有多快、on-call交接有多安静、设计评审上会不会出现反对意见这些事，是以周为单位就能观察到的。
外部观察者。读取可读性低的信号，最便宜的办法就是定期去问那些从不同角度看同一个组织的人（同级的管理者、Staff工程师）。

头六个月反复出现的三种失败

在原文的十四条、HN评论以及被广泛阅读的管理文献中反复出现的失败模式，大体收敛为三种。

放不下个人吞吐量。这是最常见的。冲刺后半程亲自写代码去堵口子，难缠的故障亲自上手处理。正如上一节所见，这是拿短期收益去换长期损失的交易，问题在于这笔交易的损失那一侧要六个月后才看得见。反馈循环慢这个事实，正是这种失败能长期存活的原因。

误判自己话的分量。这是我认为原文里指得最准的部分。做IC时那句"这个是不是有点奇怪？"是一个问题，而管理者说出同样一句话，回来的就是两周的重构。声称自己没有下指令的意图，起不到任何辩护作用，因为这不是说话者意图的问题，而是听者风险计算的问题。可操作的解法是给意图贴上标签 — 每次都明说"我这是在出声思考，不是决定"，或者"这是一个决定"，会更好。

把难开口的对话往后拖。绩效问题如果在第一个季度不说，到下个季度就更难说出口。沉默拖得越久，在对方看来就越像一次突如其来的通知，到那时候，无论内容多有道理，都会变成程序上的问题。Camille Fournier在I hate manager READMEs（2018年11月23日）里的指摘在这里完全适用：信任不是靠一份自我介绍文档建立起来的，而是随着可预测且合乎伦理的行为不断重复而积累起来的。及时进行那些难开口的对话，正是这种重复的一部分。

HN评论里也有若干针对原文的反驳，其中三条确实值得记下来。一条评论正面反对原文中管理者必须"推销"糟糕决定这一主张，指出透明的管理者最终反而赢得更多信任，而被灌以虚假正能量的一方是看得出来的。另一条认为，资深IC同样要承担会议、干系人管理和无授权领导力这几乎相同的负担，所以原文划出的IC与管理者的边界比现实中更加分明。还有一条说，经验积累起来之后，动手做事和带人是可以兼顾的，并指出原文有把好候选人吓跑的风险。

去找数字，会发现几乎没有

这个话题上被引用得最多的数字是"新任管理者有60%会在24个月内失败"。它通常被挂在CEB（现Gartner）名下。写这篇文章时我去找了原始报告，结果是年份、样本、方法论一个都无法确认。有几十家媒体和博客在引用它，但它们全都在互相引用，没有任何一条链接能通向原始出处。把它当作僵尸统计数字来对待是比较安全的。经常被拿来一起引用的Leadership IQ那个46%的数值，确实是一项真实存在的调查，但它的对象是新入职员工整体，而不是新任管理者，所以不能原样搬到这个语境里。

反过来，也有出处清楚的东西。DDI的Global Leadership Forecast 2025是第十一版，在50多个国家调查了10,796位领导者和2,185位HR专业人士，其中承受压力的领导者中有40%回答说，曾经为了自身的身心健康而考虑过离开领导岗位。这是离开意愿而不是失败率，但至少样本和方法论是公开的。

老实写下来：关于工程师转做管理者之后又回到IC的比例，我没能找到可信的统计。广为流传的说法很多，但可供引用的调查一个也没有。这个事实本身就告诉了我们该怎么读这个话题 — 关于从IC走向管理者这段转变的建议，几乎全都是经验之谈，就该当经验之谈来读。其中很多彼此矛盾，原因也在于此。

如何判断该不该回到IC

这个话题的标准参照点是Charity Majors的The Engineer/Manager Pendulum（2017年5月11日）。核心有三点。管理不是晋升，而是横向移动到一条平行的轨道上；最好的一线工程管理者离开动手工作的时间不会超过两到三年；以及工程和管理一次只能精进其中一样。

这篇文章同样不是研究，而是一种视角。文中没有引用依据，作者自述的来源是当时与Sarah Mei的一次对话。有意思的是，我没能找到针对它的正面反驳，而这与其说意味着已经形成共识，不如说更接近于这个领域根本没有可证伪的数据。

在此基础上，如果加上我自己的看法，判断标准可以这样划分。

先看那些不足以构成回去理由的东西。这个季度很难熬不构成理由。正如前面所见，头六个月正是你第一次经历"反馈循环慢、判读困难"这种状态的时期，那份不适不是失败的信号，而是这个角色的默认值。怀念写代码本身也不构成理由，值得先确认一下它是不是靠周末项目就能消解的那一类。

我认为构成回去理由的有三条。

过去了十二到十八个月，团队的产出却和我来之前分辨不出差别。不过要作出这个判断，前提是你事先做好了上一节说的那些观测。没有观测就下的这个判断，通常只是当天的心情。
仍然想象不出管理者这份工作的"好日子"长什么样。如果你无法为自己定义什么样的一天算是过得好的一天，那么在这个角色里，改进的方向也就无从定义。
组织根本没有给管理者真正的杠杆。在招聘、薪酬、方向上没有权限，却只承担结果的责任，那么格鲁夫的等式就不成立。这不是个人适不适合的问题，而是位置的问题，换个位置更快。

如果打算回去，也要把代价一并看清。按照钟摆模型，来回摆动本身是资产，但确实有一样东西会失去 — 本可以花在资深IC轨道上的时间。当管理者度过的两年，不等于在Staff工程师轨道上度过的两年。这是钟摆模型处理得不太好的部分，做决定时把它计入账内才算诚实。

结语 — 把"不知道自己做得好不好"当作默认状态接受下来

整理一下：

成为管理者不是工作量增加，而是产出函数被替换。按照格鲁夫的定义，当产出变成团队的产出，活动与产出之间就挤进了人和时间。
其结果是反馈循环从分钟级拉长到季度级，信噪比变差。原文列出的十四种症状，大部分都由此派生。
个人吞吐量作为管理者的指标会因三个原因失效：它与时间预算直接竞争，它减少团队的学习总量，它制造瓶颈。
关于这段转变的建议大多是未经验证的经验之谈。广为流传的失败率统计，找不到原始出处。
要不要回到IC，用观测来判断比用心情判断更好，而那套观测要从转岗的第一天就搭起来才用得上。

运维过慢循环系统的人对这种感觉早已熟悉。在观测延迟很大的系统里，即刻的确信反而是危险信号。管理者这个角色也一样。每周都涌起"我做得不错"的确信，这并不是正常状态；不知道自己做得好不好才是默认状态，而工作就是在这之上叠加观测手段。