虽然围绕收购的讨论通常集中在技术尽职调查和决定是否进行收购上，但随后的整合可能更加复杂。工程中很少有不可逆转的陷门决策，但在集成早期做出的决策往往出人意料地持久。
该工程策略探讨了 Stripe 整合2018 年收购 Index 的方法。虽然商业书籍会重点关注收购本身的基本原理，但在这里，该基本原理仅仅是定义整合权衡的诊断的一部分。集成本身就是重点领域。
与大多数收购一样，负责整合的团队只是在交易结束后才了解该项目，这意味着早期的努力是应用策略测试来区分乐观日期和技术现实的争先恐后。
这是一本关于工程策略的书的探索性草稿章节，我正在#eng-strategy-book中集思广益。因此，一些链接指向其他草稿章节，包括已发布的草稿和非常早期的未发布的草稿。
阅读本文档
要应用此策略，请从顶部的策略和操作开始。要了解此策略背后的想法，请按预留顺序阅读各部分，从探索开始。
有关此结构的更多详细信息，请参阅制作可读的工程策略文档。
政策与运营
我们一开始被收购的工程团队和被收购的工程团队之间几乎没有共同的背景，并且有六个月的时间表来推出联合产品。因此，我们的起始政策是联合改进的承诺和一些临时架构政策的结合：
-
至少每周举行一次会议，直到初始发布完成：Stripe 和 Index 的相关领导将每周举行一次同步会议，以完善我们的方法，直到我们完成初始发布时间表。
本次会议由 Stripe 的流量工程主管和 Index 的工程主管共同主持。
-
最大限度地减少对标记化环境的更改：因为销售点设备直接处理客户付款详细信息，因此直接支持销售点设备的 API 必须位于存储付款详细信息的安全环境中。
但是，不得将任何其他功能添加到我们的标记化环境中。
-
所有其他功能都必须存在于标准环境中：除了进入标记化环境的最低必要功能外，其他所有功能都必须在我们的标准非标记化环境中运行。特别是，任何需要频繁更改或引入复杂外部依赖项的软件都应该存在于标准环境中。
-
推迟做出关于引入 Java 的决定：Java 的引入与我们现有的工程策略不兼容，但目前我们也无法就如何解决这一决定与利益相关者保持一致。此外，我们认为试图解决这个问题会分散我们在六个月内推出联合产品的及时目标的注意力。
我们将在启动初始版本后进行此讨论。
-
升级需要配对线索：鉴于我们跨团队的共享背景有限，所有升级都必须同时提交给 Stripe 的流量工程主管和 Index 的工程主管。
-
对影响代币化环境的变化进行安全审查：我们需要迅速采取行动，推出销售点和支付相结合的产品，但我们不能为了更快地推出而在安全性上偷工减料。必须包括安全性，并明确签署涉及我们代币化环境的任何集成决策
诊断
收购通常分为四类：人才收购，以培养才华横溢的团队；业务收购，以购买公司的收入和产品；技术收购，以增加内部开发具有挑战性的差异化能力；上市时间收购，即您可以在内部开发该能力，但可以通过收购公司来更快地有意义地开发它。
虽然大多数收购都具有其中几个方面的特点，但本次收购主要是一次上市收购，旨在解决这些限制：
-
我们的几个最大的客户正在推动我们提供与我们的 API 驱动的支付生态系统集成的销售点设备。至少有人暗示我们要么在承诺的时间表上提供此功能，要么他们可能会转向竞争对手。
-
我们目前没有开发或集成销售点设备等硬件的本土专业知识。基于内部其他零到一的努力，我们相信需要大约一年的时间来雇用团队、开发和推出集成到我们平台中的销售点设备的最低可行产品。
-
我们采用横向方法通过 API 支持网络支付，而我们的竞争对手 Square 至少采用了垂直整合方法。虽然他们的 API 生态系统不如我们发达，但对于可能流失的客户来说，他们是一个合理的目的地。
-
我们相信，如果我们最好的承诺是在 12 个月后推出销售点解决方案，那么至少有一个企业客户会流失。
-
我们决定收购一家小型销售点初创公司，我们将用它来承诺六个月的时间框架，以支持与我们的 API 生态系统集成的销售点设备。
-
我们需要快速整合所收购的初创公司，以满足这一时间表。我们只知道这将带来什么的一小部分细节。我们确实知道销售点设备直接对付款详细信息进行操作（例如，销售点设备知道它所读取的卡的信用卡详细信息）。
我们的合规义务将此类活动限制在我们的“代币化环境”内，这是一个高度安全且隔离的环境，可以直接访问支付详细信息。此环境将支付详细信息转换为唯一的令牌，其他环境可以利用该令牌来针对支付详细信息进行操作，而无需直接访问底层支付详细信息的合规性开销。
-
在这种技术整合中，我们对被收购公司的技术堆栈知之甚少。我们确实知道他们主要是在 AWS 上运行的 Java 商店，而我们主要是在 AWS 上运行的 Ruby（带有一些 Go）商店。
探索
在此次收购之前，我们已经进行了几笔小型收购。这些收购都没有一个有意义的产品可以与我们的产品整合，因此我们没有太多的内部剧本来锚定我们的方法。
在整合我们之前工作过的公司的技术收购以及与其他公司的同行交谈以挖掘他们的经验方面，我们的经验确实有限。综合这些经验，反复出现的模式是：
-
通常，交易团队已经做出了某些承诺，或者被收购的团队已经理解了某些承诺，这将很难实现。当您不知道这些承诺可能是什么时，情况就更是如此。
如果人们似乎表现得很奇怪，这可能是一种误解，值得直接参与来消除混乱。
-
收购应该有一位执行发起人，而发起人通常是询问公司意图的最佳人选。如果你找不到执行发起人，或者他们没有参与，请尝试招募一位新的执行发起人，而不是试图在没有执行发起人的情况下让事情顺利进行。
-
在摩擦很少的地方迅速缩小文化差距，在信任很少的地方谨慎地缩小文化差距。
我们确实需要将被收购的公司融入我们的文化，但我们还有很多年的时间才能做到这一点。最成功的案例是通过将人员调入或调出被收购团队的方式，而不是施加压力。
-
支持新技术堆栈的长期成本很高，并且与我们巩固尽可能少的编程语言的技术战略相冲突。
这不是灵活的地方，因为新堆栈中的每个附加功能都会使您远离所需的结果。
-
最后，找到一种方法来避免关键人员离职的风险。事情可能很快就会出错。最简单的起点之一是立即整合基础设施，即使产品或软件需要更长的时间。
总而言之，这并不是最令人放心的探索：它有点抽象，而且我们的大部分研究都返回了强烈持有的、相互冲突的观点。也许收购，比如创办一家新公司，是根本没有正确方法可以做好的地方之一。