项目出了问题，领导在群里@我，说是我的失误。我翻出3个月前的会议记录，他亲口说的「按我说的做」

凌晨两点，线上告警响了。

某个团队的核心模块出了问题，用户侧报错，数据写入异常，影响范围还在扩大。排查了三个小时，定位到根因，是三个月前一次架构调整埋下的隐患。

第二天早上，领导在工作群里@了那个负责执行的工程师。

「这个问题是你当时改的，你来解释一下。」

工程师翻出了三个月前的会议记录。

领导亲口说的，「按我说的做，我来负责。」

这不是某个人的失误，这是我们整个防御体系的失效。

这种事在职场里太常见了。

智联招聘的调查显示，超过56%的职场人表示曾遭遇上级或同事推卸责任。盖洛普的数据更直接，只有约33%的员工认为自己的直属上级会在出错时主动承担责任。

剩下那67%，你懂的。

问题出了，第一反应不是「哪里出了问题」，而是「谁来背这口锅」。

这两个问题，看起来像是一回事，其实差得很远。

前者是在找系统漏洞，后者是在找替罪羊。

心理学上有个概念叫「基本归因错误」，1977年由心理学家李·罗斯提出。大意是，人在解释他人失败的时候，天然倾向于高估个人因素，低估情境因素。

翻译成大白话就是，你失败了，是因为你不行。我失败了，是因为环境太复杂。

权力不对等会把这个偏差放大好几倍。上级看下属的失误，几乎本能地会想，「这个人能力有问题」或者「态度不行」，而不是先问，「我们的流程是不是有漏洞」「当时的决策是不是有问题」。

所以那个工程师的处境，其实是一个结构性的陷阱，不是他一个人的倒霉。

说到这个，有个模型值得聊一聊。

英国心理学家詹姆斯·里森在1990年提出了「瑞士奶酪模型」。

他的核心观点是，重大事故从来不是由单一失误引发的。

你可以把每一道防线想象成一片奶酪，每片奶酪上都有洞，代表这道防线的缺陷。正常情况下，这些洞不会对齐，光线穿不过去。但当所有层的漏洞恰好对齐的时候，事故就发生了。

当所有层的漏洞恰好对齐的时候，事故就发生了。

回到那个工程师的案例，你拆开来看，漏洞其实有好几层。

领导拍板的决策，没有经过充分的技术评审，这是第一层漏洞。执行过程中没有完整的风险评估文档，这是第二层。上线前的测试覆盖不够，这是第三层。监控告警的阈值设置不合理，导致问题扩大才被发现，这是第四层。

每一层单独看，都不是致命的。但四层漏洞对齐了，事故就来了。

这时候把责任压在执行工程师一个人身上，不只是不公平，更是在浪费一次真正修复系统的机会。

锅背了，流程没变，下次还会出同样的事。

怎么说呢，这种事让人心寒的地方不只是「被甩锅」本身。

更让人难受的是，你当时是信任那个「我来负责」的。

你按他说的做，你以为有人在你前面挡着。结果出了事，那个人第一个把你推出去。

这种信任的崩塌，比锅本身更伤人。

哈佛商业评论有个研究，叫「责任下移」，说的是组织中管理层倾向于将失败归因于执行层，将成功归功于自身。这不是某几个坏领导的个人品质问题，而是一种系统性的组织行为模式。

这不是某几个坏领导的个人品质问题，而是一种系统性的组织行为模式。

知道这一点，不是为了原谅那些甩锅的人，而是为了让自己不再那么困惑，「为什么他会这样对我」。

因为在那个系统里，他大概率也是这么被训练出来的。

那个工程师后来怎么样了？

他把会议记录截图发到了群里，没有多说一句话。

领导沉默了一会儿，说，「这个事情我们内部再讨论一下。」

讨论的结果，是复盘会上用了瑞士奶酪模型，把这次事故拆成了四个层面的系统问题，每个层面都有对应的改进措施和负责人。

没有人被单独点名背锅。

那个工程师跟我说，他当时其实做好了最坏的打算。没想到结果是这样。

他说，「我只是不想让这口锅变成我职业生涯里的一个污点，仅此而已。」

我觉得他说的是事实。

我们写代码，不是为了背锅，而是为了创造价值。

一个健康的组织，应该把事故当成修复系统的机会，而不是寻找替罪羊的时机。

这才是一个学习型组织应该有的样子。

屏幕前的你，如果也遇到过类似的处境，我想说，留好记录，不是为了对抗，是为了让事实说话。

锅可以背，但要背得清楚，背得明白。

不属于你的，一克都不用多背。