[中文正文内容]

“人们是整体打包的；你必须接受优点和缺点。在大多数情况下，优势和劣势是同一枚硬币的两面。” — Steve Jobs

我注意到几乎我管理过的每一位工程师都有一个有趣的现象：他们最大的优势和最令人沮丧的劣势，往往是同一种特质在不同情境下的表现。

我还在当初级工程师的时候就亲身体验过这一点。我快速编码的能力使我非常高效——我经常能在预估时间的一半内完成功能。我的经理不断地称赞我的速度。

直到有一天……在一次特别痛苦的复盘中，我们发现一个生产问题是因为我在赶着完成功能时忽略了一个边缘情况。我的优势（编码速度）和我的劣势（偶尔忽略细节）不是分离的特质——它们是完全相同的特征在不同情境下的不同表现。

这不仅仅发生在我或少数人身上——这几乎是普遍现象。我们赞扬团队成员的品质，通常也是导致我们最大麻烦的根源。它们不是分离的特质；它们是同一枚硬币的两面。

那么我们该如何应对这种情况呢？以下三点对我很有帮助：

  1. 在你的 1:1 会议中坦诚地谈论这种二元性。 大多数人将他们的优势和劣势视为独立的事物。 事实并非如此。 在 1:1 会议中，我会说这样的话：“你深入研究问题的能力，让你能够找到别人无法找到的解决方案。 这也是你有时会错过截止日期的原因。 同样的特质，不同的结果。” 这种简单的框架重塑有助于人们停止为自己的“缺陷”而自责。
  2. 清晰明确地说明情境。 不要让人猜测他们的自然倾向在什么时候有帮助，什么时候会造成伤害。 我的一位工程师非常乐于协作——没有得到每个人的意见，他不会做出任何决定。 我明确地告诉他这种做法在什么时候有效，在什么时候无效：“对于架构决策？ 尽可能多地征求意见。 对于日常编码决策？ 你有权直接决定并继续前进。” 这种明确的指导帮助他培养了自己判断何时应该发挥他的协作天性的能力。
  3. 将紧张关系视为一种特性，而不是一个bug。 有些管理者试图建立一个所有人都以相同方式工作的团队。 那是一个错误。 我曾经将我们最快的编码员与我们最严谨、最彻底的审查员配对。 第一周完全是混乱——他们把对方逼疯了。 到第三周，他们产出的代码比任何一个人单独完成的都要好； 快速编码员开始预测彻底审查员的顾虑，而严谨的审查员则学会了哪些捷径实际上是可以走的。

我们的目标不是创造没有明显优势或劣势的“均衡”工程师。 那是不可能的。 我们想要的是能够了解自己的自然倾向，并能根据具体情况进行调整的、有自我意识的工程师。

我不认为我们的工作是磨平人们的棱角，直到每个人都变成同样无聊的形状。 我们不是试图“修复”我们的工程师。 相反，我们是在帮助他们清楚地认识自己，包括优点和缺点，并教他们何时应该加强或减弱自己的自然倾向。 这更像是指导某人有效地使用自己的力量，而不是试图从头开始重建他们。

毕竟，我们都是整体打包的。 那些让我们变得卓越的特质，不可避免地会在其他情境中挑战我们。 理解这一点不仅能让我们成为更好的管理者——还能让我们成为更富有同情心的人。