2015年左右加入Stripe时，我记得我曾短暂地试图说服一些团队成员，当它松懈时，我们应该练习适度——它的即时满足的警笛声无疑是诱人的，那些紧密的反馈循环非常令人满意，但许多讨论更适合于电子邮件或GitHub请求。虽然同步通信很好，但async有很多好处：让人们更清晰/简洁地表达想法，让人们更专注于手头的任务，允许其他时区的同事参与，并创建可搜索/可消化的书面记录。
但离我放弃还不到整整两周——这不仅仅是一场失败的战斗，这是一场很久以前就失败了的战斗，失败是决定性的。长时间的交流已经消失，再也不会回来了。在接下来的五年里，我一直在“松懈文化”中运营，我怀疑现在很多公司都在使用这种沟通模式。电子邮件收件箱或多或少是为exec和HR以及JIRA spam的广播保留的。其他一切都是在闲散中发生的。
公平地说，这种模式有相当多的好处。首先，它显著降低了人们阻碍他人的可能性。如果你需要帮助，你可以告诉别人，而且往往会立即得到回复，避免浪费时间。另一个原因是，困难的决定更有可能得到解决——有争议的对话容易在电子邮件中陷入泥潭，但同步进行往往会迫使人们得出某种结论。
但松懈狂热也有严重的负面影响。很少有人会在早上打开Slack，并且已经有3到5次提到需要投入的对话，而不是立即被淹没。很少有人能在10到15分钟内专注于任何事情，而不发出一声松懈的ping，让你转向其他事情。专注于更难的事情是非常困难的，而这些事情需要一段时间才能让人理解。公司规模越大，松弛狂热就越明显，而且每天都在持续——实际上，许多工程师完成工作的方式是在松弛噪音降低（不好）的几个小时后专注于此。
从Crunchy开始的一件不同寻常的事情是，我的一些新同事甚至比我更怀疑Slack。一个已经存在的实践是勤奋的线程处理——不仅是线程处理受到鼓励，而且由于强大的惯例，每个主题都进入一个主题。我们觉得我们的生活依赖于它。
这产生了一个干净的对话模型，与正常的松弛不同，它是选择加入而不是选择退出。即使你打开了频道通知，除非你决定参与，否则你不会自动参与每一个话题。线程也可以在以后释放，以减少嘈杂线程的通知。
从主观上讲，它似乎效果很好。我们保留了Slack的所有优势——低摩擦沟通、广泛参与、根据需要快速同步对话，但不必一天中的每一分钟都与Slack联系在一起。
有人可能会说，这种模式是不可持续的，我承认，就连我在一开始也有过怀疑，但六个月后我来到这里，它仍然像第一天一样有效。我们偶尔需要把人带到系统上，但到目前为止，每个人都很快学会了。
几周前，我把这件事告诉了一位前同事，他也担心自己公司内部的松懈文化。他喜欢这种模式，但怀疑这种模式是否适用于更大的公司。他可能是对的——到目前为止，我们一直有意让团队保持小型化和专注，但随着我们的不断增长，我们可能会看到团队崩溃。