为什么优秀的公司反而越招人越慢？Figma这场组织图演讲说透了

在 Figma Config 2024 上，Linear 产品负责人 Nan Yu 用一场关于“组织架构图”的演讲，击中了所有高速增长团队的痛点：为什么人越多、流程越全，产品却越慢？这不是管理技巧的问题，而是你从一开始就画错了组织的形状。

最反直觉的真相：你以为在扩张，其实在自我拖慢

Nan Yu 一上来就点破一个让全场安静下来的事实：很多公司不是输在不够努力，而是输在“越努力越复杂”。她在离开日常工作、与大量创业者和公司深度合作后发现一个诡异的现象——业务千差万别，但团队结构却高度相似。

大家几乎都在复制同一套“成功模板”：Spotify 在 2012 年提出的 squads、tribes、chapters、guilds。问题是，Nan Yu 直言不讳：今天的大多数公司，根本不像 Spotify。规模、产品形态、技术复杂度都不同，却硬套一张“看起来很先进”的组织图。

结果就是她反复接到创始人的求助电话：“我们加了很多人，但不知道为什么，反而变慢了。”这不是个别案例，而是一种系统性错误——把组织设计当成了流程填空题，而不是产品设计的一部分。

Conway 定律不是警告，是判决书

演讲的核心转折点，来自一个老得不能再老的理论：Conway 定律——你最终交付的产品，会长得和你的组织架构一模一样。Nan Yu 给它换了一个更残酷的说法：“You will ship your org chart.”

很多公司在发现混乱之后，会做一件看似理性的事：叠加 OKRs、增加流程、再拆几个团队。Nan Yu 对此的评价只有一句话：“用更多复杂性，去解决复杂性。”

她提出一个更底层的问题：当一个工程师、设计师，甚至产品经理都说不清楚“我这块狭窄的工作，究竟如何贡献到公司最重要的目标”时，问题就已经不是执行，而是结构本身。组织的目的，不是让每个框都对称，而是让注意力对齐。

丑陋但有效：为什么好组织看起来一点都不平衡

Nan Yu 给出的解法听起来甚至有点冒犯设计师审美：别追求好看的组织图。

她主张从“shape”开始思考组织，而不是从人数或职能。一个健康的组织图，往往是“丑的、歪的、不对称的”。为什么？因为真正重要的那一件事，应该被明显地“过度配置”。

她引用《High Output Management》，并提出一个耐人寻味的问题：如果这本书是今天写的，它会不会更接近 NVIDIA CEO 黄仁勋的管理风格——极度清晰的主线，极少的中间层，和对关键产品的极端聚焦？

相比之下，那些“完美对称的小团队”，反而容易滑向她口中的一个陷阱：kingdom building——每个团队都在经营自己的小王国，而不是推动整体产品。

从 Linear 的组织图，看见“少即是多”的极限

在演讲后半段，Nan Yu 用 Linear 自身的组织结构，给出了一个极具操作性的原则：给团队的 scope，要尽可能大；默认不设平台团队。

她解释了一个常被忽略的事实：平台团队一旦出现，就天然会成为瓶颈。于是她提出一个激进的默认值——平台团队的数量，应该从零开始证明必要性，而不是反过来。

组织拆分的真正目的，不是“管理方便”，而是确保每个团队都能直接对产品结果负责。当团队的边界，直接映射到用户能感知的价值时，沟通成本、对齐成本，才会真实下降。

总结

这场演讲最重要的启发在于：组织设计不是后台管理问题，而是产品战略的一部分。如果你在做 AI 产品、平台或工具型业务，问问自己三个问题：我们唯一的“主菜”是什么？组织里有没有被明显过度投入的地方？有没有团队存在的唯一理由，只是为了让结构看起来更合理？真正高效的组织，往往看起来不优雅，但一定诚实。下次你想“再招一个人解决问题”之前，或许该先重新画一遍那张不太好看的组织图。

关键词： 组织架构， Conway定律， 产品管理， 团队扩张， Figma Config

事实核查备注： 需要核查：Nan Yu 的职位（Linear Head of Product）；Spotify 组织模型提出时间（2012年）；Conway 定律原始表述；是否在演讲中明确提及 Jensen Huang 作为管理风格对比；Linear 组织图是否为示例而非完整披露。