I don't want the details

I don’t want the details / 我不想听细节

A few months ago I was dragged into a call with my engineering counterpart and their boss (who happens to be our SVP of engineering). Something had gone wrong that shouldn’t have. Nothing catastrophic, but important enough that I was now on a call with an SVP.

几个月前,我被拉进了一个电话会议,对方是我的工程部门同行及其主管(恰好是我们公司的工程高级副总裁)。事情出了点岔子,本不该发生的。虽然算不上灾难性事件,但重要程度足以让我直接面对一位高级副总裁。

I started to explain how it happened when they cut me off with “Michael, I don’t want the details”. They continued: “I know that if we get into the details, the reasons will be perfectly reasonable. You’ll explain what happened, I’ll understand why everyone made the decisions they made, and I’ll empathise with you. Then it’ll happen again. So I don’t want the details. I want to know what we’re changing.”

我刚开始解释事情的经过,就被打断了:“Michael,我不想听细节。” 他接着说:“我知道如果我们陷入细节,理由听起来都会非常合理。你会解释发生了什么,我会理解大家为什么做出那样的决定,我也会对你们表示同情。然后,同样的事情还会再次发生。所以我不想听细节。我想知道的是,我们要做出什么改变。”

At first I thought “I don’t want the details” sounded dismissive. How can they make informed decisions without understanding the details? Then I realised that “I don’t want the details” wasn’t being dismissive. The executive assumed that we were competent, and was saying “I already believe you. Now let’s talk about what happens next”.

起初,我觉得“我不想听细节”听起来很敷衍。如果不了解细节,怎么能做出明智的决策呢?后来我意识到,这句话并非敷衍。这位高管默认我们是称职的,他其实是在说:“我已经相信你们了。现在,让我们谈谈接下来该怎么办。”

Asking the right question / 提出正确的问题

After something goes wrong, most organizations ask “Why did this happen?” This is a question we’re all familiar with answering. We write up timelines. We reconstruct decisions. We explain dependencies. At the end of it, we hand over a document that contains the specific combination of events that led to the incident. Everyone nods their head, says “that makes sense”, and we all move on with our day.

当事情出错后,大多数组织都会问:“为什么会发生这种情况?”这是一个我们都很熟悉的回答模式。我们撰写时间线,重构决策过程,解释依赖关系。最后,我们提交一份文档,详细列出导致事故的一系列特定事件。每个人点点头,说“很有道理”,然后大家就继续忙各自的事了。

Understanding an issue is not the same as fixing it. A good explanation can make things worse. Once everyone agrees that the behaviour was reasonable, the urgency to change anything disappears. When an incident is an unfortunate but understandable sequence of events where no-one is at fault nothing changes. Then the same thing happens six months later, and everyone is left wondering how we landed here again.

理解问题并不等于解决问题。一个好的解释反而可能让情况变得更糟。一旦大家都认为当时的行为是“合理的”,改变现状的紧迫感就消失了。当一起事故被归结为一系列不幸但可以理解的事件,且无人需要负责时,什么都不会改变。于是六个月后,同样的事情再次发生,大家又开始纳闷:我们怎么又陷入了这种境地?

To drive change in your organization, don’t ask “why did this happen?”. Instead, ask: “What are we changing so that the same class of failure is less likely next time?”

想要推动组织变革,不要问“为什么会发生这种事?”相反,你应该问:“为了让同类故障在下次发生的可能性降低,我们要做出什么改变?”

Reasonable people / 合理的人

The SVP wasn’t interested in understanding how the issue happened or who was involved. They didn’t want to be convinced that everyone involved behaved reasonably. That’s a baseline expectation. Their question became: “Given that reasonable people produced this outcome, what needs to change?”

这位高级副总裁并不关心事情是如何发生的,也不关心谁参与其中。他不需要被说服去相信所有相关人员的行为都是合理的——那是基本要求。他的问题变成了:“既然是理智的人导致了这样的结果,那么需要改变什么?”

Consider these examples: “We missed it because Alice was on holiday and Bob thought the Widgets team owned it.” Okay. How do we make ownership unambiguous when someone is unavailable?

