事业部制的陷阱

一、一个简单的问题，没人能回答

2026年3月，前微软技术院士Jeffrey Snover发表了一篇长文，题为《Microsoft Hasn't Had a Coherent GUI Strategy Since Petzold》（自Petzold以来，微软就没有过连贯的界面技术策略）。Snover在微软工作了23年，从架构师一路做到技术院士，是PowerShell的发明者。这个人对微软内部的运作方式，比绝大多数局外人理解得深刻得多。

他在文章开头讲了一个场景：几年前，他参加了一场内部开发者会议，有人问了一个看似再简单不过的问题——"如果要做一个新的Windows桌面应用，应该选哪个技术方案？"

全场沉默。三个人给出了三个不同的答案，会议跑偏了，问题始终没有被回答。

Snover说，这个沉默本身就是答案。当一个平台连"你应该怎么开发应用"都回答不了的时候，它已经辜负了它的开发者。

然后他把过去三十多年Windows开发技术的演进历程一一拆开，摆到了台面上。1988年，Windows开发只有一种标准做法——一个操作系统，一套接口，一种语言，一本教程，所有开发者遵循同一套规则。到了今天，Windows上同时存在着17种开发技术方案、5种编程语言、3种完全不同的渲染方式。他给这种状态造了一个词叫"boof-a-rama"：一群极其聪明的人，共同制造了一个极其愚蠢的结果。

这篇文章在技术圈引发了广泛共鸣。无数开发者经历过类似的痛苦——自己投入精力学习和使用的技术，突然被微软宣布放弃，而替代方案可能两年后也会被放弃。但大多数讨论停留在对微软的吐槽上，很少有人追问一个更根本的问题：为什么会这样？

Snover自己给出了诊断："组织失败才是真正的产品。"这个判断完全正确。但诊断病因和设计治疗方案是两种不同的能力。他准确地指出了病根在组织层，却没能给出组织层的解法——谁来统一技术方向？用什么机制保证方案被执行？怎么防止下一个副总裁在下一场发布会上再次推翻它？这些问题需要的是组织架构的设计经验，不是一个工程师的知识体系能覆盖的。

二、混乱的根源：事业部制下的技术内战

微软的技术碎片化不是技术问题，是组织架构问题。

鲍尔默时代的微软采用典型的事业部制。Windows是一个利润中心，Office是一个利润中心，开发者工具是一个利润中心。每个事业部有自己的损益表、自己的副总裁、自己的战略、自己的技术团队。

当多个事业部共享同一批开发者作为"客户"时，它们之间的关系就不是协作，而是竞争。每个副总裁都需要在年度开发者大会上讲一个足够震撼的故事来证明自己部门的价值，争取更多的资源和人头。Snover给这种现象起了另一个名字——"发布会主旨演讲式灾难"：微软很多技术决策的优化目标，是让某个高管在台上讲出一个足够精彩的故事，而不是让开发者真正能用这个技术成功交付产品。

Windows团队和开发者工具团队之间的内战持续了13年，Office团队则在两者之间反复摇摆，哪边势头大就倒向哪边。导火索是2004年一个代号为Longhorn的重大项目失败。微软原本计划在下一代Windows中全面采用新的开发框架来重写图形界面。项目失败后，管理层把责任归咎于新框架，于是下了一道内部禁令——Windows里不许再用这套方案。

但开发者工具团队已经花了数年心血打造这个框架，技术上确实是优秀的。它在2006年随Windows Vista发布，但Windows团队拒绝在自己的产品中使用它。Windows自身的界面不用，Office不用，连微软自己的旗舰产品都不用——开发者凭什么相信它是未来？

此后的故事就是一连串的推翻和重来。2007年，微软推出一套新方案去对抗Adobe Flash。2010年，一个高管在公开场合突然宣布这套方案战略收缩，团队事先不知情。2012年的开发者大会更加混乱，台上同时传达了六个方向——六个团队各自宣称自己代表未来，互相矛盾。Snover评论说，这不是战略，这是一个饥饿游戏的舞台，六个团队在争夺你的注意力。

