想在工作中更有效?别再执着于证明自己是对的

a man explaining something to his colleague
Wanting to be right can result in being less effective.Image: Unsplash/Medienstürmer
本内容由人工智能自动翻译。
  • 这位工程总监指出,无论在职场还是其他场合,执意想要证明自己是对的,实际上可能阻碍进展。

  • 仅仅为了证明自己是对的而与人争辩,可能是在浪费精力。

  • 她说,正确性体现在机制上,而有效性体现在结果上。

  • 在出现分歧时,重要的是先就问题达成一致,这样大家才能理解解决方案应当实现什么目标。

我和伴侣最近经历了一次糟糕透顶的搬家。我们很幸运,房东是友善、通情达理的人;但我们也很不幸,他们相当缺乏条理,许多该做的事情都没有做,比如订购家具,以及彻底清理上一位租客留下的痕迹。

事情就这样发展下去:我们住在酒店里,身处一个对我而言全新的国家,他既要适应新工作,我还要兼顾原有的工作,再加上一切都乱成一团,我们之间的分歧开始显现。

作为软件工程师的伴侣说:“他们应该把这些事情办好。”而我作为工程总监,开始制定风险缓解策略。

遗憾的是,由于我们在战略层面未能达成一致,我的风险缓解策略只得到了部分执行。等我们终于能搬进去时,我又花了一周时间,被残留的猫咪气息慢慢窒息得喘不过气来。

如今我和伴侣已经和好了。而且我们短期内应该不会再经历类似的事情,因为我们不太可能进行频率超过每隔几年一次的国际搬迁。但我每天在工作中都能看到类似的情形。具体来说,我看到一些非常享受证明自己是对的软件工程师,于是我会问他们:“你是想证明自己是对的,还是想做到有效?”

我也时不时会陷入争论,并会问自己同样的问题。

正确与有效

想要证明自己是对的,这种心态是可以理解的,尤其是在软件工程这类工作中;我们的“正确性”正是推动工作完成的方式。我们接手一个问题,将其拆解、实施,然后交付。有些人会做得过火。他们会说“在我的机器上是好的”,或者“问题出在键盘和椅子之间”。即便是那些不那么令人反感的人,也会从工作的具体性和可衡量性中获得安慰。它通过了测试,推动了指标,它是正确的。

随着规模扩大,我们自然会与更多的人合作。如果我们仍然执着于寻求绝对的正确,就可能忽略整体目标。如果你负责的项目需要A和B都交付才能运转,而其中一方未能按时交付,那么你的项目也就失败了。你完全可以合理地把问题推给未能交付的团队(即表明自己“正确”)。但如果你能回溯过去,预见问题并降低风险,那么你就能够有效。

执着于正确的风险在于,它会优化错误的目标。正确性体现在机制、架构、测试覆盖率,以及每个人都严格履行了自己的承诺之中。而有效性则体现在结果上。

就问题达成一致

我经常发现,当我察觉到“正确与有效”之间的分歧时,问题往往在于:那些想要证明自己是对的人,在尚未就解决方案的目标达成一致之前,就急于提出自己的答案。

不久前,我的一个团队就是否在需要进行紧急修复(hotfix)时启用事件应急手册(即我们的标准应急响应程序)展开了争论。紧急修复(即在实时系统中修复漏洞的计划外编程)。这看起来像是一个枝节性的流程问题,怎么会如此重要呢?但大家的立场非常坚决。然而,一旦讨论转向问题本身,并以数据加以衡量(例如,我们最近进行了多少次紧急修复),团队便迅速解决了**双方**的分歧与问题。双方的分歧与问题。

当你觉得讨论缺乏建设性时,不妨试着问一问:“我们究竟想解决什么问题?它是如何表现出来的?会产生什么影响?”如果你想推行流程变革,首先要非常清楚自己想解决的问题,并让团队认同**这一点**。这一点。

提出解决方案并修复问题的人,固然令人欣慰,但若要转向有效的思维模式,就意味着你要放下非得由自己来修复问题的执念,转而扮演促进事情推进的协调者角色。如果你能让团队就问题达成一致,然后由别人提出你心中设想的解决方案,那便是巨大的胜利。这说明解决方案从来都不是问题所在,真正的问题在于对问题缺乏深入的洞察。

选择将精力投入争论,还是不争论

有一幅精彩的XKCD漫画,讲的是一个人因为“网上有人说错了”而无法从办公桌前站起来。但无论是在网上还是工作中,你都可以允许别人犯错,尤其是在这些错误并不会真正影响到你的时候。

如果有人认为发布当天必须穿上自己的幸运袜,或者认为一对一会议绝不能安排在满月前后的日子,这或许显得十分古怪,但如果这些想法并不会真正影响任何人,又何必担心呢?

