危机时期寻找领导力

Source: Dev.to

在这种情况下开始写作实在是恰如其分（我甚至觉得有点滑稽）。危机状态有时很难被识别，但一旦看到，就再也看不见了。它那挥之不去的征兆和确认会立刻妨碍生产力，甚至影响理智。绝望、冷漠和漫不经心的情绪开始显现，对更光明未来的希望也可能逐渐消退。本文采用系统化的方法来寻找危机中的领导力，并提供一些技巧和思路，帮助更好地为这种不可预测的未来情境做好准备。

注：危机情境的主题非常广泛，尽管在其他领域也可能有帮助，但此处提供的信息主要聚焦于软件工程。本文最初发布在Medium。

危机时刻

我认为特别适用的 crisis（危机）在 Merriam‑Webster Dictionary 中的一个定义是：

一种不稳定或关键的时间或状态，决定性的变化即将到来

但处于危机状态实际上是相当主观的。是否处于危机取决于个人、团队或组织的判断（即使这意味着需要外部帮助）。那么，你如何得出自己或组织实际上处于 crisis（危机）状态的结论呢？

识别危机情境

在评估情境时应考虑多个因素。根据我的经验，下面列出的几个组别是分析情境时最基本的考虑因素。请记住，进行评估的个人或团队 不一定 必须是随后解决该情境的人。

紧迫性和时间约束

危机情境通常可以分为两大类：

1. 不可预测的危机 – 例如，计算机故障、依赖系统因意外原因被攻击或宕机等。举例来说，这类事件可能导致典型 99 % 正常运行时间 SLA（服务水平协议）中的 1 % 中断。
2. 被忽视的可预测危机 – 例如，预期在即将到来的购物季期间应用使用量会激增，但负责该应用的组织未采取必要的准备措施。

这两类的主要区别在于 时间——在“决定性变化迫在眉睫”之前的时间：决定该事件是否真的构成 危机 的时间，以及决定如何行动（包括决定忽视）的时间。

影响和升级潜力

名字已经说明了一切，但我仍列出一些常见问题，以帮助判断严重程度：

• 这场危机是威胁生命还是威胁业务？
• 有多少客户受到影响？
• 这将花费我们多少成本，且在危机缓解之前的运行费用是多少？
• 这场危机的可见度如何？它会以何种方式损害我们的品牌？

不确定性和缺乏方向

这种类型的危机通常难以识别，因为它主要与组织内部的领导层或当前业务/行业状态有关。团队成员出现 斯德哥尔摩综合症 的迹象并不罕见，这会让停止并清晰评估情境变得格外困难。我发现有效的做法是始终聚焦数据，进行数据驱动的危机识别和决策。

寻找领导力

我们已经审视了在识别危机情境时的几个不同方面和迹象，但如果每次危机发生时，总有一位领袖（有时是未知的）站出来，其他团队成员随之团结起来，一切顺利进行，那该多好啊？虽然这种情形听起来像乌托邦，但它确实真实存在。只要深入探查，你可能会发现一个非常灵活的团队或组织，为此付出了大量努力。

采取行动的重要性

除非实际参与权衡或解决情境，否则任何识别因素都无关紧要。这种参与本身就是采取行动的一部分，我认为这是领导力的首要品质：在树立信任的同时果断行动。

经验、信心与信任

这三种品质并不是谈论领导力时唯一出现的，但在缓解危机情境时尤为重要。如何在人员中发现这些品质，以便以最小的损失达成危机解决？你培养它们。

积极的经历培养信心；信心促成信任；信任使果断行动成为可能。循环往复，增强组织应对未来危机的能力。

信心与信任

每种情况都是独特的，但我发现，无论领导者是团队熟知的、组织内部成长的，还是外部招聘的，积极的经历在塑造领导力特质方面都起关键作用。

一个关键点是，个人or组织must为人们创造尝试领导的机会，并发现他们的特质最受重视的地方。无论经历是积极还是消极，它都提供了关于优势和劣势的信息，使团队能够专注于最合理的方向。这就是所有权和关注领域发挥作用的地方。

---

Source: …

指派所有权

在多机组飞机上，虽然有不止一名飞行员能够操作飞机，但在任何时刻只有一名飞行员实际控制飞行操纵杆。这个“双飞行员问题”催生了 Pilot Flying (PF) / Pilot Not Flying (PNF) 概念，明确规定谁负责驾驶飞机。

在长途飞行中，当 PF 想要休息时该怎么办？
根据 ALC‑36: Positive Aircraft Control — FAASafety.gov 培训课程，需执行 “Positive Exchange of Controls” 程序：

