凌晨三点的跨时区会议，决策反而比12人团队时慢了10倍——这不是段子，是Charlotte de Jong Schouwenburg在InfoQ Dev Summit上分享的真实案例。她专门研究科技公司的人因问题，发现代码能水平扩展，人却做不到。
【核心图】
Charlotte画了一张简单的对比图：
左边：系统扩展——加服务器→性能提升→线性增长
右边：团队扩展——加人头→沟通爆炸→效率崩塌
这张图是她整场演讲的锚点。她服务过大量科技公司，客户原话是：「我们从10个工程师扩到100个，流水线扛住了，系统扛住了，但人就是不再合作了。」
沟通复杂度：每加一个人，不是加一条线
12人团队时，信息靠「大家都认识」就能流转。Charlotte引用的LeanIX案例显示，这家公司2012年起步时正是这个规模，「非常紧密，彼此熟悉，沟通路径极短」。
但扩张后，沟通链路呈指数级增长。她没给具体公式，但点出了症状：跨时区加团队→决策慢10倍。不是人变笨了，是信息在传递中层层损耗。
Charlotte把这叫「人类可扩展性问题」（human scalability problem）。系统扩展靠加机器，人扩展需要另一套机制。
行为可扩展性：两个具体工具
她提出了「行为可扩展性」（behavioral scalability）的概念，并给出两个落地工具：
第一，沟通架构（communication architecture）。不是让大家多开会，而是设计「谁在什么场景下以什么方式同步」。原文没展开细节，但强调了这是刻意设计，而非自然生长。
第二，工程化信任（engineering trust）。Charlotte的措辞很精确——不是「建立信任」这种虚词，而是像工程问题一样拆解、测量、迭代。她公司Bravely专门做这块，客户包括她现场展示的「很高兴与这群人合作」的名单（原文未列具体公司名）。
这两个工具的目标一致：让团队在扩张中保持高绩效+自主性，同时不牺牲速度和文化。
为什么这事现在值得盯
Charlotte有13年经验，专注科技公司的人因问题。她观察到一个悖论：技术团队最擅长优化系统，却系统性地忽视人的扩展瓶颈。
她的客户反馈呈现高度一致性——扩张带来「更多戏剧冲突」（more drama, more conflict）。这不是管理风格问题，是结构问题：人多了，旧有的协作模式必然失效。
LeanIX案例的价值在于，它是「极少数经过显著研究的定性研究」。Charlotte特意强调这点，暗示市面上大多数「扩张经验」都是 anecdotal（轶事性的），缺乏严谨性。
给你的检查清单
如果你正在经历或即将经历团队扩张，Charlotte的框架可以拆成三个自检问题：
1. 你的「沟通架构」是设计的，还是自然长成的？
2. 信任是被当作文化口号，还是可工程化的实践？
3. 扩张后，决策延迟和冲突上升，你有没有归因到「人的可扩展性」？
她没给标准答案，但指出了方向：把人的问题当系统问题处理。
Charlotte最后留下一个开放的邀请——LeanIX案例是公开可查的，建议亲自去读原始研究。她的演讲标题叫「为什么你的团队不像代码那样扩展」，答案藏在「代码没有情绪，人有」这个简单事实里。
下次规划团队扩张时，先画那张对比图：左边写服务器，右边写人头。然后问自己——右边那栏，你的扩展策略是什么？
热门跟贴