几年前，我面试了一位担任工程职位的高级领导，并向他们询问了有关规划的问题。我很喜欢他们的回答，“啊，是的，’P’ 字，计划。”这个答案抓住了一个经常听到的观点，即计划是某种商业咒语。即使进展顺利，规划在客观上也是一项艰巨的任务。当情况不佳时，企业会失去数月或数年的潜在进展。尽管存在这些挑战，但引导贵公司的计划朝着正确的方向发展是具有独特影响力的行政工作，并且是有效的行政人员可以大大脱颖而出的领域。
在本文中，我们将介绍：
- 将规划视为一个无限的过程，而不是一个有限的过程
- 讨论大多数公司的默认计划流程
- 将计划分解为三个独立的组成部分：财务计划、功能组合分配和路线图
- 制定公司年度财务计划
- 定义工程的功能组合分配
- 就 3 至 12 个月的路线图达成一致
- 在这三个过程中建立共享时间表
- 探索规划的频繁失败模式
到最后，您将准备好在现有规划流程中有效运作，平衡职能和跨职能需求，并诊断您当前的规划流程可能如何阻碍工程和您的公司。
计划是一场无限游戏
James Carse 的Finite and Infinite Games建议你可以从两个不同的角度来看待生活中的大多数事情。第一种是将生活视为一系列有限的游戏，具有明确的规则、一种获胜方式和多种失败方式。第二种是将生活视为一场无限的游戏，其规则由玩家随着时间的推移而演变，目标将继续进行。我发现这种简单的区别通常会改变生活，尤其适用于规划。
尽管规划通常被描述为一个有限的、规则繁重的过程，但我相信规划实际上是一个无限的、持续的、具有动态规则的游戏。在我意识到之前，我会严格遵守每条计划规则，然后当最终计划不是很好时，我会感到沮丧。更糟糕的是，我花很多时间制定的计划通常会在流程完成后一两个月就被抛弃。只有当我能够超越规定的规则时，我才能成为一名有效的计划者。
默认计划流程
当公司拥有数百名员工时，他们大多会采用相同的书面规划流程：
- 每年，执行团队都会商定年度财务计划，包括人员编制计划
- 每个季度（或半个季度），执行团队都会创建一个计划工件来描述下一个季度的计划，例如每个团队的目标和关键结果 (OKR)、目标业务成果或要交付的项目列表
- 团队负责根据四分之一或一半的计划管理自己的执行，使用他们选择的流程，例如 Scrum、敏捷
- 可能会有每月一次的执行审查来跟踪公司目标的进展情况，例如业务审查
这个过程在各个公司并不完全统一，细节上确实有所不同。有公司特定的详细信息，例如流程何时发生、您需要向谁交付什么文件、预算如何运作等等。不同公司之间特别不同的是规划的实际运作方式。虽然执行团队名义上会遵循上述规划模式，但总会有另一层基于他们行为的紧急规则。例如，一些公司有一个明确的财务规划流程，执行团队制定了一个共享的年度财务计划，但在实践中，个别高管私下建议 CEO 增加其职能部门的人数。如果 CEO 奖励那些私人升级，那么这将成为真正的过程，而共同制定的财务计划将成为礼貌的虚构。
即使在执行团队真诚合作的公司中，也会出现使当前计划无效的新信息：\
- 您开展业务所在的国家/地区可能会出人意料地通过隐私法规
- 财务合作伙伴可能倒闭
- 您可能会使用离散的时间表来解决可访问性诉讼以进行改进
从有限博弈的角度来看，更新您的计划以解决这些新问题是失败的，但从运营良好业务的角度来看，您显然希望根据解决当前而不是上个月现实的计划来运营。
规划的三个离散组件
如果规划过程没有共同的目标，规划往往会成为一个臃肿、超载的系统，无法解决许多问题。您将遇到规划流程，这些流程将大部分时间花在您是否已完成安全审查、确保您正在为跨职能项目配备人员或验证员工人数规划是否与招聘能力保持一致上。这些都很有价值，但它们可以在规划过程之外解决，并且会分散规划最有价值的地方。
你的计划过程将是有效的，因为它可以做好三件事：
- 按照年度财务计划中的记录，设置贵公司跨职能的资源分配。该计划设定了按职能和业务线细分的收入和支出目标。从中您可以回答诸如研发 (R&D) 与销售和营销 (S&M) 或一般与行政 (G&A) 的相对投资以及公司产品或业务部门之间的相对投资等问题。
- 更新您的工程战略资源分配，特别关注功能优先级和业务优先级之间的工程功能组合分配。这里有一些细微差别，因为公司在工程职能范围内考虑的内容几乎没有一致性，例如，可能会或可能不会包括安全性。
- 与您最亲密的跨职能合作伙伴合作，尤其是产品和销售（或您公司内任何领先的上市职能部门），以建立高水平的季度或半年路线图。这是关于工作范围和时间安排的跨职能协议。
在这三个不同的阶段进行规划可以减少每个步骤中的依赖项数量。更少的依赖性导致更简单、更集中的过程。尽管您可能会做出相反的假设，但我发现以这种方式人为地分解计划可以提高决策质量。例如，财务计划侧重于收入、支出和员工人数，同时保持路线图和职能组合分配不变。这意味着您可以专注于合理正确地制定财务计划，而无需就特定产品发布进行辩论。一旦您开始兼顾财务计划的细节与产品发布以及功能和跨功能优先级的组合，事情就会变得更加复杂，但很少会更准确。
这些约束创造了更好的决策，一方面是因为约束推动了创新，另一方面是因为消除约束会产生过于简单的神奇思维，例如电子表格显示本季度工程量增加三倍将使产品速度增加三倍。一开始使用顺序约束进行规划感觉不自然，但最初的不适是值得的。
我并不是说你永远不应该改变你的财务计划或永远不要改变这个顺序之外的路线图。如果您完成规划路线图后仍然认为有必要调整员工人数，那么进行该讨论是合理的。然而，我坚信对这些讨论进行排序，而不是将它们串联起来，以便做出更有针对性、更严格的决定。
制定您的财务计划
在您作为一家私营公司的工程师的非执行职业生涯中，您可能永远不会看到您公司的财务计划。如果您确实看到了它，您可能只会短暂地一闪而过，而没有时间深入研究并理解这些数字的含义。当您最终意识到您公司的财务计划是所有公司计划的基础时，这很容易让您在执行角色中感到惊讶。
下表显示了一个财务计划示例，其中包含每个业务线的收入目标以及该业务线内每个职能部门的支出。这些是包含大量数据的密集文档。
例如，这张图表显示消费者业务线同比增长 31%，收入 6.25 亿美元，支出仅为 1.33 亿美元。相反，企业业务线增长更快，同比增长 95%，但支出为 9600 万美元，收入仅为 5200 万美元。只有这两行，您可以对这两个业务线进行一组非常有趣的讨论。
您的执行团队需要每年汇总一份更新的财务计划，这归结为生成三个特定文件：
- 您的损益表显示收入和成本，按业务线和功能细分。
- 您的预算按功能显示更详细的费用，包括供应商、承包商和员工人数。
- 您的人员编制计划显示了组织中的特定角色，并强调了要雇用的新角色。
有了这三个文件，就有了足够的约束来开始你的规划过程的其余部分。这并不是说将这些文件放在一起很容易，它们可能相当困难。
从工程的角度来看，好消息是您是制定财务计划的利益相关者而不是直接负责。每个财务领导者在细节上都会有自己的不同，但希望执行团队和业务线领导者对一系列建议进行迭代，直到你完成一些没有人非常满意但似乎有道理的事情。
根据贵公司所处的阶段（例如 B 轮与 G 轮）以及您是上市公司还是私营公司，此过程会有很大不同。寻找同行公司的流程，而不是效仿您以前工作过的大得多的公司。但请记住，这些计划本质上是低准确性的，因为它们依赖于预测财务结果，而没有明确的产品路线图或不知道今年可能会带来什么混乱。稍微强调一下细节，但不要让自己筋疲力尽。
推理工程在财务计划中的作用
从执行团队的角度切换到工程执行人员的角度，问题变得简单一些。工程部门很少直接对收入负责（尽管几乎总是间接对产品或销售部门的收入负责），因此您对财务计划的主要贡献是管理工程部门的费用。
我建议按业务线和三个特定类别划分工程费用：
- 工程部门的人员开支
- 生产运营成本（大部分云成本、与生产相关的供应商成本等）
- 开发成本（与 CI/CD、运行测试、开发环境等相关的供应商和托管成本）。
在这些细分市场中，您应该将最少的时间花在收入增长快于支出（业务质量已经提高）的业务线上，而将大量时间花在所有其他业务线上。
对于费用增长快于成本增长的任何业务线，您和整个执行团队应该对何时以及如何扭转设置有一个清晰的、有记录的假设。这并不总是一个问题，例如，预计新的业务线会在该阶段花费一段时间，但整个执行团队在每个给定业务线上执行相同的订单是至关重要的。
为什么财务规划应该是年度流程？
贵公司的财务计划是每项职能的基本约束。大多数公司会在一年中调整他们的计划，这是合适的，但我认为，如果你按照计划来运作，那么作为一个执行团队和一个工程部门，你会更有效。
这有以下三个核心原因：
- 过于频繁地调整您的财务计划会导致无法对执行进行分级，因为您的目标会不断变化。
- 对您的财务计划进行重大调整是一项计划密集型活动，需要大量时间来处理许多职能。因此，更改计划会造成很大的混乱，并且通常需要重新设计其他计划组件。
- 像所有良好的约束一样，如果您使计划持久，那么它将使团队专注于在其中有效执行。如果你让它变得灵活，那么团队将转而专注于移动约束（例如要求更多的员工）。前者优于后者。
当然，如果您必须这样做，那么您就必须这样做，但是通过稳定的财务计划来经营一家有效的公司要容易得多。
将成本归因于业务单位
早期的公司只有一个业务，这使事情变得简单。所有工程成本都与经营该业务直接相关。随着公司的发展，它们最终会扩展到多个业务线，这时事情会变得有点棘手。
当你深入研究时，即使是最简单的归因也会变得混乱。例如，考虑像 Figma 这样的公司，它拥有一个核心产品，但可能将其业务分为两个业务部门：企业和其他业务。两种情况下的核心产品是相同的，但许多企业功能对非企业购买者没有价值。在这种情况下，很容易将以企业为中心的产品工程师归于企业业务部门，但不太清楚应该如何将构建核心产品的产品工程师归于该部门。按收益归属？将所有成本归因于非企业部门并人为地显示企业部门的高利润率？做点别的？
所有这些问题的答案总是“视情况而定”。我的经验是，这个主题的精确度相对较低。着重于找到财务部门满意的可防御方法，并尽量避免过于频繁地重新提出争议。
为什么财务规划会如此有争议？
在运作良好的管理团队中，财务规划本身并不存在争议。然而，当高管们专注于他们的职能而不是高管团队的共同成功时，分配费用就是一场零和游戏。再加上陷入困境的高管倾向于将预算不足作为业绩不佳的原因，很容易导致高管关系破裂或支出失控。
如果您的财务规划过程存在争议，我建议您与您的 CEO 讨论一下这个话题。这很可能是一个执行团队正在努力合作的迹象，或者是某个正在苦苦挣扎的执行官，而不是一个你可以直接解决的问题。
工程师人数增长是否应该限制公司人数增长？
总的来说，我确实认为大多数公司应该将整体员工人数的增长限制在工程增长的增长率上。这创造了经营一家高效公司的责任，即使这样做很痛苦。它还避免了其他组织的扩展速度比工程部门更快的困难情况，最终导致工程部门的带宽不足，无法在公司的最高优先事项上取得进展。
当然，细节总是有例外。 Uber 在使用灵活的工具快速扩展特定城市的运营团队方面做得很好，这些工具赋予了城市团队权力，同时又不让他们的工程部门因请求而超载。如果 Uber 限制了工程人员的运营增长，那么他们很可能会在混乱的高速增长期间失去大量的市场份额。
通知组织结构
每当您要求增加员工人数时，您都应该有一个记录在案的组织设计来合并该员工人数。最简单的方法是使用一些粗略的组织数学：
- 将您的总人数分成八人一组。每一个都应该有一个经理和一个使命
- 将这些团队分成四到六个一组。每个集群都应该有一个经验丰富的经理和一个重点领域（例如消费产品、企业产品或基础设施）
- 继续递归分组，直到你减少到五到七组，这将是你的直接下属。在约 40 名工程师的公司中，您只需要组成一层组，但在约 200 名工程师的公司中则需要多层
虽然这会感觉有点肤浅，但我不建议在财务规划过程中更详细地考虑这一点。实际组织设计的最后阶段必须考虑手头个人的优势和经验，但这种程度的特殊性在财务规划过程中没有帮助。
调整招聘计划和招聘带宽
我要提到的最后一个财务规划主题是，下一层的执行团队和领导者花时间争论不太可能填补的员工人数是很常见的。我发现将历史招聘能力与当前招聘计划进行比较非常有帮助。如果你不太可能根据历史数据进行计划招聘，那么我就不会花太多时间争论这个问题。
这在高速增长的公司中尤为常见，在这些公司中，执行团队并不过分关注研发费用，并且可能会批准大多数员工人数请求。在实践中，这种情况导致研发团队通过获取招聘人员带宽（例如，让特定的招聘人员分配到他们团队的招聘渠道）而不是通过人数批准来获得员工人数。如果您确实遇到这种情况，我的建议是通过成为强大的招聘合作伙伴来使自己与招聘保持一致：招聘人员根据他们的招聘结果进行评分，每个人都喜欢成功。
确定您的功能组合分配
您的工程战略的三个核心组成部分之一是您如何根据当前的优先事项分配工程资源。此功能组合分配适用于跨供应商、承包商和全职员工的整个工程预算。这种分配直接影响规划。
在您的职能分配中要回答的基本问题是，您希望将多少工程能力专注于利益相关者的请求，而不是在明年每个月投资于内部优先事项？这只是一系列百分比，例如，6 月份 63% 的工程时间将专注于跨职能项目，7 月份为 75%，8 月份为 60%。然而，决定这些数字可能很困难，而且它们对公司路线图有重大影响。
下图显示了该问题的一个可能答案，显示了固定的基础设施投资、扩展的开发人员体验投资以及产品工程的临时向内转变。
尽管是一个简单的百分比，但确定正确的百分比分配不可避免地有点棘手。我推荐的方法是：
- 大约每年一次，审查您的全套工程投资、它们的影响以及您尚未进行的潜在投资。从广泛的来源构建潜在影响列表：您的开发人员生产力调查、明确的头脑风暴等。
- 随着工作的完成和新想法的提出，实时更新此列表。
- 随着列表的更新，将您的目标稳态分配修改为功能优先级。具体而言，这是您对专门负责功能优先级的平台和基础设施工程团队的投资。
- 旨在解决稳态分配中的所有职能优先级，但愿意讨论通常从事跨职能工作的团队（例如产品工程）是否应该暂时协助影响特别大或依赖于上下文的项目。
- 将领导时间（包括您自己的时间）投入到修复明显没有产生太大影响的大量分配上。这些是您可以最了解您的组织的地方，也可以做出最有意义的调整。
如果你在争论要在这个过程中投入多少精力，记住它不需要完美，它需要有用。如果你的跨职能合作伙伴和工程师都很高兴，那么你就可以摆脱一些非常轻量级的东西。
为什么我们需要功能性投资组合分配？
如果设定公司的预算和路线图是一项联合工作，那么值得一问的是，为什么设定职能组合分配不是由整个执行团队来完成。答案很简单，职能规划最好由负责的主管和团队来完成。职能分配如此依赖于特定职能的专业知识，以至于在更大的跨职能团队中进行分配会导致更糟糕的结果。
这并不是说职能领导者应该孤立地进行分配。我强烈建议与您的工程领导团队和其他高级工程成员合作，如编写工程策略中所述，然后与同行高管一起验证您的建议。然而，太深入地包括同行高管不太可能帮助他们或你：如果你试图优先考虑你的首席财务官对 monorepos 的意见而不是你的员工工程师的观点，那就大错特错了。
随着时间的推移，通过将功能优先级转换为跨职能优先级来减少对功能优先级的分配，从而解决这个问题的根源。合规性、安全性、可靠性等确实应该是公司的基本工作，而不是无形的工程功能性工作。将工程工作带出职能分配比试图将非工程主管带入要有效得多。
保持分配相当稳定
高管最常见的分配挑战是过于频繁地调整他们的分配。你应该更喜欢连续性和狭窄的变化，而不是不断追求理论上的理想分配。更改分配感觉像是进步，但每次更改都相当具有破坏性，因此频繁更改会带来重大损失。因此，我建议强烈偏向资源分配现状，即使您当前的分配略有欠佳。
不经常更改分配的另一个原因是，团队可能会过于专注于分配分配的竞争，这会导致与同行的零和竞争。这在文化上是一个糟糕的地方，并且会分散创造性解决问题的更有价值的机会，而这在没有跨团队竞争的情况下具有潜在的无限回报。
注意分配粒度
在大粒度（例如基础设施和产品）和小粒度（例如前端平台团队和北美增长团队）分配之间存在固有的权衡。您分配的粒度越大，您的团队就越有能力领导他们的团队。例如，如果您分配给基础设施工程，那么基础设施的领导者有权在基础设施内进行转变。如果您对 Infrastructure 内部的团队进行明确的分配，那么 Infrastructure 的领导者将有义务与您一起改变他们自己的分配。
不要过度依赖早期结果
我在工程组合分配中看到的最常见的具体错误是根据早期结果高估了影响或低估了成本。几个说明性的例子：
- 两名工程师致力于提高构建性能，并在两个月内将构建时间缩短了 50%。他们认为，这表明理论上你应该将 50% 的工程能力投入到开发人员的生产力中，如果不是 50%，你至少应该将团队规模扩大三倍。在这里投资更多很容易，但他们可能（或可能没有）已经获得早期回报，这意味着未来的结果会低得多，
- 两名工程师正在努力将所有前端代码迁移到一个共享的前端 monorepo 中。经过三个月的工作，您获得了概念验证、四个恼火的前端工程团队，但没有任何指标显示有任何改进。取消这个项目很容易，但它可能（或可能不会）巩固这些收益，这意味着未来的结果会更高，
为防止这些错误，我建议对项目进行固定投资，直到其影响曲线至少出现一次拐点。例如，让这两名工程师继续致力于构建性能，直到您看到他们的影响向下移动，然后才估计正确的长期投资水平。如果这感觉太慢，请花一些时间设计项目以更早地显示拐点。
就路线图达成一致
我在许多领域找到了我坚信的最终解决方案。路线图不是其中之一。您可以使用四列电子表格（例如项目、机会、实施成本和拥有团队）来实现这一点。有无数其他方法可以创建同样有效的路线图，很少有格式会导致路线图失败。我建议使用任何已经提出的建议，而不是花时间争论格式。
相反，路线图失败是因为
- 将路线图与预算或功能组合分配的变化相结合
- 产品、工程及其利益相关者之间的紧张关系
- 路线图混合具体和未确定范围的项目
- 通过过于深入的计划削弱团队的能力
我们已经花时间解决了耦合问题，所以让我们深入研究一下其他问题。
脱节的计划者
有效的路线图需要产品、工程和设计协同工作。虽然一个职能部门通常主导规划，但其他两个职能部门应该是积极的合作伙伴。如果不是这种情况，您将生成一个看似合理但无法说明计划工作的实际基础地形的路线图。
同样，我经常看到产品、工程和设计彼此紧密结合的路线图，但提议的工作没有考虑利益相关者的请求（通常来自销售或市场营销）。在这些情况下，将形成一个范围适当的路线图，但它通常不会是一组能够以最佳方式解决公司挑战的工作。
您可以通过与其他职能部门的人员核实，看看他们是否普遍同意提议的计划，从而快速确定是否正在发生这种情况。如果没有，请将不同的职能规划人员拉到一个房间里，然后进行讨论。我在这里看到的常见错误是高管们试图通过一系列一对一的讨论来解决这个问题。一对一调试情况效果很好，但解决它需要公开的小组讨论。我在结构化的小组讨论中取得了特别好的成功，在小组开始讨论之前，每个人都有一到两分钟的时间来分享他们的观点，不受打扰。
路线图未界定的工作
在 Kellan Elliot-McCrea 关于如何计划？ ，他做了一个重要的观察，即规划过程经常主动邀请新想法，
Planning 的隐含或明确要求通常是，“告诉我们你所有令人兴奋的新想法。我们需要您的创造力来实现我们的目标。摇摆围栏！扔大石头！”这是个错误。
挑战在于新想法是未确定范围和未经证实的，您最终会将未确定范围的想法的原始潜力与现有想法的已证明潜力进行比较。你如何看待未经证实的想法通常反映了你的执行团队的心理，而不是它的实际潜力，这让计划变得反复无常。这也意味着，如果新想法很快被证明是错误的，那么您的规划过程将产生短暂的计划。
避免这种情况的两种有效技术是：
- 就范围内和非范围内的计划之间的分配达成一致，然后在这些分配中对同类进行优先排序。例如，您可能会说 20% 的产品工程时间应该用于验证新项目。然后你可以讨论哪些未经验证的项目应该配备那 20% 的人员，然后单独讨论将 80% 的时间投入到经过验证的项目中
- 对验证项目进行长期分配，比如 10% 的产品工程时间，这提供了足够的验证，您可以根据现有项目合理地优先考虑这些项目
即使您不能正式采用这两种方法中的任何一种，您通常也可以非正式地将讨论引向分别讨论范围内和非范围内的项目。
路线图过于详细
我要指出的最后一个路线图挑战是，如果你过于具体，你可能会意外地剥夺负责实际工作的团队的权力。 Melissa Perri 在Escaping the Build Trap中雄辩地抓住了这个想法，它描述了路线图如何过于狭隘地关注项目而不是你想要的结果会限制团队的思考。
有时，新领导者会把这种担忧看得太字面意思，并争辩说不应允许高管讨论具体项目，因为这剥夺了他们团队的自主权。这对每个人来说都是一个糟糕的结果，因为它将执行团队变成了一个纯粹的资源分配决策者，在业务变得异常庞大之前，这是一种过于抽象的经营方式。 （就像团队讨厌进行微观管理的执行团队一样，他们会更讨厌只进行资源分配的执行人员。）
相反，目标应该是首先以高置信度强调目标结果，然后以较低置信度讨论具体项目。只要他们与目标结果保持一致，团队就应该感到有能力改变项目，但深入研究具体项目将会浮现出比任何关于目标的抽象讨论更丰富的关于执行的讨论。
规划流程的时间表
将上述计划过程映射到日历通常如下所示：
- 年度预算应在上一年年底编制
- 功能规划应在全年滚动进行
- 季度计划应该在每个季度之前的几周内进行。如果你打半场而不是四节，你会在每半场之前的几周做准备
这种典型的实现如下图所示。
这里的具体细节因公司而异，而且我还没有发现这些细节有多大关系。 The biggest thing I recommend remaining vigilant against is something that Claire Hughes Johnson would often remark about when we began planning at Stripe: planning efforts always expand to fill the allocated time. If you set aside one week for planning, it will take one week. If you schedule one month for planning, it will take one month. Because planning is an infinite game, it’s best to avoid spending too much time on any given finite step.
Running a shadow planning process
At some point in time, you may find yourself in a planning process run by someone who is unwilling to independently solve for the budget, functional priorities and roadmaps. Similarly, you may find yourself working with a planning process that insists on solving every company problem, despite the fact that it’s clear that it’s solving all those problems poorly.
As an executive, you should work with the owner to improve the planning process, but you may also need to run a shadow planning process within your function. This is straightforward to do for both the budget and the functional resource allocation. For example, you can usually establish a conservative annual headcount plan for Engineering and run Engineering towards that headcount plan, even if other functions jockey for more headcount over the course of the year.
On the other hand, it’s pretty well impossible to run a shadow roadmapping process, even if the roadmapping process is difficult to work with. I’ve never seen a shadow roadmapping process work well except in the case of teams with exclusively Engineering customers such as Platform Engineering, Developer Productivity, or Infrastructure Engineering.
Ways that planning processes fail
Even talented executive teams often run planning processes that go awry. The causes are a mix of incompatible goals, subtle defections from team goals to individual goals, and a long list of small, tactical errors with outsized consequences. To help you in diagnosing your planning challenges, I’ve pulled together the most frequent planning challenges I’ve encountered as well as the symptoms that you can use to identify which challenge is impacting your planning process.
Planning as ticking checkboxes
Signs that you’ve delegated planning to someone who is process oriented rather than outcome oriented, or someone who is unable to push back on others demanding process oriented changes:
- Planning is a ritual rather than part of doing work : teams put together dozens of planning artifacts to support the planning process, and the executives celebrate the depth of work necessary. After planning ends, the plans are rarely if ever referenced again until the next planning cycle begins. This incentives individuals to focus on optically valuable work rather than genuinely valuable work.
- Planning is focused on format rather than quality : executives feel obligated to provide input on plans, to show that they value the planning process. If they don’t have valuable feedback, they will still find feedback, often related to correctly following the planning documents’ format or planning process. This distracts from assessing the quality of the planning decisions themselves
An effective planning process must have an empowered executive sponsor who can keep it focused on its core goals, as well as a planning implementor who is at least as passionate about generating useful plans as running a clear process.
Planning as inefficient resource allocator
Signs that your executive team is optimizing for their function rather than working together to optimize for the company’s overall outcomes:
- Planning creates a budget then ignores it : many executive teams will establish a resource allocation across functions in their budgeting process, but will then make headcount requests that violate that allocation. This leads to requests that are assessed by secondary factors, often individual’s interests or demands, rather than by their alignment with company goals
- Planning rewards least efficient organizations : often leaders will sandbag their organization’s capabilities, arguing that they need significantly more headcount to even continue operating at their current level. This culminates in a business where most resources are directed towards your least efficient leaders and organizations.
A variant of this pattern is one where executives imply they can’t be accountable for their function’s output unless their full headcount request is met. This, combined with consistently high headcount requests, results in a toxic cycle of executives missing their obligations and claiming they can’t be held accountable
- Planning treats headcount as a universal cure : in headcount oriented executive teams, it’s easy for planning to become focused on rationalizing headcount requests rather than deciding on the most important work to be done. It’s clear this is happening when prioritization and planning discussions assume velocity is fixed and that work must happen, and instead anchor on headcount. This penalizes creative leaders who understand how their function works whose knowledge of how the function operations makes them appear less strategic than headcount oriented peers
An executive team can create social pressure on its members to optimize for the greater good, but ultimately only the CEO can hold executives accountable for their behavior. It is valuable to politely raise these issues, but only the CEO can address them. Pushing hard to resolve them will only backfire .
Planning as rewarding shiny projects
Signs that your planning process is more focused on energizing your executive team than solving the inherent resource allocation and functional alignment problem at hand:
- **Planning is anchored on work the executive team finds most interesting: **certain projects will always be more energizing for any given executive team to discuss. For example, most executive teams are excited to discuss sales numbers or new product development, but fewer are thrilled to discuss compliance. If planning processes are driven by work that executives find fun, then they will frequently lead to poor planning outcomes
- Planning only accounts for cross-functional requests: many planning processes are focused on meeting cross-functional commitments rather than planning the entirety of work to be done. It’s reasonable for roadmapping to only deeply consider cross-functional requests, but it’s essential that the functional allocation is being planned as well, such that the executive team is able to discuss critical work that happens to be considered a single function’s responsibility (eg some companies view customer satisfaction, security, compliance, and stability as the responsibility of a single function)
Creating impactful planning outcomes depends on solving the business and functional problems at hand. Energizing your executive team is important, but distracting planning towards this goal comes with an unreasonably high cost.
Planning as diminishing ownership
Signs that your executive team is approaching planning in a way that is reducing autonomy and ownership within your broader team:
- Planning is narrowly focused on project prioritization : an effective planning process serves as guidance for teams within the company to accomplish their work. Executive teams sometimes focus too narrowly on prioritizing specific projects rather than on the necessary outcomes or areas of investment. This often results in the teams with the most context, those implementing the project themselves, being unable to tune their approach to be more effective. This leads to disengaged teams and executives who are frustrated by the lack of urgency in the company’s execution
- Planning generates new projects: in some planning processes, it’s the only time that some executives think about a given area. For example, your Chief Finance Officer may not spend much time thinking about the Customer Success organization’s roadmap outside of planning. This is not inherently a problem, but sometimes those distant executives will use planning as an opportunity to suggest significant new, unscoped work. This will almost always result in a delayed or failed planning process, as it leads to attempting to prioritize well-scoped work against unscoped work, which is very challenging
Executives should prioritize coaching the broader team through planning. At times you will identify a leader who is not able to plan in their area, and at times you may need to make top-down changes to the plan, but these should not be exceptions rather than the routine.
Summary
Working through this post, you’ve dealt with the executive team’s annual budgeting process, maintaining Engineering’s target functional allocation, and combining the two to establish a concrete roadmap. You’ve also worked through a number of smaller topics like whether Engineering growth should be the limiter on your company’s overall growth, considering the granularity within your functional allocation, and the tradeoffs of running a shadow planning process.
As you take these ideas into your next planning process, my biggest hope is that you remember the first section: planning is an infinite game, and there’s always a bit of mess at every stage. The key thing is to continue improving bit by bit!