14年间，微软在技术方案的官方推荐上转向了14次。不同部门各自为战，向开发者传递相互矛盾的信息。最终结果是Windows平台上同时存在着17种开发技术——最讽刺的是，其中部署量最大的那个，是一个微软根本没有参与创建的第三方方案。

这些技术中的每一个，单独拿出来看，都不算差。它们不是死于技术竞争，而是死于组织内耗——死于两个副总裁之间在争夺什么资源，死于某个发布会需要什么样的故事，死于开发者被反复当作最后知情人。

事业部制把"用什么技术"这个需要长期一致性的决策，变成了短期政治博弈的筹码。每个新上任的副总裁都需要"自己的故事"，而最容易讲的故事就是"我们有一个全新的方案"。至于上一任副总裁推的方案和那些已经投入其中的开发者，没人在乎。

界面框架只是这种病变最极端的表现。同样的逻辑在微软的即时通讯、AI助手、身份认证等领域反复上演——不同事业部各自造轮子，互相争夺资源，用户和开发者无所适从。Snover的文章揭开的是冰山一角，冰山下面是整个公司级别的技术碎片化。

三、苹果反例：职能制可以驾驭超大规模

同样是超大规模科技公司，苹果在平台级技术方向上从未出现过类似程度的碎片化。

苹果是全球市值最高的几家公司中唯一采用纯职能制组织架构的。没有iPhone事业部，没有Mac事业部，没有Services事业部。整个公司按职能组织——硬件工程、软件工程、设计、市场营销、运营，所有产品线共享同一套职能资源。

Craig Federighi作为软件工程高级副总裁，统管iOS、macOS、iPadOS、watchOS、visionOS所有平台的框架和开发工具。不存在"iOS团队和macOS团队争抢开发者注意力"的情况——因为这两个团队在组织架构上属于同一个部门，由同一个人负责。

苹果的界面技术演进路径清晰得多：Cocoa和AppKit起步，UIKit覆盖移动端，SwiftUI统一未来方向。Objective-C到Swift的语言过渡花了十年，但方向始终没变过。旧框架持续维护但不鼓励新项目使用，新框架有明确的迁移路径和长期承诺。没有哪个高管会在开发者大会上突然宣布SwiftUI不做了、以后改用HTML。

这种一致性不是靠协调会议谈出来的，是组织架构天然保证的。没有产品级的损益表，就没有副总裁争抢技术控制权的动机。硬件工程高级副总裁不需要证明"我的部门赚了多少钱"，他只需要证明"我交付的芯片性能是最好的"。

苹果证明了一件事：职能制不是小公司的专利，它完全可以支撑三万亿美元的市值。

当然，苹果的"方向清晰"也受益于它封闭生态的强势地位——它敢于直接废弃旧技术、强制开发者迁移，而微软背负着沉重的向下兼容包袱。但两家公司经历了同样的技术周期震荡——从桌面到浏览器再到移动端。面对同样的外部压力，苹果的职能制让它用一个统一的决策来应对迁移，微软的事业部制让每个团队各自应对，结果是六个方向同时宣布。外部压力相同，组织架构决定了压力传导之后的结果是收敛还是发散。

回头看微软，从面向用户的产品条数看，它和苹果其实在同一个量级——Windows、Office、Azure、开发者工具、游戏、LinkedIn，六条线。苹果是iPhone、Mac、iPad、Watch、Services，五条线。微软之所以看起来"复杂"，不是因为业务真的复杂，而是事业部制人为制造了复杂性。同一个界面框架的问题，被Windows团队、Office团队、.NET团队、Edge团队各自解读为"自己的问题"，各自给出"自己的答案"。这不是业务复杂性，是组织病变伪装成业务复杂性。

事业部制不是大公司的必然选择。很多时候，它是一个不必要的、代价高昂的选择。

四、事业部制的三个隐性陷阱