1. 教官对学员说：“你现在拥有飞行控制权。”
2. 学员立即确认：“我拥有飞行控制权。”
3. 教官再次确认：“你拥有飞行控制权。”

还需要进行目视检查，以确保对方真的已经取得控制权。

虽然在软件工程环境中此程序看似繁琐，但 明确的角色分配和所有权同样至关重要。在许多团队中角色已经事先定义，但危机情境往往前所未有。此时，角色和所有权可能需要在危机期间重新审视。未能做到这一点通常会导致混乱、无所作为，甚至更糟——角色重复，使团队朝相互冲突的方向前进。

总体而言，每一次危机都是促进经验的机会，但必须考虑危机的严重程度以及组织的风险容忍度。

以身作则

这里有一个情节转折（也许并不适用于所有人）：领导力 不仅仅是管理人员。你不需要正式的团队负责人才能成为领袖。通常，领导力关乎激励和驱动力。

设想一次危机，某个特定团队被指派去应对。团队负责人可以提供激励、协调和促进，但 任何被随机挑选的团队成员同样展现出领导力——无论他们是否愿意。该成员处理自己负责的领域并与团队其他成员沟通的方式，实际上就是领导力，并且有助于他们的经验和成长。

---

恢复

当我们讨论危机情境中的领导力时，恢复是不可避免的。个人或团队在危机中消耗的能量越多，他们就需要越多的时间来恢复和补给。

上升的必将下降。

花时间进行恢复可以说是最常被忽视，却也是最关键的领导力方面。在体能训练中，恢复才是真正塑造和强化肌肉与组织的过程，为未来的表现做好准备。在工程领域，恢复期提升士气和信任，不仅对领导层，而且对整个团队都是如此。

回顾

回顾（也称为事后分析）是对一次事件从发生到解决的审查。它必须在安全的环境中，以不追究责任的态度进行。

关键点

• 让所有参与事件的人以及在适当情况下的相关利益相关者都参与进来。
• 旨在提升对未来危机的准备和应对能力。
• 加强团队动态和跨团队沟通。

---

庆祝

在化解危机后进行庆祝至关重要，原因如下：

• 它肯定了克服挑战所付出的辛勤工作、韧性和团队合作。
• 它提升士气，强化社区感。
• 它营造积极的文化，鼓励持续的参与和动力。
• 它提醒每个人自己的能力以及他们贡献的重要性。

通过有意创建体验、明确所有权、以身作则、留出恢复时间、在回顾中反思以及庆祝成功，团队可以建立信心、信任和持久的领导力品质。

庆祝成功

花时间庆祝能够强化积极的思维方式，增强团队内部的纽带，为持续的成功和成长铺平道路。

---

下一场危机

恢复的一部分与为下一场危机做准备有关。根据危机的可能性以及系统需要的弹性程度，可以引入Chaos Engineering和其他技术。然而，在为——甚至正在经历——下一场危机做准备时，需要牢记以下几点。

---

救世主情结的危险

我将其与心理学中的 Savior Complex 综合症联系起来。在软件工程环境中，个人或团队常常被“自愿”承担任务，因为这更容易且“上次有效”。反复把这种压力加在同一个人或团队上，会形成单点故障。

• 如果下一次危机发生时，那个人正处于假期或病假中怎么办？
• 救世主情结会侵蚀“安全空间”——其他人可能因为害怕失败而不敢站出来，或者变得被动，认为“我们已经有救世主了”。

未来的危机是让其他个人或团队获得经验的绝佳机会，同时仍需考虑事件的严重性和组织的风险容忍度。

长期危机

当我们比较体力活动——比如马拉松（耐力）与 100 米短跑（爆发）——时，身体的生化反应和能量利用方式截然不同。你可以在短时间内保持高输出 或 在长时间内保持低输出，但两者不能兼得。

危机情境也是如此。如果危机拖延太久（把短跑变成马拉松）或发生得太频繁，团队会变得“受伤”。在软件工程中，这些“伤病”表现为：

• Silent quitting
• Burnout
• High turnover

如何防止受伤

1. 引入频繁的恢复
   将整体危机拆分为短期里程碑，每个里程碑后都安排一次简短的恢复和认可时间。
   如果业务负担不起这种做法，请考虑下一个选项。

2. 实施个人或团队轮换
   把危机当作接力赛——将接力棒交给下一个个人或团队。
   例如，值班轮换可以让团队保持准备、专注和积极性。

结论

每个组织和团队都不同。评估和应对危机的最有效方式是诚实沟通。