Digg v4 发布时，旧网站关闭了，但新网站却无法启动。当时压力很大，大家都在努力解决问题，但却束手无策。我们花了将近一个月的时间才让网站完全恢复运行。这一个月过得并不愉快，我们尝试了很多次才勉强摆脱发布一个尚未完成、令人绝望的产品的困境。
那次项目启动是我职业生涯早期的一次重要经历。然而，这并非个例，许多领导者都会将这种压力施加在团队身上，作为一种常规的管理手段。以下是我见过的一些缺乏计划的施压模式的例子：
-
前文提到的Digg V4发布在两个方面都面临着缺乏计划的压力。首先，为了激励工程团队，我们设定了一个固定的发布日期，但却没有明确的机制来确保按时发布。其次，发布后需要修复的问题也同样面临着缺乏计划的压力。
-
Uber 的服务迁移有一个明确的平台作为从 Python 单体架构中移除的内容的目标平台，但最初除了摆脱自上而下的压力之外，并没有一个明确的离开单体架构的计划。
缺乏计划的压力几乎是2010年代服务分解项目的标志性特征。Calm和Carta最初的方案也存在一些此类问题，这也是我加入后很快就暂停它们的原因。
-
许多公司仅以指标衡量人工智能的应用就属于这种情况，他们只关注指责不参与，却不去了解不参与背后的原因。（在 Imprint，我们一直努力反其道而行之。）
压力本身往往是有益的，但如果没有计划，压力只会造成混乱，除非你的团队中有一位懂得如何将这种能量转化为有计划的压力的内部领导者。作为领导者，你的目标应该是弄清楚如何成为这样的内部领导者。
成为这样的人不仅是帮助团队成功的最佳途径（说服那些喜欢“无计划施压”的人放弃这种做法……很难），也是最有趣的工作之一。 《构建工程战略》一书中关于战略测试的章节，阐述了我如何在最终确定方案并付诸实施之前，通过迭代不断完善计划的方法，以及我如何将“无计划施压”转化为一种合理的应对策略。
最后补充一点，我认为这种模式的根源在于目标管理的误用。目标管理的理论是，执行团队既要参与目标的制定，也要参与目标的实施。这听起来不错，几乎与《逃离构建陷阱》一书的建议一致。然而，在实践中，我们经常看到高管设定目标，然后管理一个缺乏自主性的团队去实现这些团队认为不可能达成的目标，这恰恰导致了“没有计划的压力”模式。