马斯克到底懂多少技术？聊聊“高密度人才组织“为什么是技术团队的天花板

前言

最近做技术招聘和带团队评审，有一个反复出现的画面：

10 人的小研发团队，把一个项目从 0 做到 1，干得又快又稳。等公司开始扩张，团队涨到 30 人、50 人、80 人，结果同样的迭代速度反而慢了 3 倍——会议从一天 2 个涨到一天 8 个，PR 评审从 1 天合掉变成卡 3 天，需求从想法到上线的周期从 2 周拉到了 8 周。

这不是工程师的问题，也不是管理工具的问题。这是一个组织从"高密度人才结构"滑向"草台班子结构"的典型过程。

最近翻到一篇知乎高赞回答（《马斯克到底懂多少技术？》），作者把这个现象归到了"反帕金森定律"和"高密度人才组织"上——一句话戳穿了这两年大家对马斯克"懂不懂代码"的误解。

读完这篇文章，结合我自己十几年带技术团队的观察，我想从一个研发管理者的角度，把这套逻辑往程序员和技术 leader 视角展开聊聊：

• 为什么马斯克"懂的技术"不是写代码，而是识别哪些程序员是真正有水平的
• 帕金森定律为什么会摧毁绝大多数 5 年以上的研发组织
• 一份研发团队官僚化的 6 个早期信号自检清单
• 高密度人才组织的真实案例：Valve、DeepSeek、巴菲特团队
• 技术 leader 在自己 30 人以下的团队里，具体怎么操作能避免组织熵增

不管你是 1-3 年的工程师、5 年以上的技术骨干、还是带 10-50 人团队的技术 leader，这套思考都用得上。

开整。

一、马斯克"懂的技术"，根本不是写代码

去年 DeepSeek 最火的时候，梁文锋说过一句话：“我们缺乏一种高密度人才的组织方式。”

我当时反复在想，什么叫"高密度人才的组织方式"？

后来想明白了——就是马斯克搞的几个公司的运作逻辑：第一性原理，简单直接，没有任何为了管理而管理的人员。

真正的科技精英是非常反感外行为了管理而管理的。一个技术团队，只要混入了一两个纯行政导向的管理者，就会不可避免地走向臃肿。

很多人问：马斯克一个 CEO，又不写代码，他到底懂多少技术？

我的看法和知乎那篇回答一致：他懂的根本不是写代码，而是识别哪些程序员是真正有水平的那种洞察力。

他把推特买下来之后，直接裁掉 80% 的人，只保留 20% 必须的程序员，后来又根据情况增聘了 5% 的程序员。这个操作的关键不是"裁员"本身，而是他能判断出哪些人是必须的、哪些人是充数的。

这就是我理解中"马斯克懂的技术"。

他不一定比工程师更懂某段代码怎么写，但他在几百个技术人员的组织里，能快速过滤出谁是创造价值的核心节点、谁在拖后腿。这种能力，比多写几万行代码对组织更有价值。

二、帕金森定律：每个 5 年以上的研发组织都会得的"熵增病"

帕金森定律（Parkinson’s Law）是 20 世纪西方文化三大发现之一。它的核心描述很简单：

一个不称职的官员（管理者），有三条出路——退位让贤、找一个能干的人当助手、找两个更无能的人当助手。

前两条都走不通：退位丢权力，找能干的人会变成自己的对手。

于是所有人都选了第三条：找两个更无能的人当助手。助手们又上行下效，再给自己招两个更无能的副手。结果就是机构每层都在膨胀，效率每层都在下降。

这个定律在研发组织里，比在传统企业管理里发作得更隐蔽，但也更致命。

原因是：技术团队里"能力差异"的跨度极大。一个优秀的工程师可能顶 10 个甚至 50 个普通的。如果组织机制允许管理者持续选"看起来听话但技术平庸的人"进入团队，3 年内就会形成一条"平庸堆积链"：

• 第 1 年：核心骨干发现周围新招的人跟不上节奏
• 第 2 年：骨干开始承担越来越多"帮别人改 Bug"的额外工作
• 第 3 年：骨干要么被累垮、要么主动离开
• 第 4 年：团队里全是"听话但不解决实际问题"的人

这个链条在互联网行业比传统行业更快——因为技术迭代速度快，人才流动性大。 你不需要故意搞官僚主义，只需要在招人时选"安全但不优秀"的人，帕金森定律就会自动运转。

反过来说，马斯克裁掉推特 80% 的人之后，系统没崩溃、业务没停摆——说明那 80% 的人，大概率就是帕金森定律制造出来的冗余。

裁掉冗余不是目的，让剩下的人有空间真正做事才是。

三、研发团队官僚化的 6 个早期信号（自检清单）