事业部制的表面收益非常明确：聚焦、责任清晰、决策快。这些好处是真实的，也正因如此，几乎所有公司在业务线增加到两三条的时候，都会本能地考虑拆分事业部。

但隐性成本是滞后的、累积的，而且往往等你发现的时候已经积重难返。

第一个陷阱是技术碎片化。

各事业部独立选型，技术栈开始分叉，基础设施重复建设。分布式事务一致性的坑，A团队踩过了，B团队两年后又踩一遍，因为两个团队互相不知道对方做过什么。每个事业部从头做起，用自己的时间和血汗重新发现公司其他团队早已解决的问题。公司级的技术积累无法形成，每个事业部都在海拔零米起步。

微软的界面技术碎片化就是这个陷阱的极端表现。但即使在没那么极端的情况下，两三个事业部各自维护一套类似的中间件、各自搭建一套类似的数据平台、各自招聘一批做类似事情的工程师，浪费已经在发生了。

第二个陷阱是信息黑箱。

事业部负责人集产品、市场、商务、客服的信息于一身。他向上汇报什么、不汇报什么、怎么解读数据，完全由他一个人控制。CEO看到的不是业务的真实状态，而是事业部负责人选择让你看到的状态。GE在韦尔奇时代大力推行事业部制，各业务集团CEO权力极大。GE Capital的高管连续多年用金融工程手段粉饰报表，向总部呈现稳定增长的假象，直到2008年金融危机彻底暴露了底层资产的风险。总部在此之前几乎完全依赖事业部自己的汇报来评估业务健康度，等到发现问题的时候，窟窿已经大到需要联邦政府救助。

这比中央集权更危险。中央集权至少信息是往一个点汇聚的，决策质量取决于那个点的判断力。事业部制下信息往多个点汇聚，每个点都有动机美化自己的叙事，CEO反而成了信息最不充分的人。

职能制下这个问题要轻得多。产品知道用户要什么，市场知道渠道效果如何，商务知道客户真实反馈，客服知道实际投诉量。没有任何一个人能垄断全部信息。正因为没有人有完整的拼图，重大决策就必须把各方拉到一起，各自摆出自己手里的信息，集体讨论。任何一方想隐瞒或美化，其他方的数据会形成交叉验证。事业部制摧毁的正是这种纠错机制。

第三个陷阱是人才锁死。

工程师被绑定在单一事业部内，组织架构天然限制了他的视野和接触面。他只了解自己事业部的业务、用户和技术决策逻辑，对其他事业部的情况一无所知。跨事业部调动和外部招聘几乎没有区别——都需要从零开始熟悉业务上下文。公司花了三五年培养一个人，这个人积累的组织知识却只在一个事业部内有效。知识停止在组织内流动，每个事业部变成信息孤岛。优秀工程师的成长天花板被限制在一个事业部的业务范围内，而非整个公司的技术全景。

这三个成本都是滞后显现的。拆分的第一年，你只看到"团队更聚焦了"、"决策更快了"的好处。第二年，技术栈开始分叉，但还没到不可收拾的程度。第三年，信息壁垒成型，CEO开始发现自己对某些业务的真实状态越来越模糊。第五年，两套基础设施的维护成本已经大到无法忽视，但合并的成本更大。等到了微软那种程度——三十年积累、十几种技术共存——改革的成本已经超过了几乎任何人的承受能力。

五、职能制的边界与事业部制的正确使用场景

指出事业部制的陷阱，不等于说职能制是万能解药。前面用苹果做对照，不是说微软应该完全照搬苹果——而是说微软在界面技术这个本应统一的领域，不该用事业部的逻辑来切分。事业部制有它的适用场景，关键是边界画在哪里。

职能制的有效前提是产品线相对收敛，产品之间共享大量技术底座。苹果能用职能制，是因为iPhone和Mac共享芯片架构、共享操作系统内核、共享开发框架、共享云服务。一致性本身就是苹果最核心的竞争力——用户买的不是单个设备，而是一个设备之间无缝协同的生态体验。职能制天然保证了这种一致性。

