新晋管理者如何应对团队内耗：前亚马逊 PM 的实战策略
一句话总结
新晋管理者最大的幻觉，是以为内耗源于"人有问题"，于是急着换人、调架构、搞团建。真实的判断是：团队内耗在90%的情况下是系统设计的副产品，不是个体道德的失败。你需要的不是更敏锐的识人眼光，而是敢于在信息不完整时重构激励机制的勇气——因为等你看清"到底是谁在搞事"，系统已经烂透了。
适合谁看
这篇文章写给那些晋升后突然发现自己从"解决问题的人"变成了"问题本身"的新晋管理者。你可能刚带3-15人的团队，可能在大厂或高速成长的独角兽，可能前六个月还在庆功宴上被恭喜，现在却在凌晨两点翻 Slack 记录想搞清楚为什么两个明明聪明的人要互相抄送对方老板告状。
你不是在找管理学的通识科普。你不需要再听一遍"1 on 1 很重要"或者"要建立心理安全"。你需要的是具体场景下的判断框架：当两个高级工程师在架构评审会上公开对峙，当产品经理和设计师在 Figma 评论区互写小作文，当你的老板问你"团队氛围怎么样"而你既不能说谎又不敢全说的时候——你怎么选？
这篇文章也适合那些正在考虑接受管理岗的资深 IC（Individual Contributor）。硅谷大厂 PM 的薪资结构通常是 base $120K-$180K，RSU 每年 $80K-$200K，bonus target 15%-20%（总包 $200K-$400K 区间）。管理岗的 base 可能只上浮 10%-15%，但 RSU 和 bonus 的杠杆会显著放大。
问题是：你是否清楚这份溢价买的是"承受内耗的耐受力"，而不是"更大的决策权"？很多人签 offer 时没算这笔账。
内耗的第一个信号：你以为的"沟通问题"，其实是权力真空
新晋管理者最常收到的投诉，是"A 和 B 沟通不畅"。然后你介入调解，发现两人各说各话，于是你安排了一次"对齐会议"，甚至拉了一张 RACI 表。三个月后同样的人换了个话题继续撕。你不是在解决内耗，你是在给内耗办延期手续。
真实的判断是：持续出现的"沟通问题"，本质是决策权的归属没有说清楚。不是 A 和 B 不会说话，而是这个决策理论上该谁拍板、拍板的依据是什么、拍完后能不能改——这三件事没人明确过。
我在亚马逊带过一个六人小组，负责供应链系统的一个子模块。两位资深工程师，一位倾向用 Lambda 做事件驱动，一位坚持用 ECS 跑常驻服务。技术争论持续了六周，每周的 standup 都变成辩论赛。
我当时的做法是分别谈话，然后组织了一次"技术选型会"，让两人各讲十五分钟，最后我"综合双方优点"做了一个折中方案。结果是两边都不满意，执行时阳奉阴违，上线后出了两个 P1 故障。
三个月后我的 manager 在 1 on 1 里问我："你知道为什么他们一直在吵吗？"我说技术观点不同。他摇头："因为你没有授权。他们不是在争技术，是在试探你的边界。你做了一个没有意义的折中，等于告诉他们'这里没有真正的决策机制'。"
正确的做法不是更耐心地倾听，而是在信息不完备时强制分配决策权。不是"我们再聊聊"，而是"这个决策 X 负责，依据是 Y，周四下午五点前给我方案，可以不同意但必须执行"。内耗的燃料是不确定性，不是分歧本身。
> 📖 延伸阅读：如果你是Spotify PM你会如何提升付费转化率
为什么你的 1 on 1 在制造内耗
新晋管理者被教导的第一个工具就是 1 on 1，每周三十分钟，"倾听员工声音"。然后你发现这些会议变成了投诉信箱：A 说 B 不配合，C 说 D 抢功，E 暗示 F 在散布关于项目的谣言。你认真地记笔记、承诺去谈、下次会议收到"你上次说的那件事，没什么改善"。
不是 1 on 1 没用，而是你把 1 on 1 做成了没有后果的宣泄渠道。当员工发现"向老板抱怨"这个行为本身没有任何成本，也没有后续的结构化动作，抱怨就会从信息传递变成权力博弈的工具。
我在一次 hiring committee 旁听中学到这件事。一位候选人的 references 提到他"善于在团队中 surfacing concerns"，HC 里一位资深 director 直接打断："surfacing concerns 是加分项，但如果他每次都 surface 给 manager 而不是给当事人，他不是在解决问题，他是在积累政治资本。
" 这句话让我重新理解了自己的 1 on 1。
正确的 1 on 1 结构应该是：员工可以带任何话题，但管理者必须做一件事——区分"这需要我介入"和"这需要你自己处理"，并且明确说破。不是"我理解了，我去看看"，而是"这件事你希望和对方直接谈，还是需要我到场？如果你需要我到场，我的角色是确保双方不打断对方说话，不是替你表达。
你选哪个？" 这个选择本身就在训练员工处理冲突的能力，同时避免你把 1 on 1 变成刷存在感的表演。
更隐蔽的陷阱是：当你和员工 A 的 1 on 1 总是聊到员工 B，你和 B 的 1 on 1 也总是聊到 A，你实际上在成为信息的中转站。不是你在管理冲突，是冲突在管理你。
跨部门冲突时，"中立"是最差策略
新晋管理者常犯的一个错误，是在自己团队与其他部门的冲突中保持"中立"。比如你的产品经理和法务因为上市材料的合规描述僵持不下，你说"你们先谈，我尊重双方的专业判断"。这听起来理性，实际上是在逃避一个基本事实：冲突的解决需要有人承担决策的代价，而这个人只能是你。
不是"中立"不对，而是"中立"在组织行为学中被证明会延长冲突周期并降低双方满意度。经典的 Deutsch 冲突理论指出，当第三方呈现出"非决断性"时，冲突双方会倾向于强化自己的立场以争取更多支持，而不是寻求解决方案。你的"中立"给了双方继续博弈的许可证。
我在一次 debrief 会议中见过一个反面教材。一位新晋 manager 负责的产品需要数据团队支持一个临时取数需求，数据团队负责人以"排期已满"拒绝。manager 在双方之间传了三天话，最后提议"要不各退一步，下周做但数据精简版"。结果产品团队觉得数据团队傲慢，数据团队觉得产品团队不懂规矩，而这位 manager 在双方那里的信任评分都下降了。
正确的判断是：跨部门冲突中，管理者的角色不是调解员，而是利益代表。你需要公开声明"我的团队的 priority 是什么，我愿意为此付出什么代价"，然后去找对方同等级别的管理者谈交换条件。不是"帮我们个忙"，而是"如果我们放弃 Q2 的另一个需求，这个临时取数能否插队？
或者我这边出一个工程师支援你们下周的发布，换这次支持？" 谈判的结构是清晰的，代价是显性的，内耗因为没有模糊的期待而减少。
> 📖 延伸阅读：Coda内推攻略：如何拿到产品经理内推2026
绩效考核：你在奖励什么，就会收获什么内耗
很多新晋管理者沿用公司的标准绩效模板，然后困惑于为什么团队行为与 stated values 不符。不是模板有问题，是你没有意识到：任何可被量化的指标都会被博弈，而博弈的方式就是你内耗的来源。
亚马逊的 OP1/OP2 规划周期中，有一个经典场景：两个团队合作一个项目，A 团队负责前端，B 团队负责后端。年底 review 时，A 的 leader 强调"我们交付了用户可见的新功能"，B 的 leader 强调"sleeps, 低延迟的 API 是系统稳定的基石"。
双方都对，但双方都没有动机去修复那个导致 A 的功能上线延迟了两周的接口问题——因为修复跨团队的技术债不会出现在任何人的绩效文档里。
不是绩效考核不公平，而是你的考核设计在鼓励局部最优。新晋管理者常犯的错误，是接受 HR 给的模板然后"根据团队情况微调"。真正有效的做法，是在考核周期开始前就定义清楚：哪些成果必须是跨团队合作的产物，并且把这些成果的重量显著调高。
具体操作上，我在一个周期里实验过这样的调整：把"独立完成的项目"权重从 40% 降到 25%，新增"主动修复的跨团队 friction"权重 15%，并且要求每个员工在 self-review 中明确写出一个具体案例。这个设计不是完美的——有人开始制造 friction 然后修复它——但它至少把讨论引向了"我们如何协作"，而不是"我做了什么"。
当你必须开掉一个人：内耗的终极处理
内耗有一个残酷的终点：某个人的存在本身就是系统噪音的主要来源。新晋管理者在这个决策上往往犹豫太久，理由通常是"再给他一次机会"或者"现在换人成本太高"。不是你不仁慈，而是你对"成本"的理解有误。
硅谷大厂的典型流程中，从提出 performance concern 到正式 action，往往需要 3-6 个月的文档周期。这三个月里，团队其他成员在观察：管理者是否真的会处理不可接受的行为。你的犹豫是在用团队其他人的信任做隐性支付。
我在一次 hiring manager 的 coffee chat 中听到过一个精确的判断："我们算过，一个 toxic high performer 在团队里的隐性成本，大约是他薪水的 1.5-2 倍。不是因为他做错了什么，而是因为他周围的人开始不犯错——不提出新想法、不质疑现有方案、不在会议上发言，因为'多一事不如少一事'。"
正确的判断不是"他有没有功劳"，而是"他离开后，团队的整体输出曲线会怎样变化"。这个判断需要在日常就建立观测：当这个人休假时，团队的会议质量是上升还是下降？代码 review 的评论数量是增加还是减少？Slack 里的私聊比例有什么变化？这些数据比任何一次"深度谈话"更能告诉你真相。
准备清单
- 重画你的团队决策地图。不是组织架构图，是"这个决策谁拍板"的地图。用红笔标出所有模糊地带，本周内逐一明确。
- 改造你的下一次 1 on 。取消自由闲聊的前十分钟，改为员工必须带一个具体议题，你在会议结束前必须给出一个明确的分类：需要我介入 / 需要你自己处理 / 需要我们一起设计一个实验。
- 系统性拆解面试结构。如果你在组建团队，PM 面试手册里有完整的跨团队冲突场景实战复盘可以参考——不是让你背答案，是理解那些"优秀候选人"和"真正能做管理的人"在回答同一道题时的结构性差异。
- 审计你的绩效考核模板。把"独立完成"相关的权重降低至少 10%，转移到需要跨团队合作的指标上。如果做不到，至少在下一次的 calibration 中主动提出这个议题。
- 设立"冲突日志"。不是记录谁和谁有矛盾，是记录"这个冲突的决策权本应属于谁"。每周 review 一次，你会看到系统性的模式。
- 找到你的 peer group。不是同公司同级别的 manager 聚餐吐槽那种，是外部的小范围、有保密协议的交流圈。内耗的处理需要参照系，而你的参照系不能只是你的老板。
- 做一次预演：如果你的团队明天必须裁掉一个人，你的名单是谁？这个思考实验的价值不在于你真的要执行，而在于它强迫你诚实面对"谁在消耗系统的能量"这个 uncomfortable truth。
常见错误
错误一：把"团队和谐"当作管理目标
BAD 版本：一位新晋 manager 发现两位工程师在技术方案上有分歧，主动提出"我们先搁置争议，按时间线推进，后面再优化"。六个月后系统架构债爆发，两人矛盾更深，因为各自在私下推进自己的方案。
GOOD 版本：同一情境下，manager 在分歧出现的第一次会议就明确："我们现在需要在一个小时内决定采用 A 还是 B。我的判断是 A，因为上线时间约束。选择 A 不意味着 B 的想法没有价值，如果上线后数据支持 B 的假设，我们 Q3 重构。现在，反对 A 的人，你的顾虑是什么？我需要听到。" 不是消除了分歧，是把分歧转化为可执行的承诺。
错误二：用"更多沟通"解决结构性矛盾
BAD 版本：产品和技术团队持续冲突，manager 增加双周 sync 会议，建立 Slack channel，甚至组织了一次 offsite。三个月后 channel 里只有机器人消息，sync 会议变成各自读 update，offsite 的合影还挂在墙上。
GOOD 版本：manager 识别到冲突根源是 KPI 不匹配——产品按功能上线数考核，技术按系统稳定性考核。不是增加沟通，是向双方 leadership 提出联合 KPI 的试点方案，用一个季度的数据验证"功能上线且稳定性不下降"是否可行。沟通解决不了的，结构可以。
错误三：在新人加入时期待"文化自然融合"
BAD 版本：团队新招了一位背景不同的 senior，manager 在 onboarding 里说"我们团队很 flat，有什么直接说"。三个月后新人离职，feedback 是"不知道这里的规则是什么，每次'直接说'都好像踩到雷"。
GOOD 版本：manager 在第一天就明确："我们团队有三个不成文规则：一，公开挑战方案是可以的，挑战动机需要附替代方案；二，1 on 1 里说的话不会传到第三方，除非你明确授权；三，跨团队冲突先尝试直接沟通，记录点需要在 24 小时内同步给我。这些规则是我观察到的，不是写死的，你有三个月时间验证它们是否有效。" 不是期待融合，是主动显化规则供人检验。
FAQ
Q: 我刚晋升两个月，发现团队里已经有一个小团体在排挤新成员，我作为"外来的"管理者该怎么介入？
这个问题的陷阱在于，它预设了"先观察再行动"的合理性。不是观察不对，而是新晋管理者的观察期本身就是权力真空期——你在看，小团体也在看你什么时候出手。我的判断是：在确认信息后的第一次 team meeting 就必须介入，延迟本身就是信号。具体做法不是直接点名，而是重构一个让小团体无法维持现状的机制。比如调整项目分组，确保小团体的核心成员必须与新成员合作一个短期目标；
或者在公开场合重新定义"团队成功"的衡量标准，引入需要跨小团体协作才能达成的指标。关键不是惩罚，是改变博弈的收益结构。我在亚马逊的早期处理过类似情况，当时的错误就是观察了六周，结果小团体的边界已经固化，后期调整的成本高出三倍。你的第一次介入不需要完美，需要的是明确：这个团队的规则由谁定。
Q: 我的老板就是内耗的来源之一，他经常在未通知我的情况下直接指挥我的团队成员，我该怎么办？
这不是一个"向上管理"的技术问题，是一个边界重构的政治问题。不是你不能谈，而是你怎么谈决定了结果。错误的打开方式是"我觉得您这样做影响了我的权威"——这是在用个人感受对抗组织权力，必输。正确的判断是：你的老板在越界，说明他对你有未被满足的信息需求，或者他对你的决策速度不信任。
第一次谈话的结构应该是："我注意到您上周直接找了 X 谈 Y 项目，我想确认一下，是您需要更快的信息流转，还是我对 Y 项目的判断有您不同意的部分？" 这个问题把话题从"您越界了"转移到"我们如何协作更高效"，同时给了他一个明确的选择：要么承认是信息问题（那你解决信息同步），要么提出具体分歧（那你们有实质性议题可谈）。如果他回避这个问题继续越界，你的下一步不是再谈一次，而是开始记录实例，在合适的时机（比如他的 manager 问你对他的 feedback 时）用具体事件而非概括评价呈现。这不是告状，是系统层面的信号传递。
Q: 团队成员的能力都不错，但一到执行就互相推诿，这种"好人内耗"怎么破？
这是新晋管理者最困惑的类型，因为找不到明确的"坏人"。判断是："好人内耗"的根源往往是角色定义中的责任重叠，而不是个人品质问题。不是他们不想做，是边界设计让他们可以合理地不做。处理上，避免"大家开个会明确一下分工"这种无效动作——这会让推诿从暗处转到明处，更加耗时。有效的做法是：选一个即将启动的具体项目，由你亲自定义 R 和 A（Responsible 和 Accountable），并且让 A 只有一个人，R 可以多个但必须有明确的交付物和时间。
然后公开声明："这个项目的成功标准是 X，如果达不到，Accountable 的人需要向团队解释原因，不是追责，是复盘。" 关键是把"推诿"从一种可行的团队行为，变成需要承担解释成本的个体行为。一旦这个机制运转起来，"好人"们会发现协作比推诿更省力。我在一次 HC 讨论中听过一个精辟的判断："team health 不是看大家相处多好，是看 bad behavior 的成本有多高。" 调高一点试试。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。