好的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 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.
- 与您的赞助商的目标保持一致。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.
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.