但当产品线数量膨胀、业务差异大到共享资源的收益小于协调成本时，职能制会变得笨重。所有产品排队共享同一批职能资源，排期冲突不可避免。不同产品对同一个职能的需求差异大到无法用同一套流程服务。这时候职能制的协调成本开始超过事业部制的碎片化成本。

判断标准不是公司规模，是业务线之间的技术协同需求强度。

腾讯的社交、游戏、云服务、内容，面对的用户群和竞争对手完全不同。游戏团队需要的决策速度和试错空间，与企业云服务截然不同。强制把这些业务统一在一个职能架构下，确实会牺牲灵活性。这种情况下，事业部制是合理的选择。

一个简单的判断方法：如果两条产品线的工程师互换之后需要重新学习大量领域知识才能上手，说明业务差异已经大到值得拆分。如果互换之后很快能上手，说明底层是相通的，不该拆。

微软的问题不是不该有事业部——Azure和Xbox确实面对完全不同的市场。微软的问题是在不该拆的地方拆了——Windows和Office的界面技术本应统一，.NET开发者工具本应是公司级基础设施而非某个事业部的地盘。

事业部制的真正危险不在于它本身，而在于它符合直觉却不符合逻辑。公司有了两三条相似的业务线，把它们拆开各自负责，听起来天经地义——聚焦、责任清晰、决策快。但相似的业务恰恰意味着底层技术高度相通，拆分带来的碎片化成本远大于聚焦带来的效率提升。越相似的业务，越不应该拆。在产品线不多的时候坚持职能制，不是懒惰，是一种需要判断力的克制。

六、科技公司如何避免事业部制的陷阱：强总部与技术治理

当产品复杂度确实高到需要事业部制时，问题就变成了：怎么拆才不会掉进陷阱？

答案是：事业部制本身不是错，错在拆分之后总部放弃了技术控制权。

对于科技公司而言，技术标准和基础设施是所有业务线的公共地基。这块东西一旦碎片化，每个事业部都在海拔零米重新起步，公司级的技术积累归零。更重要的是，公司级的技术标准和基础设施，对员工而言是极佳的学习资源——新人不需要从零摸索，前人踩过的坑和积累的最佳实践就在那里；对企业而言是高价值资产——它可以被持续积累、持续增值，不随某个工程师的离职而消失。

正确的分工是：事业部负责业务决策，总部负责技术标准和关键基础设施。总部决定"用什么建"，事业部决定"建什么"。现实中两者的边界不可能完全清晰——事业部会抱怨标准方案不满足特定需求，总部会质疑事业部的偏离是否合理——但只要分工原则明确，争议可以通过机制解决。怕的不是争议，而是根本没有这条分界线。

这种分工的逻辑并不新鲜。军事组织几千年的演化早已把类似问题想透了。军部不直接打仗，但它统一管控情报、通信、后勤补给和火力协调——没有哪个团会自己建一套后勤供应链，也没有哪个营会自己搞一套通信系统。各作战单位在战术层面有充分的自主权，但共享军部提供的基础支撑。没有军部，每个作战单位都只是一支孤军。企业的强总部也是一样：它不直接做业务，但它提供的技术底座和治理体系，决定了每个事业部是在海拔零米起步，还是站在公司级积累之上。

最早把这个原则做到极致的是亚马逊。2002年，贝索斯发了一封内部邮件，要求所有团队的功能必须通过标准化的服务接口对外暴露，团队之间不允许直接读取彼此的数据库，不允许任何后门，不遵守的人会被开除。这封邮件用技术架构的硬约束倒逼出了组织行为的改变——当团队之间只能通过接口通信时，基础设施就真正变成了"地面"而非"同事"。更重要的是，亚马逊内部的基础设施团队同时服务内部业务和外部客户，内部按量计费。做着做着，这套内部基础设施就演化成了亚马逊云服务——对内对外一个标准，外部市场的竞争压力倒逼内部技术持续进化。

