习得性无助的发现和改变

你可能遇到从加入一个技术团最初的兴奋，到“习得性无助”，再到辞职再就业的情况；

看到一篇文章，觉得很有意思，所以翻译下；

原文链接

这是一个名字叫做“大厂”公司的故事

欢迎加入大厂有限公司！*

这是你作为软件工程师工作的第一天，你非常兴奋的开始了你的第一次commit。当你的新同事老毕给你介绍代码库时，你不禁注意到了老毕一直在回复企微消息，你问老毕“要不你先忙，我们一会在看？”，“不用，这周我负责oncall,我都习惯了，没事哈，着急的都会打电话的”。你有一丝丝的困惑，在企微消息不断弹出的同时，老毕给你介绍着大厂有限公司的代码库的构成。 一年过去了，你在参加老毕离职趴的路上，口袋里的企微消息不断滴滴响，“老毕咋走了呢，没听他抱怨过啥啊”，一边想着，一边把通知置为了静音，“这周贼累，得好好睡一觉才行” 在路上正走着，你听到把你倒挂的应届毕业生参加完封培快乐的交谈。

用刚刚的小例子介绍下习得性无助的概念：

我们开始放弃逃避痛苦，因为我们的大脑逐渐的学会接受在那种情况下我无能为力的设定。“经过某事后学习得来的”无助感，意谓着一种被动的动物消极行为（也包括了人类行为），其中被动的因子占相当多数，尤其指对失败而非成功的反应。

在上面的小例子里，在“大厂”上班就要去时时刻刻的接收on-call信息是一个正常的行为，虽然在其他人看来，这一定是哪里有问题才会有这么多的消息，需要修复这个问题，但是“大厂”员工已经放弃去改善oncall的糟糕体验，他们是被动的，甚至还会做出无法改善的解释，“一直都是这样”，或者“告警了我才知道我的应用是OK的”，直到有一天，他们离职了。

虽然这个例子更多的是一个一线运维的体验（改了下哈，原文已经讲了是个软件开发工程师），习得性无助这种情况也给他们的领导带来了充满矛盾的挑战：领导应该密切关注团队内的幸福感，参与度，骨干留存，但是他们现在遇到的问题本身是什么，无论是例会还是骨干会议都没有人提到这种糟糕的on-call体验，并且员工甚至可能会拒绝尝试改善当前的现状，因为修复问题本身可能有一定的复杂度和并不高的“产出”。

这种习得性无助是如何在团队内发生的

在我们讨论如何去防止习得性无助的行为发生时，我们看下这种行为是如何开始的。

大概有两种情况；

情况一：流程导致的习得性无助

在这种情景下，团队需要遵守内外部强加的但是没有人确切记住原因的一些流程，比如说：

* Engineers need to follow a long deployment checklist or get their deployment approved by several committees (e.g. a security committee and an API standards committee). Soon enough, engineers start self-censoring innovative ideas or tell other engineers that their new features won’t pass the committees' checks.

• 在上线一个功能或者解决一个问题的时候，需要话较长的时间去遵循很长的上线规范，或者得到审批流程的批准，久而久之，工程师就会自我审查创新的想法，或者告诉其他工程师这样的创新不会通过规范或者上线流程的批准。

* A tenured engineer is taking on a very large amount of the code review load for the team, assuming everyone is working as much as them. Other engineers start complaining that this engineer is not very responsive to code reviews.

• 假设每个工程师都会提交较多的代码，这时候骨干工程师需要承担大量的代码review的工作，其他工程师会抱怨review太慢之类。

情景二：复杂度导致的习得性无助

In this other case, the source of powerlessness is sheer scale and/or complexity. There is truly no-one who understands the emergent behavior of the system. For example:

在另一种情景下，无能为力的根源在系统的规模和复杂度上，没有人了解系统紧急现网问题发生时应当如何快速处置。举个例子：

* Slow creep / boiling frog situations where existing tools have become ineffective. This could be a release system involving many manual steps, which worked when the codebase was 1/10th of its current size, and is now requiring an entire release team to be maintained. Paradoxically, this same team might not have time to look for a newer, more automated system.

• 温水煮青蛙；可能是一个涉及到很多步骤的需要人工发布的系统，当代码库是现在十分之一的时候还可以正常的发布，随着功能的增加，代码的增长，现在涉及的东西太多，需要一个发布团队才能去完成一次发布，矛盾的是，这个团队还可能没有时间去找一个更新的，更自动化的发布系统。

