Seeing system dynamics in organizational change: 7) incremental structural change
This is the seventh article in the series of seeing system dynamics in organizational change. In the last article, we concluded that incremental structural change was more appropriate for huge organizations. In this article, we shall look at the different approaches for incremental structural change.
Two approaches
There are mainly two different approaches for incremental structural change. For the ease of explaining, I shall refer to the LeSS terms, but the thinking behind goes beyond LeSS and applies to the incremental structural change in general.
The above diagram illustrates these two approaches for a typical telecom product. The product consists of 3 main subsystems - O&M (Operations & Maintenance), CP (Control Plane) and UP (User Plane). In each subsystem, there are several components. Before we start the change, all teams are organized around components and functions. The change vision is that all teams will be cross-functional and cross-component, i.e. all are feature teams. How are we going to make incremental structural change?
- Gradual expanding
This is the approach used with LeSS guide: feature team adoption map. We first expand the scope of component team and move it closer to feature team. For each subsystem, we make structural change to create "feature" teams inside subsystem. The expansion happens in parallel in all subsystems.
- Cutting through
This is the approach used with LeSS guide: one requirement area at a time. We cut through all subsystems and create the first requirement area, with a few real feature teams. In the meantime, the major part of the organization remains with the old structure.
There are similarities and differences between these two approaches.
What's the same
Both are incremental structural change. Thus, both are only the first step towards the change vision. As described in the last article of "the scope of structural change", we limit the change scope to decrease the complexity, but it extends the change period, which increases the complexity. Therefore, it is a balance.
There are a couple of challenges for incremental structural change.
- The initial success is critical, as there involves a reinforcing loop.
R1-loop: Result speaks
Better result, more commitment, more investment, leading to even better result. Note that it works in other direction too. Worse result, less commitment, less investment, leading to even worse result.
This is probably the most fundamental dynamic for any change. We must have the initial success and let the result speak. This applies to both approaches.
2. The change may stall after the initial success, as described in the article of "from change resistance to limits to growth". In order to grow the change, we have to set the next goal immediately after the initial success, until the change vision about organizational structure is fully achieved.
What's different
In order to have the initial success, these two approaches make different trade-offs, as summarized in the below table.
Let's elaborate in more details.
- Organization
We would only have real feature teams with the second approach. The change there is more disruptive, as it cuts through the whole organization. However, it does not affect everybody immediately, instead, the initial change is based on volunteering.
The second approach also leads to parallel organizations, in which one requirement area works in the new mode, while the rest of the organization remains in the old mode. This increases the complexity for change management.
- Customer value
Individual teams in the second approach would deliver real customer value in every sprint, while inside-subsystem "feature" teams still need to coordinate and integrate their work together for customer value delivery. In essence, inside-subsystem "feature" teams are still component teams, thus, they suffer from the same problems as component team, but to a lesser extent.
- Learning
Learning from a component to a subsystem is more gradual in the first approach, while broad learning is usually required immediately in the second approach. The broad learning could mean a big challenge if team members have narrowly focused on small components in the past.
In summary, both approaches are incremental, thus share the same basic reasoning and dynamic. However, they make different trade-offs for the initial success, thus take different first step.
