这篇帖子围绕一种把组织从 leader-follower（上级指挥、下属执行）转向 leader-leader（每个人都能主动负责）的管理哲学展开。评论里不少人把它理解为“信任、授权、少 micromanage（微观管控）”，而不是复杂的新框架。反对者则担心这种模式一旦放大到几十人、上百人甚至上千人，就会因为职责边界不清而失控，还有人用 Dunbar's number（邓巴数）来提示人际协作规模的上限。讨论还延伸到 Scrum（敏捷开发中的站会与流程）和 user stories（用户故事模板）等做法：原则本身可能合理，但如果被经理机械地套用、甚至强制话术，就会变成管理仪式。
一些评论者认为，leader-leader 并不是一套复杂框架，更像是最朴素的领导方式：信任团队、授权给人，然后别挡路。有人强调领导者的任务不是把事情都握在自己手里，而是把目标和边界说清楚，让成员自己承担执行。这个观点还延伸到“人会长到你给出的信任水平”——当管理者不把人当成只会被驱动的执行器时，团队往往会更主动。也有人直接说，很多人误把领导力理解成控制流程，而不是帮助别人把事情做成。
另一组评论质疑这种模式在规模扩大后是否仍然有效。有人直接指出，团队到 100 人左右就需要更多结构，超过 1000 人时如果人人都算领导，组织会变成混乱。还有人用 Dunbar's number（邓巴数）暗示，人类可稳定协作的关系数量本来就有限，所以分布式领导不可能无限复制。“如果人人都是领导，谁来干活”也表达了对责任稀释、执行空转的担心。
不少人并不反对原则本身，而是反对把好建议做成硬性规则。评论里提到，不要 micromanage、做 coach、不要让工作必须经过 manager，这些都很合理，但一旦变成禁止某些词、强制员工使用固定句式，就会立刻变味。有人拿 user stories（敏捷开发里的需求叙述模板）举例，说明管理书上的技巧常被经理机械照搬，最后只剩下表演。这个批评的核心是：有价值的原则很容易被做成 cargo cult（只学外形不学原理）的仪式。
扁平化管理（flat management style）本来被认为有助于减少层级、提高自主性，但评论者说自己真正见过做对的情况很少。更多时候，它要么沦为老式层级管理换了个名字，要么是小创业公司硬学大公司的流程，结果把两边的缺点都拿来。有人举例，经理要求一个并不统一、而且大多数人甚至不是软件工程师的团队做 daily standup（每日站会）式 Scrum（敏捷框架）安排，最后把反对意见理解成权力问题。结果不是协作变好，而是几位工程师直接离开。
还有人把注意力放在文章包装上，觉得标题或博客名像是在借更知名的 Practical Engineering（一个知名工程类频道/博客）的名气。虽然这种第一印象让人反感，但看完后仍承认文章内容至少有一些可取之处。这个反应说明，讨论管理理念时，外包装和品牌联想也会先入为主地影响读者判断。它也提醒读者，内容评价和对标题/定位的观感有时会被混在一起。
Leader-Leader: 一种强调每个人都能主动负责、组织更分布式的管理模式。
Leader-Follower: 传统层级式管理，决策和责任主要自上而下传递。
flat management style: 扁平化管理，层级较少、决策更分散的组织方式。
micromanage: 微观管控，领导者过度介入细节，压缩团队自主性。
cargo cult: 只模仿流程或话术外形，不理解背后原理的形式主义。
Dunbar's number: 邓巴数，指人类能稳定维持的社交关系规模上限，常用于讨论组织扩张后的协作难度。
Scrum: 敏捷开发框架，常见实践包括站会、迭代和任务看板。
user stories: 敏捷开发中的需求表达模板，用来描述用户目标与期望。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。