原文分析了帕金森定律的发作逻辑，但我想从一线技术管理者的角度，给出更具体的东西——当你的组织正在"变胖"时，早期有哪些信号？

我见过不少技术团队，从 10 人扩张到 30 人后，效率不但没提高反而下降了。复盘下来，以下 6 个信号出现 3 个以上，说明你的团队已经进入"低密度化"的通道：

1. 会议里讨论框架选型的人，比写框架的人还多

一个 10 人团队讨论技术选型，30 分钟搞定。一个 30 人团队讨论技术选型，可能开 3 场会还定不下来——因为参会者里有大量"虽然不写代码但需要发表意见"的人。

2. 制度化的流程开始替代工程师的判断力

“这个需求按要求排期就行，不用问为什么这么做。”——当工程师开始不质疑需求的合理性，只是机械执行时，团队就从"高密度组织"变成了"执行队列"。

3. 人均 PR 数量持续下降超过 2 个迭代

这是个可以量化的指标。如果你发现团队过去 6 周的人均 PR 合入量（剔除休假/新人入职）环比下降超过 20%，说明有人在无效忙碌——开会、写文档、走审批流程，这些都不产出代码。

4. 技术 leader 的大部分时间花在"协调"而非"决策"

技术 leader 一周的工作场景：80% 在协调不同小组之间的依赖关系，15% 在写周报/汇报，5% 在思考架构方向。这就是典型的帕金森症状——管理层在制造工作，而不是解决问题。

5. 一个简单需求的改动，牵涉 3 个以上的评审群

正常的研发组织中，一个前端样式改动的 PR 应该只需要 1-2 个人 Review。如果你发现一个按钮换个颜色需要拉 5 个人进群、对齐 3 个小组、审批 2 轮——说明组织的复杂度已经超越了业务复杂度本身。

6. 新人的产出贡献周期从"2 周"拉长到"3 个月"

这是最隐蔽但最致命的一个信号。高密度的 10 人团队，一个中等水平的应届生入职 2 周就能开始贡献有效代码。而一个开始官僚化的 30 人团队，同样的新人可能 3 个月后还在"熟悉业务"——因为他的代码需要经过太多人的评审，每层评审的人都会出于"自保"心态挑一堆无关紧要的问题。

如果你发现团队出现了 3 个以上信号，不要急着买新的项目管理工具，也不要组织更大规模的团建。回到最底层的问题：你的团队里有多少人在创造价值，多少人只是被帕金森定律"制造"出来的？

四、为什么"控制技术精英"是最贵的内耗

原文里有个观点很犀利：

“我们为什么要控制科技工作者？我们为啥要向一个高密度的人才组织里掺沙子去降低效率？”

这句话戳到了不少国内技术团队的隐痛。

很多公司在管理上有一种潜意识——“必须有人盯着工程师”。于是给一个 5 人的小组配 1 个项目经理、1 个产品经理、1 个 QA leader、1 个技术总监，4 个管理岗位监督 5 个开发。结果不是"管得更好"，而是每个开发的有效编码时间从一天 6 小时缩到 3 小时。

这种"控制"的代价，其实远比不"控制"高——

• 真正有水平的工程师最反感被外行管理，他们会用脚投票（要么离开，要么消极怠工）
• 留下来的工程师会"演"给管理者看（写华丽的周报、做形式主义的复盘），但代码本身的质量在下降
• 组织对外部市场的反应速度变慢——因为每一个决策都要走 4 层审批

更关键的是，技术精英的稀缺性远高于管理者的稀缺性。

知乎那篇回答里举了一些例子：

• 美国某公司给一个中国 AI 专家开年薪 1 亿美金
• 马斯克的董事会给他 1 万亿美金的薪酬包（虽然主要是期权）

很多人会批判美国是"个人英雄主义"。但在科技领域，这种"个人英雄主义"是有数据支撑的——一个数学天才解决一个数学难题，可能比 10 亿普通人加起来花几十年都管用。

例子：可回收火箭技术为什么直到最近几年才搞成？因为里面最关键的数学问题之一直到 2013 年才被解决。在数学问题没解决之前，你堆再多的工程师都没用。

这套逻辑放到日常的研发团队同样适用：

• 一个真正能搞定核心算法的工程师，比 10 个写 CRUD 的工程师对项目价值更大
• 一个能在架构层面提前避坑的架构师，比 5 个事后救火的中级工程师对系统稳定性更关键
• 一个能识别并保留这种核心人才的技术 leader，比一个忙着开会汇报的管理者对组织未来更有意义

承认精英价值，给精英相称的回报，不是个人英雄主义，是对组织效率的诚实。

五、高密度人才组织的几个真实案例：Valve、DeepSeek、巴菲特

原文最后举了几个高密度人才组织的真实例子，我把它们和我自己的观察对照展开。