看看这些例子: “我们漏掉了,因为 Alice 在休假,而 Bob 以为是 Widgets 团队负责。” 好的。那么当有人缺席时,我们该如何明确责任归属?

“The requirements changed three days before launch.” Of course they did! What happens when requirements change inside the launch window?

“需求在发布前三天变了。” 当然会变!那么当需求在发布窗口期内发生变更时,我们该怎么办?

“The alert fired, but the on-call engineer had already dealt with twenty low-value alerts that evening.” Makes sense. How do we improve the signal to noise ratio of our alerts?

“警报响了,但值班工程师那天晚上已经处理了二十个低价值警报。” 有道理。那么我们该如何提高警报的信噪比?

Focus on changing the system. The people are usually not what needs changing.

专注于改变系统。通常需要改变的并不是人。

A good explanation is not a fix / 好的解释不是解决方案

If your postmortem is full of sentences like “we should involve support earlier” and “we need to communicate better”, or my personal favourite, “we’ll be more careful next time”, you have a collection of hopes dressed up as progress.

如果你的事后总结(postmortem)里充斥着“我们应该更早让支持团队介入”、“我们需要加强沟通”,或者我个人最喜欢的“下次我们会更小心”,那么你拥有的只是一堆伪装成进步的愿望。

If your corrective action depends on people remembering a conversation from six months ago, you don’t have a corrective action. You have organizational folklore. If everyone involved in the incident left the company tomorrow, would the fix still work? If the answer is no, the people may have learned something while the system is still destined to fail.

如果你的纠正措施依赖于人们记住六个月前的一次谈话,那就不叫纠正措施,那叫组织传说。如果所有参与事故的人明天都离职了,这个修复方案还管用吗?如果答案是否定的,那么虽然人可能学到了教训,但系统依然注定会失败。

For a postmortem to drive lasting change, ask: If the same situation happened tomorrow, what would cause a different outcome? A process that forces a decision at this point is an improvement. A system that prevents this class of mistake is stronger still.

为了让事后总结能推动持久的变革,请问:如果明天同样的情况再次发生,什么因素会导致不同的结果?一个能在关键时刻强制做出决策的流程是一种进步。而一个能从根本上防止此类错误的系统则更为强大。

Process for process’ sake / 为了流程而流程

You can take “the system prevents this class of mistake” too far. Not every failure deserves a new process. That’s how you build environments that no-one wants to work in. Sometimes the cost of preventing recurrence is higher than the cost of occasionally accepting the failure, and that’s ok.

你可能会过度追求“系统防止此类错误”。并非每一次失败都值得建立一个新的流程。否则,你只会建立起一个没人愿意工作的环境。有时,防止复发的成本高于偶尔容忍失败的成本,这没关系。

But you need to accept failure with your eyes open. “We are consciously accepting this risk” is very different from “we said we’d try harder and everyone felt better”.

但你需要清醒地接受失败。“我们是有意识地接受这种风险”与“我们说会更努力,然后大家都感觉好受了一些”有着本质的区别。

Trust / 信任

I still think about what the SVP said a lot. What sounded like impatience was a declaration of trust. They didn’t need me to prove that the people involved were competent or well intentioned. They were willing to start there. If the investigation showed otherwise, we could deal with that separately.

我至今仍经常想起那位高级副总裁的话。听起来像是不耐烦,实则是一种信任的宣言。他不需要我证明相关人员是称职的或动机良好的。他愿意从这个前提出发。如果调查结果显示并非如此,我们可以另行处理。

What they didn’t want was for empathy to become the mechanism by which the organisation absolved itself of having to change. People are usually making the best decisions they can with the information, incentives and constraints around them. That’s why fixing the people is often the wrong answer.

他不想看到的是,同情心成为组织逃避变革的借口。人们通常是在现有的信息、激励和约束条件下,做出他们所能做出的最佳决策。这就是为什么“修理人”往往是错误的答案。

Sometimes the most useful thing a leader can say is: I believe you. I don’t need the details. Tell me what we’re changing.

有时,领导者能说的最有价值的话就是:我相信你。我不需要细节。告诉我我们要做出什么改变。