为什么你的“和谐”团队正在失败
为什么你的“和谐”团队实际上正在失败
团队常常将心理安全感误解为每个人都相处得完美无缺。我看到一些领导者吹嘘他们的团队里从来没有人提高嗓门，会议结束时每个人都点头同意，并且很少有分歧。有些人甚至认为他们的团队是“心理安全的”，因为没有人争吵。
但事实是：真正的心理安全感不是为了避免冲突，而是创建一个环境，让挑战性的想法使团队更强大，而不是更弱。
来自 Harvard Business School 的 Amy Edmondson 将心理安全感定义为_“一种信念，即人们不会因为提出想法、问题、疑虑或错误而受到惩罚或羞辱。”_
再次强调，这并不是要避免（有时是激烈的）讨论，而是要创造一个空间，在这个空间里：
- 你可以说_“我认为那是错的”_而不用担心被排斥
- 想法会根据其本身的价值受到挑战，而不是因为是谁提出的
- 人们可以承认自己的错误并从中学习
- 不同的观点不仅被容忍，而且被鼓励
从我所见过的，真正拥抱建设性分歧的团队表现出以下特点：
- 问题会尽早被发现：工程师会及时指出问题，而不会等到事情变得不可收拾。
- 想法会得到充分的辩论：我曾见过两位资深开发人员就架构问题激烈争论，但第二天他们就像什么都没发生一样进行结对编程。
- 焦点始终放在问题上：使用_“这种方法可能无法扩展”，而不是“你的想法很糟糕。”_
- 错误成为学习的机会：在上次发生故障后，犯了错误的工程师亲自领导了事后讨论。
“友善”团队的隐藏成本
我见过很多“友善”的团队，每个人都彬彬有礼，没有人惹麻烦，会议也很顺利。但几乎所有这些团队都只产出了平庸的工作。
为什么？因为批判性思维需要摩擦。这些团队实际上并不和谐，而是回避冲突。分歧仍然存在，只是转到了地下。工程师们会在会议上点头同意，然后回到自己的办公桌前编写完全不同的代码。每个人私下都意识到的设计缺陷会未经修改地通过评审。
真正的问题不在于缺乏冲突，而在于缺乏诚实的沟通。这些团队失败不是因为他们的分歧太少，而是因为他们无法进行建设性的分歧。
平衡安全感和冲突
以下是我作为 EM 尝试构建这种环境的一些经验：
- 展示你自己的脆弱性：当我承认我在一个 Kubernetes 讨论中完全迷失时，突然每个人都觉得可以问“愚蠢”的问题了。
- 为辩论设定一些基本规则：我们有一些简单的约定——关注想法而不是人，并将争论与决策分开。
- 赞扬挑战者：我会公开表扬那些提出令人不舒服的问题或发现其他人错过的难题的人。这些人不是“难相处”，他们是你的预警系统。
我发现一件奇怪的事情：那些感到足够安全可以坦诚交流的团队，实际上随着时间的推移，会减少许多恶性冲突。当小的分歧能够被正面解决时，它们就不会变成沉默的怨恨或消极攻击性的行为。
我最好的工程团队从来不是那些安静的团队，而是那些技术辩论充满活力，不同观点受到欢迎，并且我们可以在相互尊重的同时进行辩论的团队。
所以，当你看到你的团队真正深入研究一个技术分歧时，不要惊慌。这可能表明你已经建立了一些有价值的东西——一个人们感到足够安全可以彼此坦诚相待的地方，包括冲突。
毕竟，没有人质疑的代码通常会在生产环境中崩溃。想法也是如此。