1. Valve：几百名工程师，没有经理

Valve 公司是个非常特别的样本——代表作品包括《半条命》《反恐精英》《Dota 2》《求生之路》，以及 Steam 平台。2025 年 Steam 日均新增付费用户达 10.9 万，同时在线峰值突破 4000 万。

而支撑这一切的内部组织，是几百名顶尖工程师，没有经理、没有主管、甚至没有"汇报线"这种东西。

它的核心机制：

• 无层级结构：所有人平等，员工自己选择项目
• 自我驱动文化：你认为某个东西重要，就直接去做
• 内部人才市场：项目缺人时，自己去说服别人加入
• 信息极致透明：内部所有项目数据全员可见
• 同行评价体系：年度考核由同事互评，不是上级打分
• 失败容忍生态：尝试失败的项目不会成为黑历史

这种组织看起来"乱"，但实际上对真正高水平的人才最友好——你不用花时间证明自己"忙"，只需要证明自己"有产出"。

2. DeepSeek：150 人，做出能和 OpenAI 对标的大模型

梁文锋的 DeepSeek 团队只有 150 人，搞出来 DeepSeek-V3、DeepSeek-R1 这一系列在国际上有竞争力的模型。同时还运营着幻方量化的核心策略。

对比一下：很多互联网大厂的 AI 部门动辄 500 人、1000 人，但产出却跟不上。

这不是 DeepSeek 的人比大厂的人更聪明，而是150 人的组织里，每个人都得真的产出，没有冗余位置可以躺。

3. 巴菲特投资团队：20 多人管几千亿美元资产

伯克希尔·哈撒韦的核心投资团队大概只有 20 多人，但管理着几千亿美元的资产。

这里的关键不是"人少"，而是这 20 多个人都是能独立做出投资决策的人。每个人都不是螺丝钉，每个人都是发动机。

4. 反观国内不少互联网公司的研发部门

我观察过国内一些大厂的中层架构：

• 一个普通业务线，配 3-5 个项目经理、2-3 个产品经理、1-2 个技术总监
• 实际写代码的工程师可能只有 15-20 人
• 但部门总人数能达到 40-50 人

这种结构在业务高速增长期还能掩盖问题，一旦业务进入平稳期，冗余结构就会成为首先被砍掉的对象。

我说这些不是要鼓吹"裁员是对的"。我想说的是——与其等到业务出问题再被动裁员，不如从一开始就把组织维持在高密度状态。

六、技术 leader 怎么把团队往"高密度"方向带

前面讲了帕金森定律是怎么发作的、高密度组织长什么样。但很多人会说：道理我都懂，可我自己只是个 10-30 人团队的技术 leader，不是 CEO，怎么操作？

我把自己的方法论总结成 5 条可执行原则。

1. 招人的时候，宁缺毋滥

帕金森定律的起点是"招了一个不合适的人"。一旦招进来，再想清出去成本极高（HR 流程、人际关系、团队心理）。

具体准则：

• 招人时至少 3 个面试官达成共识，任何一个明确反对就不要
• 拒绝"业务紧急、先招进来再说"的妥协——紧急招进来的人，2 年后大概率成为团队的负担
• 候选人的"上限"比"下限"重要——一个有上升潜力的初级工程师，比一个稳定但无潜力的中级工程师更值得招

2. 评估方式从"工时"切到"产出"

很多团队的评估方式还停留在"谁加班多"“谁会议多”，这就在系统性鼓励冗余。

具体操作：

• 周会从"每个人讲讲做了什么"改为"每个人讲讲解决了什么问题"
• KPI 中至少 50% 是可量化的产出（PR 合入数、Bug 修复数、需求交付周期）
• 明确告诉团队：会议、文档、汇报，本身不产生价值，只有真正交付的东西才算数

3. 给核心工程师"反官僚特权"

如果你的团队里有 1-2 个真正的技术骨干，给他们：

• 拒绝无意义会议的权利——他们可以选择不参加大部分会议
• 跨部门直接沟通的权利——不用什么事都走 leader 转交
• 挑战决策的权利——他们说"这个方向不对"时，你必须认真听

这看起来像是"给特殊人物特权"，但实际上是让组织里最有价值的人有空间继续创造价值。

4. 定期"反熵增审查"

每 6 个月做一次组织审查，问自己几个问题：

• 上半年新增的会议有几个是真正必要的？
• 团队里有没有"位置在但产出说不清"的人？
• 决策链路有没有变长？过去 1 周决定的事情，是不是 3 个月前用 1 天就能定？

发现问题就果断处理：取消会议、调整人员、压缩流程。不要等组织自己变好——熵增是单向的，必须主动反熵增才能维持高效。

5. 自己以身作则——少开会，多写东西