* Particularly bad cases of technical debt, where a sub-system or a common library has become resistant to any change. Engineers assigned to these components gradually reduce their ambitions to fix the technical debt, push back on newcomers' attempts to fix the debt, and ultimately ask to get re-assigned somewhere else.

• 技术债是最头疼的；当一个子系统或者一个公共库已经没法去改代码去升级的时候，分配到这些组件的工程师会逐渐降低升级重构的决心，新人去尝试解决这些深坑的时候保险起见也会进行阻止。这些东西一时又下不掉，又会有问题出现。

* In bigger companies, managers forwarding top-down asks and pressure to their teams without pausing to understand the business reason behind the request. In this case, the manager has given up on protecting their team's focus from bureaucratic pressures of various kinds.

• 在大公司，领导会向团队成员透传来自他们领导的要求和压力，有时候没有思考这些要求背后的逻辑是否合理，是否有更优的解决方式，可能只是他们的领导需要的一些需求。在这种情况下，团队领导在官僚向上管理的压力下，放弃了对团队内聚焦的事情的坚持。

后果是怎样的？

故事通常是这样：

1. Employee joins 新员工加入
2. Employee is faced with a first source of learned helplessness. 新员工面临着第一个习得性无助的case
3. Another employee or their manager teaches them it's a normal situation at this company另一个员工或者领导告诉他，这很正常，就是这样的，搞不定。
4. ... many quarters pass and this situation repeats itself many times 很多季度过去了，这种情况会上演很多次
5. Employee quits and their manager is blindsided 员工辞职了，领导觉得人来人去很正常。

总之，如果一如既往总会有人离开，但是领导仿佛毫不知情。

However, if we adopt the point-of-view of the employee, they should have resigned a lot earlier in this process. The main reason they stayed is that they learned to be helpless - not that the situation was improving or even stabilizing.

但是，如果我们站在员工的角度，他们应该更早的辞职才对，他们留下的主要原因是他们学会了和习得性无助相处，并不是在这个环境里能有所成长也不是在这个环境更稳定更有安全感。

As individual contributors or as managers, we also strive to work in and build great company cultures. Learned helplessness can cause a great loss of human talent and we should find ways to combat it. Let's see what we can do to detect and avoid it.

作为一个团队成员或者领导，我们试图去创建一个更好的团队文化，习得性无助的行为会导致人才的流失，我们应当找到一个方法去规避，让我们看下我们可以做些什么。

能做啥呢 What can you do ?

Before taking action, it is important to become aware of this phenomenon. As we wrote above, learned helpessness tends to be hard to detect by nature. In the following sections, we thus share both how to detect that learned helplessness is happening, and then how to take action against it.

在我们采取行动之前，需要先意识到这种现象。正如上文提到的，这种现象是很难自然而然的暴露出来。所以，接下来我们将分享如何发现这种习得性无助的行为正在发生，应当如何采取行动。

作为团队成员 As an individual contributor

发现问题 Detection

* Do not second-guess your intuitions: going back to the BigCo story above, it is easier to have clarity when you are first faced with the issue. In that case, noisy oncall pages. Pay attention to ineffiencies and processes that don't feel useful anymore, and react earlier rather than later.

• 不要怀疑你的直觉：回到上面”大厂”的故事，当你第一次面对这个问题的时候，其实是更容易弄清楚问题背后的原因。在这种情况下，on-call过多这一事情上，要意识到，需要对对低效的和没有用的流程尽快的修复和响应，不要一拖再拖。oncall过多，就是习得性无助的根源之一；

* Take a step back: later on, make sure you regularly assess the "why?" behind your company's processes and cultural norms. In particular, pay attention to what people around you consider "obvious". For example, everyone might consider it obvious that pull requests take more than 3 days to get reviewed. Ask yourself why.

• 站出来想问题；在负责的流程和复杂度较高的部署中，多问几个为什么，特别是那些“就是这样”的事情，举个例子，每个人都觉得审批超过3天才会被通过是合理的，问问自己为什么。流程过于复杂，这就是习得性无助的根源之一。

解决方式 Resolution

* Work with your team to implement solutions: this can either be actively noticing when you are "teaching" others to accept an already broken situation (Bill, in our story), or find creative ways to improve processes. In particular, agile rituals like retrospectives can be pretty effective to raise issues and agree to fix them together.

• 和团队成员一起去实施解决方案：你可以告诉老毕，这种一直oncall的情况是不合理的，找到一个改进流程的方法，向通过迭代会对过往问题进行讨论然后一起去修复就是一个很好的方法。