腾讯不是没有尝试过。技术工程事业群TEG的初衷就是为全公司提供统一的技术底座。但TEG被设为与业务事业群平级的组织，既不是业务——没有客户、没有收入、没有市场压力，也不是总部——没有强制力、没有审计权。一个基础设施部门跟业务线"协商"技术采纳，结局从定位那天就写好了。各业务事业群纷纷绕过TEG自建方案，TEG越被绕过越没有价值，越没有价值越容易被绕过。方向没错，但组织定位错了。更深层的问题是：腾讯的业务线之间明明存在大量技术协同需求，却在实际运作中让各事业群完全自治——本质上是一家伪装成事业部制的集团公司。

亚马逊做对了什么，腾讯做错了什么，差异其实可以归结为几个具体的机制设计。

第一，统一代码管理平台是一切的起点。没有全公司代码的可见性，重复建设无法发现，最佳实践无法流动，技术审计也无从谈起。Google把全公司代码放在一个仓库里，任何工程师可以搜索和阅读任何团队的代码——不一定要做到这个程度，但代码的跨团队可检索和可发现是必要的。当一个团队正在解决的问题可以被其他团队看到时，重复建设会被自然发现，而不需要等技术委员会年底来审计。

第二，基础设施应该对内对外一个标准，事业部按量付费使用。这一点是腾讯TEG模式和亚马逊模式的根本区别。TEG是免费的内部服务，资源分配靠政治协商——谁的副总裁声音大谁拿到资源，没有人考虑成本，也没有人有动力优化服务质量。付费模式下，资源分配靠价格信号。事业部不会滥用资源，因为要花自己的利润来买；基础设施团队不需要论证自身价值，因为收入数字就是价值证明；服务质量有天然的反馈机制——你服务差了，事业部的用量会下降。市场机制替代了政治博弈，效率自然提升。

第三，技术委员会负责定标准、做审计、沉淀最佳实践。成员应该从各事业部一线技术骨干中轮岗抽调，保持活水，避免脱离业务变成官僚机构。定期对各事业部的技术栈进行审计，发现重复建设和不合理的偏离。所谓"沉淀最佳实践"，不是在文档库里堆积没人看的过期文件，而是维护一个经过审核的、可检索的技术决策知识库——每个重大选型为什么选了这个方案、放弃了哪些替代方案、在什么规模下遇到了什么瓶颈、怎么解决的。新项目启动时先查这个知识库，很多已知问题不需要重新踩坑。这些信息在公开互联网上找不到，是企业独有的知识资产。

第四，事业部默认使用公司级技术标准，不用可以，但需要提出充分理由并存档。举证责任在偏离方，而非遵守方。这种"默认遵守、偏离需解释"机制的精妙之处在于，它既不是一刀切的强制统一——那会扼杀合理的业务特殊需求，也不是完全放任——那会回到各自为战的碎片化。它把选择权留给了事业部，但把举证成本加在了偏离的一方。大多数时候，当事业部被要求写清楚"为什么标准方案不够用、自建方案的成本是多少、未来如何保持接口兼容"时，他们会发现标准方案其实够用。

这四个机制合在一起，恰好对应了前面提出的三个隐性陷阱。统一代码平台和"默认遵守、偏离需解释"机制直接遏制技术碎片化。内部付费用市场信号替代政治博弈，削弱了信息黑箱的土壤。而当所有事业部共享同一套技术底座时，工程师跨事业部流动不再需要从零学起，公司级的知识积累对每个人都可用——人才锁死的问题从根源上被缓解了。

但强总部的职能不只是自上而下的管控，还有一个同样关键但更容易被忽视的方向：自下而上的能力吸收。事业部在一线业务中经常会发展出有价值的技术能力——某个团队为了解决自己的特定问题，做出了一套高效的方案。如果没有强总部，这个能力就永远锁在那个事业部内部，其他有类似需求的团队只能自己从零再造一遍。

