工程战略应该实现什么，以及工程主管如何指导该战略的制定？
示例策略
我们希望我们的策略解决的主要因素是（例如，我们对我们的情况的诊断）：
- 我们支持三个业务线（消费者、企业对企业和新实验）。80% 的收入来自消费者，20% 来自 b2b，新的实验是预收入。我们预计今年的大部分收入增长将出现在 b2b 领域，消费者收入增长将低于 15%，并且相信未来 3-5 年新实验获得超额回报的可能性很小但确实存在
- 我们是一个拥有 400 人的工程组织（300 名工程师、40 名经理和 10 名技术项目经理）。我们预计在维持当前规模的情况下保持现金流中性
- 在我们最近的开发人员生产力调查中，排名第一的问题 是测试不可靠。此外，我们的测试稳定性仪表板显示稳定性同比下降了约 40%，导致三分之一的构建错误失败
- 自从增加到 400 名工程师后，我们看到文化调查显着增加，人们没有必要的信息来完成他们的工作。在我们跟进时，我们听说人们特别不了解其他团队正在做出的发布和决策
我们解决这些限制的指导方针是：
- 保持 4:1 的产品工程师与基础架构工程师的比例。 这是我们过去几年的比率，而且效果相当好，所以我们打算保持它。
对于我们的下一次战略更新，我们还打算明确打破安全和数据工程比率，希望在我们的人员配置工作中更加慎重 - 目标是将 45% 的产品工程资源用于 b2b，35% 用于消费者，10% 用于新赌注。 剩余的 10% 将专注于对开发人员生产力进行为期 12 个月的投资。 与去年相比，我们正在将大约 20% 的产能转移到 b2b，因为我们看到那里发生了显着的收入增长，而且还没有看到消费者增长反弹。我们希望保持对新赌注的持续投资，但还没有任何东西显示出足够的牵引力来保证分拆到自己的业务线。这种转变将导致一些团队变动。
对开发人员生产力的 10% 投资不会影响团队结构，相反，每个团队将有一部分时间优先用于开发人员生产力工作（在“操作”部分中有更详细的描述） - 保持现金流中性。我们将避免任何使我们出现负现金流的行为。特别是，我们将避免招聘会增加我们现有员工人数的人员。如果保持现金流中性与使用供应商提供商品解决方案相冲突，请与工程主管进行讨论
- 使用我们的标准技术堆栈和流程（或升级到技术规范审查）。 我们对所有项目都使用我们的标准技术堆栈和流程（记录在我们的 wiki 上）。任何想要引入新技术或偏离我们标准流程的项目都应通过我们的技术规范审查流程进行审查。这使我们能够确保我们最大限度地提高开发人员生产力投资和安全投资的影响，促进轻松的跨团队转移，并极大地简化维护我们的合规性控制。
我很欣赏这会让人感到严厉。该政策的目的是确保我们深思熟虑地下注创新，并在进行新的下注之前完成我们的飞行中下注。目的不是避免所有新的赌注，我们鼓励在技术规范审查过程中提出新想法以供考虑 - 如果不清楚并且看起来有风险，或者存在重大分歧，请迅速将技术问题升级为技术规范审查，以及管理链上的其他问题。 如果没有书面决定，这个决定是有风险的或者是陷阱门决定，并且不清楚谁是所有者，那么你应该升级！技术决策应升级为技术规范审查，其他决策应升级为管理链。
升级通常被视为“消极”或“敌对”，但我真的想反驳这种看法。升级是合作的自然组成部分，它使我们能够在必要的背景下快速做出决策，从而做出有效的决策。只有当我们（在技术规范审查或管理团队中）缓慢时，升级才会缓慢，我们应该通过解决延迟来解决这个问题，而不是假设过程本身就很慢！ - tech-updates 中宣布的所有技术更改，shipped 中共享的所有版本。 为了减少未广泛沟通的技术决策带来的意外，以及在其他受影响团队不可见的情况下交付影响跨产品的更改，我们要求分别在tech-updates 和shipped 频道中传达这两种更改。
我们可能需要一个更重的解决方案，但我们想从简单的开始
虽然这些指导政策中有许多是从去年开始延续的，但其中一些确实需要特定的一次性行动来实施：
- 组织更新以将产品工程从消费者转移到 b2b。 我们正在将大约 10% 的产品工程能力转向 b2b 工程，以支持 b2b 的收入加速增长。这将导致多个团队跨组织移动。也会有少数人移动，通常我们正在促进向 b2b 的移动。
请参阅 B2B 优先级更新中的详细信息 - 测试稳定性工作组向前推进。 正如最近的测试稳定性更新中所记录的那样，今年我们将投入 10% 的产品工程时间来提高测试稳定性。我们还将在那里投入大量的基础设施工程时间，测试稳定性是他们的第三个稳定性（仅次于安全性和整体站点稳定性）。
阅读最新的测试稳定性更新以获取更多详细信息 - 技术规范审查：现在也进行轻量级异步审查。 我们要求技术规范审查在审查技术决策方面发挥更大的作用，但与此同时，我们希望了解反馈，即技术规范审查需要 1-2 周的时间才能针对他们提出的许多问题提供可操作的反馈. 我们现在要求所有对 TSR 的请求都从聊天开始，此时 TSR 将在可行的情况下立即异步处理它们，并且只要求更复杂的主题进入每周回顾会议。