十多年前，我打出了几段笔记，标题为“建立技术杠杆”，然后就忘记了它。这些笔记来自与时任 LinkedIn 工程高级副总裁 Kevin Scott 的一次会议，当时我们在硅谷徘徊，试图说服潜在收购者购买 Digg 。直到今天早上，当我开始尝试为这篇文章命名同一主题时，我才想起这篇文章的存在。
十年后，我对这个问题积累了更多的思考。从一些定义开始：
- 这里的技术杠杆意味着“使用软件和软件系统解决问题”。它是杠杆的一个子集，还包括使用培训、改进流程、沟通等来解决问题
- 我在行业中看到的技术杠杆有两大类：工作流程改进和产品功能
- 工作流程的改进通常是为了提高效率（例如，新代码的部署速度更快，数据库迁移不太可能破坏生产）
- 产品功能使以前不可能的事情成为可能，或者至少快了一个数量级（前者的一个例子是机器学习优化的登陆页面，它为给定用户而不是全局优化内容，后者的一个例子是替换使用完全自动化的工具上传内容的耗时的手动过程）
有了这些基线定义，让我们稍微探讨一下这个主题。
工作流程改进
工作流程改进可提高团队或公司的效率。这实际上可以使其变得更快（例如更快的构建时间），也可能使某些事情变得更慢，但消除了对人类关注的需要（例如金丝雀部署可能会减慢部署速度，但可以使部署更安全地推出，而无需人工监控） ）。
您通常可以通过使用系统思维进行建模来发现工作流程的改进。 （这是一个使用系统思维对示例系统进行建模的示例。）
例子：
- 在 Calm 和 Stripe 中，我们都尝试了金丝雀部署，这样从机器的角度来看，我们的部署速度较慢，但人类能够更快地停止关注，因为他们知道明显糟糕的部署只会出现在少数机器上，并且自动恢复
- 在 Uber，我们构建了一个支持自助服务配置的系统，该系统取代了请求服务然后由 SRE 手动配置的系统。我们保留了对生产中超出特定阈值的计算资源扩展的控制，使我们能够在不减慢实验速度的情况下控制我们最关心的内容
- 在 Calm，我们转而使用功能标志来控制访问，而不是使用部署来控制访问，这使我们能够立即发布和恢复功能，而不需要（相对较慢的）部署
失效模式：
- 不同但不是更好：有时人们说服自己新的解决方案更好，但实际上只是不同。当团队从目标向后推理（“我想使用 Redis”）而不是从问题向前推理（“查询这些不频繁更改的数据会使我们的主数据库超载”）时，这种情况最常发生。
- 现在你有了N+1个解决方案：一个新的解决方案在某些情况下确实更好，但在许多其他情况下并不更好，这样一部分用户有更好的体验，但大多数用户没有，并且你不得不维护还有另一个解决方案。 （这是迁移失败的众多变体之一。）
产品能力
产品功能正在使您的产品中以前无法实现的事情成为可能，或者使当前可能的事情变得更加高效。这种创新需要识别有意义的新事物，对其进行投资直至完成，并说服用户值得采用（甚至在内部），这确实是罕见的三连胜。
例子：
- 曾经一度，在 Calm 上发布新内容需要内容、产品和工程团队之间的大力协调。这意味着新产品开发经常被发布内容的工作打断。我们构建了工具和工作流程，以从发布新内容中完全提取产品和工程，同时还显着加快了内容团队的工作流程。在该项目之前，我们公司的大部分精力都集中在发布内容上。项目结束后，只有内容团队的精力集中在内容发布上
- 有一次，Calm 的增长、产品和内容团队就手动放置新内容产生了争论。布局显着影响内容性能，团队的目标相互冲突（所有内容的性能与给定内容的性能），这引发了围绕内容定位的持续争论。我们用机器学习驱动的系统取代了它，该系统为每个用户优化了内容，并具有新内容的内容测试机制，这使我们能够在不影响整体性能的情况下提供更好的新内容，并且无需人工辩论即可做到这一点。我们能够为各方取得更好的结果，同时消除协调和紧张的一个主要根源
失效模式：
- 为不存在的问题构建能力：通常是因为平台希望产生对解决方案的新需求，而不是服务于当前问题产生的现有需求（例如，内容管理是 Calm 持续摩擦的根源，并且立即对我们的解决方案产生了需求；相反，在 SocialCode，我们构建了一个网络抓取服务，该服务误诊了问题，因为它是从技术优先的角度驱动的，解决的是抓取配置问题，而不是令牌管理，这是真正的需求来源）
- 未能在资金枯竭之前交付：通常是因为该方法的架构不佳，无法支持增量支持。同样，这种情况经常发生，因为您没有要为其构建的具体用户，您可以使用他们所需的特定子集来验证方法，而不是构建整体以支持抽象的未来采用
- 未能推动采用：有许多有用的工具从未被采用。有时这是出于充分的理由（不可靠、太昂贵），有时则是出于不好的理由（涉及的两名高管彼此不喜欢）。任何一种不采用都会破坏你的产品能力
工作流程与能力
工作流程改进和产品功能都很有价值。团队应根据预期的投资回报率和对其风险预算的诚实评估来进行选择。如果您不能承担太大的风险，请专注于工作流程的改进。即使您可以承担一些风险，也不要同时尝试太多的产品功能 – 它们往往具有很高的失败率，并且您希望快速学习，以便可以继续进行下一个。
我的经验是，大多数工程组织都在努力完成启动产品功能所需的三项任务：识别、资金交付和推动采用。有一些技术可以帮助解决这个问题：
- 识别机会：产品发现的核心技术
- 资金交付：在您能够为整个项目提供资金之前，通常通过解决用例有限的特定用户来确定增量可交付成果
- 推动采用：尽早为一些最困难的客户构建，以避免您的解决方案根本不适合他们的可能性
我的规则是，产品功能只有在强大的技术领导、工程主管支持和信任工程主管的更广泛的执行团队的支持下才可能实现。如果没有这三者，很少有产品功能能够成功交付。
谨慎优先
工程组织通常应该在技术杠杆上投入更多资金，但前提是他们有成功这样做的记录。如果您没有成功的记录，请集中精力开始，并建立信心，相信您可以完成此类工作并且它是有用的。
如果您在组织了解如何选择和实施此类工作之前投入过多，那么您更有可能产生大量技术债务，而不是工具或产品的转型改进。好消息是，变得更好是很简单的。这些项目往往会因为非常无聊的原因而失败：在提供反馈之前承担过多的工作，为不存在的用户构建，构建有趣而不有价值的东西。
注意这些风险，随着时间的推移慢慢扩大你的预算，你就会有所感受。如果你被一些有趣的项目分散了注意力，而这些项目并不能为清晰的人解决明确的问题，那么你将度过一个有趣的季度，然后是多年的清理工作。