发现这些能力需要两条通道同时运转。一条是自上而下的：技术委员会通过定期审计和统一代码平台的可见性，主动识别各事业部中有复用价值的技术方案。另一条是自下而上的：建立类似技术提案的机制，让一线工程师和团队可以主动提交自己认为有通用价值的方案，由总部的技术委员会评审。通过评审的方案，提出者应该获得对应的激励——可以是物质奖励，更重要的是职业通道上的认可：让提出方案的人直接进入总部，组建团队负责把这个能力抽象和系统化。最了解一个方案的人就是写它的人，由他来主导系统化，质量最高、效率最高。同时这也为一线工程师打开了一条不走管理路线也能影响全公司技术方向的成长通道。

这个机制天然地解决了两个难题。第一是总部技术团队的来源问题。总部的技术骨干不能靠外部招聘来组建——真正优秀的人在市场上极度稀缺，就算高薪挖来，他对公司的业务、代码和历史决策一无所知，也缺乏内部权威。从一线涌现出来的人完全没有这些问题：他的技术成果就是他的权威来源，他对业务有深度理解，进入总部几乎零磨合。总部不需要去市场上抢人，只需要建立一个让优秀的人能被发现的机制。第二是优秀技术人才的职业生涯问题。工程师在事业部做到一定程度就碰到天花板——要么转管理，要么在同一个业务范围里重复。总部提供了第三条路：不管人、不做业务，专注于把最有价值的技术能力做到极致，影响范围从一个事业部扩展到全公司。总部同时也是一个天然的人才储备池——这些人积累了跨事业部的全局视野，当公司需要开拓新方向时，他们比任何只在单一事业部待过的人都更适合去带队。

不管是哪条通道发现的能力，总部的工作都是一样的：把它从特定业务代码中抽离出来，剥离业务逻辑，抽象成通用的、文档完备的基础服务，纳入公司级技术底座。这个过程如果能持续运转，就形成了一个飞轮：事业部在一线产生创新，总部识别并吸收有复用价值的创新，抽象成通用能力纳入技术底座，所有事业部站在更高的起点上继续创新。每转一圈，公司级的技术底座就厚一层。亚马逊的很多云服务就是这样诞生的——不是总部凭空设计的，而是某个业务团队先在实战中做出来，然后被抽象成通用服务，最终对外开放成了云产品。

字节跳动是目前最接近这个方向的中国科技公司。它保留了独立的事业部——抖音、飞书、TikTok等各自运营，但基础架构团队是全公司统一的，支撑所有产品线，管理百万量级服务器。所有事业部必须跑在同一套基础设施上，不允许自建替代方案。同时，这套基础设施通过火山引擎对外提供商业云服务，内部和外部使用同一套标准，外部市场的竞争压力倒逼内部技术持续进化。

在信息治理上，字节采用"提供上下文而非下达指令"的透明机制——OKR全员可见、跨部门协作不需要领导审批、组织层级极度扁平。这在很大程度上避免了事业部制常见的信息黑箱问题，让事业部的业务自主权和总部的技术管控权实现了并存。不过需要指出的是，这套模式能运转有一个前提：极高的人才密度和严格的绩效淘汰。"给上下文而不给指令"要求每个人都有能力基于上下文做出好的判断，这不是任何公司都具备的条件。

但不管具体做法如何，技术治理体系都需要持续的压力和活力来维护。技术标准一旦制定就开始贬值——技术在演进、业务在变化、行业在迁移，标准如果不更新就会沦为没人看的过期文档。内部付费客户的需求反馈、外部云服务的市场竞争、技术委员会的定期审计，三重压力叠加，才能让技术标准和基础设施成为一个活的、持续增值的系统，而非一份死的规章制度。

七、多元化集团：当协同需求归零

还有一种情况，比腾讯的产品多样性走得更远：业务线之间不仅产品不同，连技术底座、用户群、市场逻辑都完全没有交集。

铁路公司和保险公司之间不需要统一代码平台。糖果公司和能源公司之间不需要技术委员会。珠宝零售和航空发动机之间不存在任何技术协同的可能性。

这时候强总部的协调成本大于收益。统一技术标准没有意义，因为没有什么可以统一的。统一基础设施没有意义，因为每条业务线的技术需求截然不同。