技术 leader 最容易掉进的陷阱是：成天开会、不再写代码也不再深度思考。然后下属的工作方式会自动模仿你。

具体做法：

• 每周至少留出 1-2 天"无会议日"，自己也写代码或者深度复盘技术问题
• 把"我在思考 XX 架构"作为日常对外输出，而不是"我在协调 XX 项目"
• 写技术博客、做内部分享——让团队看到你还在保持技术敏感度

leader 自己保持高产出状态，团队才会保持高密度状态。这是最隐蔽但最有效的反熵增手段。

七、现实里的"草台班子"：管理学的另一半真相

前面讲了那么多"高密度组织好"，但要承认一个事实：现实里 90% 的组织根本不是高密度的——它们是"草台班子"。

原文作者讲过一句话很到位：“100% 的工地，99% 的工厂，和大多数企事业单位都是草台班子。”

圈子里能看到的不少传统行业 IT 项目，确实是这种状态——人员水平参差不齐，岗位职责模糊，质量标准不清晰。

对草台班子来说，管理是必须的。

海尔创始人张瑞敏当年定的第一条管理制度是"不准随地大小便"。我看了之后没觉得是笑话，反而觉得很真实——管理这件事，得看你管的是什么人。

对一个真正的高密度技术团队，过度管理是诅咒；对一个草台班子，缺少管理是灾难。

所以这套"反帕金森"的逻辑不能粗暴套用——

1. 你需要先判断自己团队的真实水平

• 团队里 80% 以上是技术骨干水平 → 适合高密度模式，少管多放
• 团队里 50% 左右是技术骨干，剩下是中等及以下 → 混合模式，给骨干自由，给一般水平的人明确流程
• 团队里大部分是初级、外包、跨行人员 →必须靠管理体系兜底，否则交付质量不可控

2. "高密度"是目标，不是起点

如果你接手一个新团队，发现现状是后两种，正确的做法不是立刻搞"无层级 Valve 模式"，那会立刻乱套。正确的做法是：

• 先用流程稳住质量基本盘
• 通过淘汰 + 招聘逐步替换人员结构
• 团队骨干浓度上来后，再逐步取消多余的管理层级

这个过程一般需要 1-2 年。

3. 警惕"假高密度"

有些团队对外宣称扁平化、无管理，但实际上：

• 老板大权独揽，所有决策都要拍板
• 没有人敢挑战决策
• 表面上自由，实际上是恐惧文化下的伪自由

这种比传统层级组织更糟糕——既没有层级带来的清晰责任，也没有真正高密度团队的创新空间。

4. 钱学森之问，本质是组织生态问题

著名的钱学森之问：“为什么中国教育培养不出世界顶尖人才？”

我个人的看法：人才本身一直都有，但社会整体的组织生态没能给真正的人才提供宽松、自由、不被外行压制的环境。

这是一个超出技术 leader 能影响的范围，但作为技术管理者，我们至少能在自己 30 人以下的团队里，尽量做到这一点。这也算是对"反帕金森"理念最实际的实践。

总结

回到最开始那个问题——马斯克到底懂多少技术？

我的答案：他可能不写代码，甚至读代码都未必比一个高级工程师快。但他懂的是比写代码更稀缺的东西：在几百个技术人员的组织里，能识别真正有价值的那 20%，并且敢于把剩下的 80% 砍掉。

总结全文 5 个核心观点：

1. 马斯克"懂的技术"，本质是识别真正有水平的工程师并把他们放到合适位置上的洞察力——这种能力比写代码更稀缺。
2. 帕金森定律是研发组织最隐蔽的杀手——不需要任何人故意搞官僚主义，只要在招人时持续选"安全但平庸"的人，3-5 年内组织就会自动臃肿。
3. 研发团队官僚化有 6 个早期信号——会议堆叠、流程替代判断、人均 PR 下降、leader 时间被协调耗光、决策链路变长、新人产出周期拉长。出现 3 个以上就要警惕。
4. 承认精英价值不是个人英雄主义，是对组织效率的诚实——一个核心工程师顶 10 个普通工程师是真实的，给他们相称的回报和环境，是高密度组织的基础。
5. 技术 leader 在 10-30 人团队层面，至少能做 5 件事反熵增——招人宁缺毋滥、评估改成产出导向、给骨干反官僚特权、定期反熵增审查、leader 自己保持高产出状态。

最后一句留给读者：不是每个团队都能成为下一个 Valve、DeepSeek，但每个技术 leader 都能让自己手里的 10-30 人团队，比 5 年前的同等规模团队更密度、更有产出。

如果这篇文章让你想起了自己团队里的某个画面，欢迎评论区聊聊：你觉得自己团队现在是"高密度状态"还是已经在向"草台班子"滑了？