从实际问题的重要程度来看,关于风格的分歧,例如有人喜欢蓝色,有人喜欢绿色,句号后面加两个空格还是一个空格,都只是风格上的分歧而已。给出反馈,然后放下。引用风格指南即可。陈述自己的偏好,然后继续前行。

很久以前,我目睹了一个邮件线程中长达100条消息的争论,内容是代码条件判断代码条件判断应写作'var == const'还是'const == var'。我无法相信那个线程耗费了那么多时间和精力,但发起讨论的人却很享受这场争论,直到最后有人插话,说出了我一直以来的想法:如此微小的事情却投入了如此多的思考,让他们不禁怀疑,因此还有什么其他事情没有被思考。

有些人确实乐于争论,但如果你不喜欢,也没有问题。你完全没有必要参与那些编译器本来就会检查的琐碎辩论。事实上,如果你不喜欢争论,就更有理由避免参与。把精力留给真正重要的事情。

当我在指导他人(或自己)判断是否要就某件事展开争论时,我会问:

  • 这件事对你为什么重要?

  • 它如何影响你的效率?

  • 什么情况会使它成为问题?

这些问题有助于我们找出真正的问题(如果确实存在问题),并由此进入我们真正希望展开的对话。

如果某件事会对你的效率产生重大影响,那么为此据理力争就是有道理的。如果你最大的问题是招聘,而某项改动会使招聘显著变得更加困难,那么你的工作就即将变得困难得多,这是你应当解释并加以反对的。如果你们整体的交付情况相当不错,但你担心这项改动会在人们适应期间让交付略有放缓,那么这大概是可以应对的。

当我们问“什么情况会使它成为问题?”时,它能够阐明我们所担心的二阶效应,因为分歧往往不在于当下的决定,而在于如果同样的做法持续下去,会对未来的决策产生何种影响。也许某位备受瞩目的人才获得了超出薪酬区间的报酬。问题是否在于这位特定的人才和这份特定的薪资?你是否希望在这一点上争论?还是问题在于,如果这种情况反复发生,就会完全抵消你们现有的薪酬区间体系,并使现有的工程师薪资偏低?也许真正的论点应当是:如果未来需要再次出现这种情况,就应当启动一次全面的薪酬评估。相比于说服大家牺牲一位他们明显想要留住、并视为某方面卓越的人,让大家同意这一点可能会容易得多。

无论是为长远考虑而争论,还是为眼前的事情而争论,请记住:让分歧变得更简短、更具建设性,其影响可能与最终实现你所期望的结果一样大。

保留异议,坚决执行

在我之前的一份工作中,一次组织架构调整期间,受影响团队的负责人调往了另一个团队。调整方案的设计者对此很不满,并将其定性为该负责人不愿意“保留异议,坚决执行”。有人指出,“保留异议”和“坚决执行”实际上是两件不同的事情。如果这位负责人无法坚决执行,那么他转到其他团队就是合理的。

这彻底改变了我对“保留异议,坚决执行”这一概念的理解。分歧可以是一场持续进行的对话;我们可以根据自己为何反对、反对什么,来强调不同的方面。如果我们强烈反对某件事,就应当慎重思考自己愿意承诺和不愿承诺什么。通过有意识地拆解自己的分歧,并审慎选择参与哪些争论,我们就更有可能分辨出其中的区别。

在我上一份工作中,有一天,我和同事们就是否引入一套工程职级体系来界定职业晋升展开了冗长的争论。这样做有充分的理由:它有助于让员工感受到成长与认可,这也是它成为行业标准的原因。我的看法是,它并非万能良药,尤其不适用于那家公司(那里它不会得到薪酬的认可或与薪酬挂钩)。而且我怀疑它总体上是否能带来净收益,因为运行晋升流程非常耗时,而且你不只是要晋升员工,还必须告诉其他人他们没有获得晋升。总之,这场争论一直持续,直到我说:“好吧,我不会成为那个负责执行的人。”随后争论便结束了。我不确定他们是否原本期望我来执行,或者这句话是否让大家明白,其实也没有其他人愿意去做这件事。

“我不会成为做这件事的人”这句话,我会极其审慎地使用,但那次经历在某种程度上让我看清了自己所拥有的影响力。愿意承诺使用某样东西,并不等于承诺去做某件事。

在一个人们会以“欢迎来到混乱之中”迎接新员工的地方工作之后,为了保持内心的平衡,我开始认为,只要事情足够正确,我便能够保持有效。并非一切都必须完美无缺,只需足够好,使我们能够共同把事情做成。

授权与转载
世界经济论坛发布的文章,可依据《知识共享署名-非商业性使用-禁止演绎4.0国际公共许可协议》以及我方《使用条款》进行转载。 本文所表达的观点仅代表作者个人立场,并不代表世界经济论坛的观点。