Waterline 模型:团队失灵时,别急着怪人,先查水位线以下

同一篇文章，两个世界

我在 Hacker News 上看到这篇帖子的时候，它挂在首页边缘，1 个点，0 条评论 来源：HN。那感觉像是一间空荡荡的会议室里，只有一个人举了手。我顺着链接去了 Substack 原文，页面上的数字完全是另一个世界，831 个赞、11 条评论、75 次分享 来源：AR。同一篇文章，两个平台，温差大到让人想查一查是不是统计口径出了错。

数字当然没出错。差别在于 HN 上的那 1 个点来自一个刚发布的链接，冷启动太正常了。而 Substack 页面上的数据是社区内部积累出来的热度，说明内容质量已经经过了足够多人的检验。831 个赞意味着什么？意味着这篇文章不是靠标题骗来的点击，是读了以后真的觉得有价值的人留下的印记 来源：AR。

付费墙的两面

这个反差还有一个更实际的原因。Substack 原文页面上有一个很小的标志，∙ Paid，付费内容 来源：AR。付费墙会挡住大部分只想随便看看的人，也会拦住 HN 上那些习惯先看免费文章再决定要不要讨论的人。所以 HN 的冷清不奇怪，反而印证了一个判断：愿意为这篇内容掏钱的人，已经在 Substack 内部形成了有效的传播循环。

我不确定付费墙是不是唯一原因。HN 上的讨论氛围本来就更偏技术细节，团队管理这类话题在那边一向不算主流。但有一点可以确定，831 这个数字是在有付费门槛的前提下积累起来的，含金量比同量的免费流量要高 来源：AR。

团队失灵时的第一反应

文章的作者 Molly Graham 在开头描述了一个场景，领导者都认得出来。目标看起来定好了，团队看起来也认同了，可时间线一直在滑，执行一塌糊涂，同样的对话翻来覆去地说。这种时候，最顺手的事情是直接往人身上找原因。“这个团队就是合不来。”“那个人不够强。”“我们需要更好的执行力。”来源：AR

Graham 在 Google、Facebook 和 Chan Zuckerberg Initiative 工作了二十年，也帮 Stripe、Anthropic、OpenAI、Microsoft、Gamma 这些公司的领导者做过顾问 来源：AR。她说，有些时候这些归咎于人的判断是对的，但更多时候不是。她见过太多例子，问题出在系统里，不在人身上，可系统出问题的时候，人往往是最显眼的靶子 来源：AR。

水位线以下

这就是 Waterline 模型的出发点。把团队想象成一艘船，水位线以上的部分人人看得见，那是人，是行为，是直接的执行表现。水位线以下的部分，是结构、流程、激励，是不容易看见但决定船能不能浮起来的东西。Graham 的主张很直接，团队出了问题，先查水位线以下，别急着怪水位线以上的人 来源：AR。

她在文章里打了个比方，调试团队应该像调试代码一样。代码出 bug，你不会第一件事就是把整个模块删了重写，你会先检查依赖，检查配置，看看是不是哪个参数传错了。换人的动作，等于把模块整个换掉，成本高，风险大，而且经常掩盖了真正的问题 来源：AR。

Graham 和 Mark Zuckerberg、Sheryl Sandberg、Chamath Palihapitiya、Bret Taylor 这些人近距离工作过，她擅长把复杂的管理经验压缩成让人记得住的隐喻。Give Away Your Legos 是她的一个经典比喻，讲的是授权。Waterline 模型是另一个 来源：AR。

别急着问谁不行

所以下次团队出问题，先别急着问“谁不行”。这句话在绝大多数团队里会引发一场无谓的互相指认。先花点时间搞清楚，是不是目标本身就含混，是不是流程里有个反复绊倒人的结，是不是激励把大家往错的方向推。这些问题的答案通常比换一个人更接近事情的根源 来源：AR。

我见过太多团队在问题刚冒头的时候就把矛头指向某个具体的人，然后那个人被换掉，团队短暂的顺畅了一阵，几个月后同样的问题换了个形式重新出现。水位线以下的东西没有被碰过，船还是会漏水。Graham 的文章给了一个更便宜的排查顺序，先看结构，再看流程，然后看激励，最后才是人。这个顺序不能保证找到全部问题，但至少不会让你在没看清系统之前就把人给牺牲掉 来源：AR。

原文：

How to debug a team that isn't working: the Waterline Model · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月28日