正确的选择是集团制——总部只做两件事：资本配置和CEO选拔。资本配置决定把钱投向哪些业务，CEO选拔决定让谁来经营这些业务。其余一切完全放权给子公司。

伯克希尔·哈撒韦是这个模式的极致体现。总部大约30个人，管理着近四十万员工的商业帝国。巴菲特的核心洞察是：大多数决策不应该由总部做。子公司CEO全权负责自己的经营，利润上缴总部由巴菲特统一再分配。这个模式的天才之处在于，它不试图解决业务之间的协调问题，而是通过选择不需要协调的业务组合来消除协调问题本身。

集团制做错的反面案例还是GE。前面提到GE Capital利用信息不对称粉饰报表，但GE的组织失败远不止于信息黑箱。韦尔奇时代的GE表面上是多元化集团，但总部不甘心只做资本配置，试图在航空发动机、医疗设备、金融服务之间强行制造协同——用GE Capital的利润补贴工业部门，用"六西格玛"方法论统一管理从涡轮机到次级贷款的所有业务。结果是多元化的风险没有隔离，协同的收益也没有兑现。金融危机一来，GE Capital的窟窿拖垮了整个帝国。集团制的前提是承认业务之间没有协同，总部克制住"创造协同"的冲动。一旦总部开始越界，集团制的风险隔离优势就荡然无存。

集团制的适用条件很明确：业务之间的技术协同需求接近于零。如果两条业务线的工程师互换之后，不仅需要学习新的领域知识，连编程语言、技术栈、工具链都完全不同——甚至其中一条业务线根本不需要软件工程师——那就说明这两条线不应该共享任何技术基础设施，集团制是唯一合理的选择。

八、三种组织形态，一个选择框架

超大规模公司的组织形态归根到底只有三种。

职能制。 产品精简，协同紧密，核心竞争力来自一致性。所有技术和职能资源统一管理，不设产品级损益表。没有产品级的利润中心，就没有副总裁争抢技术控制权的动机，一致性是组织架构天然保证的。

事业部制。 产品庞杂但技术底座相通，各业务线面对不同市场需要灵活响应。事业部拥有业务自主权，但总部必须控制技术标准和关键基础设施。没有强总部的事业部制就是碎片化的温床。

集团制。 业务多元化到完全没有协同需求。总部极简，只做资本配置和人事任命，各子公司完全独立运作。集团制的前提是承认业务之间没有协同，总部克制住"创造协同"的冲动。

现实中，纯粹的单一形态很少见。大多数公司是混合体——某些业务线之间用职能制共享资源，某些业务线独立成事业部，某些完全不相关的业务以集团方式运作。同一家公司的不同层级、不同阶段，适用的模式也不同。这三种形态不是三个非此即彼的选项，而是三个基本原型。理解它们的核心逻辑和适用边界，比套用任何一个标签更重要。

对于超大规模科技公司，最务实的做法是在公司内部的不同层级采用不同模式。

总部层采用职能制。技术标准、基础设施、代码平台、技术委员会——这些是地基，用职能制统一管理，不允许任何事业部绕过。

核心业务层视协同程度而定。如果核心业务之间协同紧密，就不应该拆成事业部，而应该直接纳入总部的职能体系——产品设计、技术研发、市场销售各自作为职能部门，服务所有产品线。只有业务差异大到共享资源的收益小于协调成本时，才拆出来作为独立的事业部运营，但仍然必须站在总部的技术底座之上。

外围和新业务层采用事业部制。新业务方向不确定，需要快速试错，给独立团队充分的自主权。一定程度的技术碎片化在这个阶段是可以接受的成本。等跑出来了，再决定是并入核心业务的职能体系，还是独立成长为新的事业部。