* Hold managers accountable: one of the key responsibilities of leaders is to create positive change for their teams. Once you notice a situation where you think everyone is in learned helplessness mode, make sure to notify your manager and follow-up until the problem is addressed. It may also be useful to literally frame the issue as a "learned helplessness" situation.

• 告知领导是有责任的：领导的主要职责之一就是为团队带来积极的改变。一旦你发现大部分都习得性无助，一定要告诉你的领导并且跟进，直到问题得到解决，大家都习得性无助本身就是一个习得性无助的情况；

作为领导 As a manager

发现问题 Detection

* Regularly get in your team's shoes: by design, a manager is not involved in every day-to-day activity (e.g. PR reviews, on-call, experiencing the build system, etc.). This is both a weakness and a strength: it can lead you to get disconnected from your team's pain-points but, on the other hand, it will give you a fresh outlook when you do get back to experiencing the life of an IC. For example, you add yourself to the on-call rotation of one of your teams and you realize that it is a terrible experience. People on that rotation might be so used to the noise that they have stopped complaining about it but, as a "newcomer", you quickly spot the issue.

• 定期参与团队工作，在通常情况下，可能领导不会参会与到团队的工作（其他的事情，PR，随叫随到，体验系统的构建等等），不参与团队工作有利有弊，体会不到团队成员的痛点，另一方面，当你重新去参与到工作中时，会带有一个新人的角度。比如你可以将自己添加到一个团队的oncall轮值中，让你意识到这是一种糟糕的体验，但是轮值的的人已经习惯了这种糟糕，以至于都不会抱怨这件事情，但是作为“新人”，你可以很快的发现问题；

* Notice subtle changes in behavior: the most useful hint here is when someone who used to be very vocal about an issue stops complaining. You should not always interpret this change as a positive, "problem solved" resolution. Make sure you seek closure with the person or teams involved.

• 注意团队成员细微的变化，最有用的一个提示是，如果曾经对某个问题直言不讳的人不在抱怨了，可能该问题并不是被解决了。确保与团队成员保持共识。

* Measure: build a list of common sources of learned helplessness (high meeting load, broken CI, build too slow, noisy pages, etc.) and create a set of metrics that you regularly monitor or get alerts on. Having an objective measurement enable spotting abnormal trends that you would otherwise gradually consider "normal".

• 如何更好的测量评估，做一个常见的习得性无助来源列表（经常的开会，不好用的部署系统，部署构建非常的慢，每天的消息过多，等等），并且创建一组定期监控或者获取告警的指标，进行客观的测量可以发现异常的趋势，比如凌晨的告警次数等等，否则你也会慢慢的认为是正常的。

解决方式 Resolution

* Encourage engineers to have autonomy: teaching people — directly and through cultural norms — that they are powerful, not powerless, to change and fix broken things is the key. This means welcoming criticism and enabling people to address problems.

• 鼓励工程师自治，通过团队文化氛围强调所有的问题都是可解的，去修复一个问题是值得肯定的行为，这意味着欢迎团队成员进行问题的提出和解决。

* Declare process bankruptcy: not every process is meant to exist forever. For example, do your engineers really need to fill out a checklist for every PR they merge ? Do you still need that on-call rotation where engineers just acknowledge and silence alerts 99% of the time? It may be more comfortable to not upset the status quo, but more effective to remove useless processes.

• 承认无效流程：在不同的时间和节点可能需要不同的流程，例如一些流程在当时可能是解决特定问题建立的，工程师需要为每个PR填写一份清单吗？工程师只是按了1的告警是否需要继续保留？不打破现状可能更舒服，但去除无用繁琐的流程可能会更有效。

* Start small, lead with empathy: one of the surprising aspects of learned helplessness is that people are so used to a bad situation that they may initially resist your attempts to fix it. Focusing on small, tactical wins can help at first. You might also think that there is obviously an issue, but it's important to reconnect with how your team has been feeling the whole time. It will help you find more effective ways to help them.

• 具备同理心，从小处入手：习得性无助出人意料的一个方面之一是团队成员习惯于糟糕的现状，以至于可能会对试图解决问题的时候有些抵触，可以先从小的方面开始，当有效果时会让团队成员更有动力去解决，了解团队成员的感受，有助于找到更有效的方法来帮助他们。

Hopefully, this article has shed light on a recurring source of issues in engineering teams, and it has given you several keys to solve them! If you'd like to see how Okay can help, let know.

希望这篇文章讲清楚了团队中反复出现的问题的根源，并为你提供解决问题的关键。