计划：拥有无法致命的提示。

好的organizational designminimizes the cross-team coordination required to achieve team goals. Teams that move with little coordination finish projects while the others are still ratifying their implementation proposal.

However, complex organizations can’t enclose every company goal in a reassuringly simple box. These goals that don’t map easily include some of the most interesting goals that companies have. Things likereliability, security, efficiency， 等等。

These goals don’t map well because they are特性that require active investment across every facet across the organization, but they’re also difficult to wholly decentralize because they have economies of scale and domain specific context that disincentivize uniformly disseminating responsibility across every team. Can每一个team of six engineers have someone with domain expertise on security和云成本和表现和API设计和所以所以列出了向外的风？可能不是。

由于我对更多的目标负责，这不适合单一团队的范围，我越来越疯狂使用programs完成这些目标。

Programs are initiatives led by a dedicated team with the goal of maintaining a property across an organization. Some examples of programs I’ve encountered are incident programs, various flavors of architecture reviews, maintaining infrastructure efficiency, UX consistency work, etc.

Programs are fascinating, because they’re like projects but for properties rather than tasks, and maintaining a property requires continual, ongoing investment. Because they’re never ending, they are an amazing cauldron for experimentation, and because they’re supporting critical goals, they typically get staffed to success. Combined, they’re a unique opportunity for an organization to learn and improve quickly.

虽然我仍然积极学习如何使程序成功，但我已经写了我所学到的。

---

这是常有的事,there are more folks who deserve credit for these ideas and practices than fit on any finite list, but particular thanks to my coworkers Cecily, Charles, Grace, Davin, Drew, Erin, Roberto, Smruti and Taleena atStripe。

何时使用

Running a successful program is far harder than running a successful team. This means that programs are a bad default tactic, rather their relatively high fixed costs make them a tool for deliberate use only.

A successful program requires systems thinkers with experience in process design, folks with significant domain expertise, oh, and don’t forget the ability to keep executive sponsors engaged in areas they might not be natively engaged with while also accomplishing much of your work through influence without authority. If you don’t have全部其中，你可能不应该使用程序。

Conversely, if you need to make progress on something that requires broad, consistent application across numerous teams and projects, then programs are one of the few tools that truly work. Properly resourced and designed, I’ve seen programs move and retain mountains that no other approach can rival.

设计程序

Assuming a program is the right solution for the problem at hand, let’s walk through the steps to launch it from concept to functional program: (1) assemble the team, (2) do initial discovery, and then (3) design the process.

当您决定启动程序时，第一步是组装程序团队。人们即将成功的计划需求是：

• 程序设计师/系统思想家who has experience leading at scale with influence, knows how to leverage sponsors, knows how to engage partner teams, and can do all of these things in the most economical way for both the program team and the organization the program is guiding.
• Subject-matter expert谁可以控制政策决策，影响和教育其他团队，并依靠过去的经验来跳过第一个系列的错误（尽可能快地前进到新颖的原始缺陷）。
• 系统和工具制造商谁将与该计划的其他成员合作以创建自动化和反馈循环，以使程序成功使用固定的时间坐标人类（避免支撑程序作为其支持的组织所花费的时间线性增长）。
• Executive sponsor世卫组织将确保程序获取资源吗requires to succeed, and also serve as the escalation point when the programs projects need to get prioritized.

一旦您收集了您的团队，您的下一步就是为程序做初始发现。目标是清楚地了解问题，以开始设计一个程序来解决它，并确定组织解决问题的愿望的限制。指导学习的一些方法是：

• **Learn from your partner teams. **The partner teams across that organization will supply the majority of the hands to accomplish your program’s goals, and you need to understand their needs and priorities before they’re going to be interested in understanding yours. Build these relationships early and you’ll get ongoing feedback about how to reduce their friction and make the program work.
• 从你的执行赞助商学习。Programs that don’t leverage their executive sponsors well don’t succeed. Similarly, programs that lean too heavily on their sponsors typically don’t do super well either, becoming bottlenecked on their sponsor’s scarce time. Take the time upfront to agree on boundaries, escalation mechanisms and what not.
• 向行业同行学习。Most companies “at scale” will have a program similar to the one that you’re running. Meet with as many of those folks as you can and learn from their successes and failures.
• Learn from literature.并非每个计划都会有相关的文学，但有一个令人惊讶的大量相关书籍，其中许多人隐藏在Devops类别中。问周围的建议！

最后，通过团队和上下文，您可以开始设计您的程序。您需要创建的工具，系统和结构是：

