How to manage a program in a product-mode organization

Invest time at the beginning to set the program up for success

The beginning of the program provides a natural pause point in which to run focused workshops that set the teams and the program up for success. By the end of the program kickoff, business stakeholders and team members should be aware of the initiative and its significance, their role in it, how it’ll be delivered and the high-level scope of the first release. Investing time upfront in a project kickoff like this is proper risk mitigation for a multi-month missed delivery date. We advise setting aside time to run a set of workshops that provide the following outcomes:

• align all stakeholders on what needs to be done and why (including any changes to the current operating model);
• define consistent ways of working, ceremonies and best practices;
• socialize the business, technical and customer context with all teams involved;
• build trust across the teams by making explicit the roles, responsibilities and motivations of individuals;
• lay a foundation for building empathy and understanding within the team;
• shine a light on the risks, dependencies, assumptions and complexity that exists in the delivery.

An example schedule for a kickoff intending to address these outcomes might look like this:

Choose a leadership style that’s appropriate for the program

Depending on the organization, the current culture in the product division may not be receptive to the urgency and level of process standardization that the delivery of a program requires. Therefore, program leaders, acting like solution-champions, may find that they need to adapt their leadership style to the demands of the initiative.

As an example, the situational leadership model provides a useful description of some common communication styles in various states of leadership (see sidebar). In the ideal state, leaders of self-organizing product teams will be involving and empowering their teams. However, as the program may require a change in operating model that challenges the self-organizing nature of the product teams involved, leaders may need to adapt their style and spend more time clarifying and defining than they’re used to.

In addition to changing their communication style, program leaders will need to keep teams accountable for those changes required to support the new operating model. A commonly used tool to communicate responsibility and accountability is a responsibility assignment matrix (see RACI matrix sidebar). Something like this can be used to help team members understand what’s expected from them with regards to upholding process standards and attending critical program meetings.

Manage dependencies and risks diligently

Dependencies between teams (known as backlog coupling) are common in program delivery as multiple teams will be responsible for delivering different discrete parts of the solution. A good practice for proactively managing these dependencies is to frontload the program delivery with activities intended to decouple individual team backlogs, with a view to enabling teams to deliver more autonomously.

For example, in order to reduce the backlog coupling between the product teams in our example, the program team might decide to spend its first few iterations swarming around building a walking-skeleton (see Figure 7 below). Assuming a mature continuous delivery setup, the walking-skeleton can be deployed to production behind feature flags, enabling future program progress updates to focus on the evolution of the walking-skeleton as more fidelity and depth of scope is added by the product teams. Below is an example of a release plan that shows where the walking skeleton swarm team fits into the product roadmap.

In our example above, the walking-skeleton would have consisted of the entire MVP user journey but with little time invested in the fidelity of the user interface. Moreover, all API integrations would be stubbed with any data mocked and hard-coded. The intention isn’t for the walking-skeleton to be used by a customer, but for the work that couples the product teams to each other to be mostly resolved before the teams proceed with delivery of their own backlogs. Moreover, once the walking-skeleton is built it allows all teams to continuously integrate their code mitigating the risk of late integration.

There’ll be many other risks to the delivery of the program, so therefore actively managing risks as part of the normal iteration cycle is imperative to success. Active risk management isn’t always a part of the standard product delivery cycle (as evidenced in the example above) so some discipline may be required on the part of the leadership team to keep the momentum going throughout delivery.

Develop a strong communication strategy

A large part of the coordination effort in program management is spent on communication in order to:

• make sure all relevant stakeholders are kept informed and given the chance to raise issues and ask questions;
• facilitate the communication across teams to help relieve bottlenecks in delivery;
• surface blockers to the program leadership team so that they can help alleviate them.

Due to this required overhead of communication in programs, program leadership should look to create a strong communication strategy with touch points that satisfy the needs of each stakeholder group. An example communication strategy might look something like this:

Invest in visual artifacts that aid in information radiation

Visual artifacts such as a physical program wall (see Figure 9 below) can be used as a great information radiator for the program not only to the benefit of key stakeholders, but also for the entire company.

A program wall can be seen as an isolated initiative in the beginning, but also new organizational habits and disciplines can be created by keeping it up to date and forcing conversations to happen around it. An interesting additional side benefit of physical walls is that they can promote collaboration and accountability among the teams. Moreover, program walls can help prompt questions from other people in the company by allowing them to consume information quickly without needing to schedule time with anyone.

An ideal program wall contains just enough information to provide a status update at a glance. From the example above we can tell that the swarm team has completed its work and disbanded, and that the delivery teams are now working through their deliverables with one of the teams in need of some assistance to remove a future blocker.

Don’t be afraid of having a defined role for managing the program

We believe that the discipline of program management is crucial to ensuring success when any initiative involves the orchestration and coordination of multiple teams to deliver value. However, the actual role definition and responsibilities will depend on the organizational context and program complexity and therefore we prefer to call this role “solution champion” as opposed to program manager. Fundamentally though, there needs to be someone who is responsible for the overall health of the initiative focusing their efforts on the following strategic elements:

• continually ensuring alignment between teams;
• ensuring that communication flows smoothly between the teams and external stakeholders;
• keeping relevant and critical information fresh;
• managing program dependencies and risks.

It’s important to make sure the responsibilities of the role are made explicit to everyone involved, preferably at the program kickoff. A risk we have observed when introducing solution champions at product-mode organizations is that product team members and the solution champion can end up with overlapping responsibilities, making both roles less effective. As mentioned, solution champions should be focused on the strategic aspects of the program and not on the tactical product delivery tasks of the teams involved. The following RACI matrix shows the separation of responsibilities between roles:

Note the separation of accountability between the solution champion and the product delivery leadership and team.