但需要清醒认识到，职能制对人的要求远高于事业部制。事业部制有一个天然的纠错机制：损益表。做得好赚钱，做得差亏钱，市场替你筛选决策质量。职能制没有这个兜底——没有产品级损益表，就没有一个简单的数字来衡量某个决策是对是错。决策质量几乎完全取决于关键岗位上的人。CEO必须有足够的判断力来仲裁跨职能的争议，因为职能制下所有重大决策最终都会汇聚到CEO这个节点。各职能负责人必须是各自领域的顶尖专家，考核标准是专业水准而非财务指标。苹果的职能制能运转，乔布斯和库克的判断力是前提，不是结果。如果CEO层面的判断力不够，职能制会比事业部制更糟——因为连市场反馈这个兜底机制都没有了。

选择依据不是公司大小，是一个变量：业务线之间的技术协同需求强度。协同需求强，技术管控集中的收益大于成本，走职能制。协同需求中等，业务差异大但技术底座相通，走事业部制，但总部必须把技术治理抓在手里。协同需求弱到接近于零，走集团制。

大多数公司的治理灾难都是错配——需要协同的时候用了分权（微软把本应统一的界面技术交给各事业部各自为战），不需要协同的时候搞了中台（许多盲目学习"大中台"战略的公司在没有协同需求的业务之间强行统一）。选对模式不需要天才，需要的是对自身业务本质的诚实判断。

九、组织架构是公司真正的底层代码

组织架构是一家公司真正的底层代码。产品策略、技术选型、人才密度、执行效率——这些被反复讨论的议题，大多数时候只是组织架构这个上游变量的下游表现。当一家公司反复出现"聪明人做蠢事"的现象时，问题几乎都可以追溯到组织架构的设计缺陷。微软的界面技术碎片化如此，所有大公司里反复出现的重复建设、信息壁垒和政治内耗也是如此。

但大多数管理者不这么看。他们把组织架构当作行政事务——公司大了就拆事业部，新来一个高管就调一次架构，两个人都不能得罪就拆成两个部门一人管一个。每一次调整都在解决一个人事问题，而不是在回答一个架构问题。结果是组织架构变成了权力分配的镜像，和业务的实际协同需求没有任何关系。这就像一个程序员只关心功能实现，从来不思考整体的架构设计，然后困惑为什么代码越写越乱、越改越崩。正确的顺序应该反过来：先根据业务的协同关系设计架构，再把合适的人放到合适的位置上。人服从架构，不是架构服从人。

而且组织架构的改革成本随时间指数增长。公司只有几百人的时候，把技术基础设施定位为统一管理的公共资源，阻力很小——那时候事业部壁垒还没成型，没有副总裁领地，没有"我们部门的技术栈"这种意识，统一是自然状态，根本不需要"推行"。等到各事业部长到几千上万人，各自有了完整的技术团队、自己的框架、自己的基础设施、自己的技术文化，再想统一就是在拆已经盖好的楼。不是不能拆，是拆的代价大到没有人愿意承担。组织架构一旦定型，既得利益网络就开始生长，每多一年，改革的阻力就增加一分。在不需要制度的时候把制度建好，因为等你需要的时候已经建不起来了。

说到底，组织架构的设计是企业管理的第一性原理。产品做不好，常见的归因是产品经理能力不行、技术方案选错了。但如果组织架构设计得当——职能制下产品、技术、市场各自专业负责，信息交叉验证，没有人能垄断决策——产品做不好的概率本身就大幅降低。技术混乱，常见的归因是缺乏统一标准。但如果从一开始就建立了统一的技术底座和治理体系，碎片化根本不会发生。人才流失，常见的归因是薪酬不够、文化不好。但如果工程师有全公司视野，跨部门流动无障碍，公司级知识积累对每个人开放，人才的成长空间本身就大得多。所有这些被反复讨论的下游问题，都是组织架构这个上游变量的函数。把上游设计对了，下游的大部分问题不会出现。

选对组织模式不需要天才，需要的是对自身业务本质的诚实判断，以及在不需要事业部制的时候克制住拆分冲动的定力。

回到Snover文章开头的那个场景：一群开发者坐在一起，没有人能回答"新项目该用什么框架"。这个沉默的根源从来不在技术里。