• 程序数据是成功计划的支撑，以及您需要创建的大多数其他工具和系统的先决条件。准确，可辩护的数据造成您的程序，是首先专注于建筑物的信息。在您构建数据之前 - 并且程序团队对其深感熟悉 - 这些其他方法都不是特别有效的。
• **Program goals. **Your program needs to have clear top-level goals that are used to track whether the program’s approach is succeeding. These should be both top-level goals that tie tightly to your users’ and business needs, as well as intermediary goals that help you understand the health of the program’s approach.
• Sub-goals for partner teams.您与您合作的每个团队都应该对整个方案目标有自己的贡献，并且应该有一个子目标，使他们负责对该贡献负责。这些子目标应由该计划提出，然后与合作伙伴团队合作进入每个人都感受到舒适的致力。
• **Dashboards **that show program progress against goals and allow each team to dig into and understand their progress against their sub-goals. The best versions of these provide clear recommendations on where the program team should focus their attendion, as well as which areas teams should focus on to meet their targets.
• Nudgesthat push updates to teams who are falling behind on their sub-goals. It’s impractical to assume folks will poll dashboard to learn they’re falling behind, so instead you need to bring that context to them. Conversely, you should never send a nudge to someone who doesn’t need to take action, which will cause them to tune out all further nudges.
• Program status review.You’ll need a recurring forum to hold yourself accountable to your own goals (I’d recommend a quarterly review). It’s essential that your sponsor is a participant in these meetings, providing a mechanism for ongoing alignment as priorities change.
• Partner-team状态评估。You’ll need another set of forums to ensure that each partner team is holding itself accountable to their goals. This is likely adding the sub-goals into an existing review forum for the partner teams, not creating a brand new forum. For example, this might be specifying an additional OKR for each partner team to review during their OKR reviews. It’s usually impractical to attend all of these, but it’s quite useful to attend those where the team is struggling to meet its program sub-goals, you’ll learn a lot about the challenges they’re up against and how you can adapt the program to work with them where they are.
• **Team operating meeting. **Your program will learn so, so much as it operates, and you need a place to make the numerous ongoing tweaks that are the lifeblood of successful, effective, efficient programs. The program team should be meeting at least every other week for an hour.
• 程序回顾。您需要一个计划团队的论坛，以了解并在一起将该计划延伸一次，也许是一年一次或两次。这些会议应比营业会议更广泛的观点，根据组织的不断发展的背景重建您的策略。

将这三个比特组合在一起，祝贺您的组织计划的开始，可以承担到目前为止，您一直在会议之间的备用时间内致力于领导的广泛目标。

Making them effective

Beyond the above steps for designing and launching a new program, a few more comments and tips for how to make your program work:

• Manual work is a prototype, not a solution.The best way to make programs fail is to adopt manual processes as long-term solutions. Manual work is boring, error prone and misinvests your energy into execution instead of evolution. It’s extremely important to do the first version of most program work manually to understand where the rough edges are and fix them before doing a broad rollout, but you should never rely on manual work to perform the broad rollout. Automate instead, even if that means ramping more slowly, because the automation is going to get you much further in the medium and long-term.
• 为初学者构建。Program leaders must focus their approach and tools on supporting beginners, not on supporting experts. This can be difficult because part of ramping up to lead a program is becoming an expert in its domain. When working with many teams, most of those teams will focus on your program’s area so infrequently that they’ve forgotten whatever they learned last time before they think about it again. Build your tools and guidelines with the assumption that your users have never used them before and will never use them again.
• Be explicit about team roles.Each program team will have a different set of folks with different strengths and interests, which means each program will have slightly different roles. The important thing is to have the team sit down together and clarify their roles and responsibilities.
• 每个域都有不同的节奏。事件程序是一个具有非常短的节奏的域的一个很好的例子，需要从事件中推动以在几小时或几天内进行修复。另一方面，负责一致API设计的程序通常具有较长的节奏，需要几天或几周，以考虑不断发展API规范的持久影响。管理您在云基础设施上的花费（意思是AWS，GCP等）的程序可能会在几个月和季度运行，因为金钱随着时间的推移慢慢地花了。
  
  您的程序设计需要将该级别的节奏分解为您的报告和审查机制，确保它们适合您所在的底层域。
• 与您的赞助商的目标保持一致。Some programs find themselves struggling as they push their goals further than their sponsor is willing to support, and burn out themselves and their relationships with partner teams. Every program is competing for resources with many parallel initiatives, and being aligned with your sponsor on how to encourage folks to make trade offs is essential to succeed. If you’re consistently aligned with your sponsor, then folks won’t escalate, because they know it’ll not change the direction, and your life will get much easier.
• 迅速迭代以减少摩擦。即使是最好的计划也为他们合作的团队创造了摩擦，因为他们希望当球队本身往往具有相互矛盾的优先事项时，他们希望团队优先考虑项目。成功的秘诀并没有创造没有摩擦，而是非常迅速地努力摩擦为合作伙伴团队旗帜问题。

This isn’t the complete list of things you should be thinking about to make your program effective, but it’s a good start! Drop me a note if you have suggestions for more and I’ll add them in.

What’s next?

没有“一个真正的节目设计”，我发现了每种程序我的工作已经结束了它的细节。把这些想法作为调整和偶尔蔑视的框架。

If you’re looking for more reading about program design, some of the lightly related books I’ve enjoyed are最后期限由Demarco，人士by DeMarco and Lister, andThe Phoenix Projectby Kim, Spafford and Behr. It’s true that these are not truly aboutprogrammanagement, but I think the thinking in each of these books translates quite directly. What is a program, anyway, if not a project whose goal simply refuses to stay fixed.