Programs: tips for owning the unownable.

Good organizational design minimizes 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 like reliability, security, efficiency, and so on.

These goals don’t map well because they are properties that require active investment across every facet of 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 every team of six engineers have someone with domain expertise on security and cloud costs and performance and API design and so the list winds onward into oblivion? Probably not.

As I’ve become responsible for more goals that don’t fit into the scope of a single team, I’ve become increasingly enamored with using programs to accomplish those goals.

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.

While I’m still actively learning how to make programs successful, I’ve written up what I’ve learned thus far.

As is often the case, 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 at Stripe.

When to use

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 all of those things, you probably shouldn’t use a program.

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.

Designing the program

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.

When you decide to launch a program, the first step is to assemble the program team. The folks your soon-to-be-successful program needs are:

• Program designer / systems thinker 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 who can steer policy decisions, influence and educate other teams, and lean on their past experience to skip past the first series of missteps (moving on to novel, original missteps as quickly as possible).
• System and tool builders who will partner with the other members of the program to create the automation and feedback loops to make the program successful with a fixed amount of time spent coordinating humans (avoiding linear growth of time spent supporting a program as the organization it supports continues to grow).
• Executive sponsor who will ensure the program gets the resources it requires to succeed, and also serve as the escalation point when the program’s projects need to get prioritized.

Once you’ve gathered your team, your next step is to do initial discovery for the programs. The goal is to understand the problem clearly enough to start designing a program to solve it, and to determine the limits of the organization’s desire to address the problem. Some approaches to guide that learning are:

• 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.
• Learn from your executive sponsor. 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.
• Learn from industry peers. 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. Not every program is going to have relevant literature, but there are a surprisingly large number of relevant books out there, many of them hiding in the DevOps category. Ask around for suggestions!

Finally, with both the team and the context, you can start designing your program. The tools, systems and structures you need to create are:

• Program data is the underpinning of successful programs, and a prerequisite for most of the other tools and systems you need to create. Having accurate, defensible data to ground your program on is the first thing to focus on building. Until you’ve built that data — and the program team has become deeply familiar with it — none of these other approaches will be particularly effective.
• 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. Each team you partner with should have its own contribution towards the overall program goal, and should have a sub-goal that holds them accountable to that contribution. These sub-goals should be proposed by the program and then refined together with the partner team into something everyone feels comfortable committing towards.
• 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 attention, as well as which areas teams should focus on to meet their targets.
• Nudges that push updates to teams who are falling behind on their sub-goals. It’s impractical to assume folks will poll dashboards 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 status review. 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.
• Program retrospective. You need a forum for the program team to learn about and evolve the program together, perhaps once or twice a year. These meetings should take a broader view than the operating meeting, rebuilding your strategy based on your organization’s evolving context.

Combine these three bits together, and congratulations you have the beginnings of an organizational program that can take on the sort of broad goals that so far you’ve been trying to lead in the spare minutes between meetings.

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.
• Build for beginners. 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.
• Each domain has a different cadence. An incident program is a good example of a domain with a very short cadence, needing to drive from incident to remediation to understanding in hours or days. On the other hand, a program responsible for consistent API design would generally have a longer cadence, taking days or weeks to consider the long-lasting implications of evolving your API specification. A program managing your spend on cloud infrastructure (meaning AWS, GCP, etc) might operate over months and quarters, since money is spent slowly over time.
  
  Your program design needs to factor that cadence into your reporting and review mechanisms, ensuring they’re appropriate to the underlying domain you’re working in.
• Stay aligned with your sponsor’s goals. 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.
• Iterate quickly to reduce friction. Even the best programs create friction for the teams they work with, because they want teams to prioritize projects when the teams themselves often have conflicting priorities. The secret to success isn’t creating no friction, but rather responding very quickly to friction as partner teams flag concerns.

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?

There is no “one true program design”, and I’ve found each sort of program I’ve worked on has ended up being quite different in its details. Take these ideas as a framework to tweak and occasionally defy.

If you’re looking for more reading about program design, some of the lightly related books I’ve enjoyed are The Deadline by DeMarco, Peopleware by DeMarco and Lister, and The Phoenix Project by Kim, Spafford and Behr. It’s true that these are not truly about program management, 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.