你可能遇到从加入一个技术团最初的兴奋,到“习得性无助”,再到辞职再就业的情况;
看到一篇文章,觉得很有意思,所以翻译下;
欢迎加入大厂有限公司!*
这是你作为软件工程师工作的第一天,你非常兴奋的开始了你的第一次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.
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.
故事通常是这样:
总之,如果一如既往总会有人离开,但是领导仿佛毫不知情。
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.
作为一个团队成员或者领导,我们试图去创建一个更好的团队文化,习得性无助的行为会导致人才的流失,我们应当找到一个方法去规避,让我们看下我们可以做些什么。
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.
在我们采取行动之前,需要先意识到这种现象。正如上文提到的,这种现象是很难自然而然的暴露出来。所以,接下来我们将分享如何发现这种习得性无助的行为正在发生,应当如何采取行动。
* 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.
* 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.
* 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.
* 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.
* 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.
* 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".
* 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.
* 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.
希望这篇文章讲清楚了团队中反复出现的问题的根源,并为你提供解决问题的关键。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。