最大的错误之一就是保护人们免受学习所需的痛苦。
解雇员工
我 26 岁时第一次成为一名经理。我 26 岁时第一次解雇员工。
我整整一周都焦虑不安。前一天晚上我彻夜难眠。解雇当天，我紧张得要命。去会议室的路上，我感觉胃里翻江倒海。当我告诉他失业了，我的手在桌子底下颤抖。当他听到这个消息时，我激动不已。
我送他到电梯，和他道别。然后我回到我的办公桌，我的团队在那里。我让所有人集合，告诉他们他已经离开了团队。大家都坐了下来，我盯着屏幕一小时，什么也没做，漫无目的地点击着，假装在工作。我早早下班，喝了几杯。接下来的几天里，我一直在想他最近在做什么，过得怎么样。
这真是令人痛苦。
但，这本该如此。当我亲眼目睹解雇员工的痛苦时，我深刻理解了聘用优秀人才和做好绩效管理的重要性。之后的每一次解雇都产生了同样的效果——我会聘用更优秀的人才，我会更好地进行绩效管理。
这些信念并非轻率之举。在十个人挤在一起、只因为某人“足够好”就强行雇佣他的情况下，我绝对不会说“足够好”。“足够好”并不意味着“足够好”。这种信念的背后，是对解雇经历的深刻理解。如果再次发生类似事件，我绝不会偷懒。
被解雇的痛苦，也让我在管理方面进步了很多。很多大公司环境的问题在于，管理者们都对痛苦避之不及：
- 经验丰富的人力资源人员全程陪伴您，解答任何需要解答的问题
- 他们通常说了 90% 的话，甚至全部话
- 你所说的非常有限且受限
最让人抓狂的是？真正疯狂的是——它往往是远程的。对着屏幕说话简直是笑话。它比任何其他方式都更能消除互动中的人性。你本质上是在玩电子游戏。
那么会发生什么？你消除了痛苦，人们却学不会。他们学不会更好地招聘。他们学不会更好地进行绩效管理。最糟糕的情况不是现实生活中的恐怖经历——而是一场15分钟的虚构会议，然后你又回到了办公室，吃着糖果。
运输错误
交付 bug 是另一个你应该从痛苦中学习的地方。随着公司规模扩大，文化趋于无责，工程师们往往与 bug 的影响格格不入。你写了一个 bug，它给你一直听说的那些不知名的客户带来了问题，你不得不仓促地发起一个事件来修复它。没有麻烦，没有大惊小怪。Sprint 计划一如既往地在周二进行。
这简直是胡说八道，这是在逃避痛苦。
工程师最好与客户沟通，观察他们的反应，并解释bug。当你看到你的用户因为花费大量时间和精力处理你编写的bug而心烦意乱时，当你看到他们担心自己之前对你的软件的担保有误时，当你听说他们的团队整个周末都在修复数据时，那种强烈的羞愧和歉意应该深入你的血液。
亲眼目睹 Bug 对客户造成的影响，这种发自内心的感受可以帮助工程团队彻底改善质量，帮助团队克服坚持标准并付出额外努力的不适感。
结论
人们应该接触正确的创伤。失败的后果会带来一些转变性的经历。忽视它们、逃避它们，或者让任何事情转移它们，都会阻碍你的奖励/问责机制发出关键信号。
找到方法，从失败中汲取经验教训。这意味着要更多地自己承担解雇责任，而不是推卸给别人。这意味着要与那些让你失望的客户互动。
这些经历并非旨在让你变得麻木不仁。这是一个常见的误解。优秀的经理人解雇员工时不会感到那么痛苦，这并不是因为他们习惯了，而是因为他们从以往的经验中汲取了教训，知道自己已经尽了一切努力来招聘优秀员工并公平管理。
最后，如果你遇到员工未能遵循你的价值观或标准的文化问题，那就找出那些受失败影响的人。让未来失败的结果成为与这些人互动的必要条件。这样，问题通常很快就会迎刃而解。
原文： https://staysaasy.com/management/2025/09/14/educational-trauma.html