Solving shared assets (SW+HW) development with Floating Platform Teams (FPTe)

Background

In the previous post, we went through high-level organizational design and touched lightly on the sub-unit design. This post focuses on shared asset development problems between subunits and how to solve them. You can find subunits in organizational charts with names like business units, departments, tribes, or product groups.

Design Problem

A common problem in subunit design is that the subunits have coupling (goal conflict), meaning that when the subunit pursues its goals, it harms other subunits to reach their goals. For example, let's assume we have three subunits organized in the following way.

Each BU builds products for different market segments and shares HW and SW parts with each other. Because the BUs develop functionality also used in other BUs, the Design Matrix of BU's will look the following.

Design Matrix shows the coupling between BU's as small "x." The capital "X" indicates the unit's own goal. The coupling is caused since BUs share the same SW+HW platform and some parts of products.

We can visualize this situation by drawing a Venn diagram where we can see the shared parts of products. How much functionality is shared between products determines the size of the overlapping area.

Organizations' common solution when facing this problem is to create a subunit platform and move the development of common parts there (org. char below).

This will solve the coupling, as seen in the following design matrix. (The alternative to introducing a platform subunit is to combine all BUs into one product group, which will remove the coupling between units. However, this option is seldom used due to the enormous scale of needed reorganization and the fear that product teams cannot create reusable platform. If an organization wants this path, the gradual change using the parallel organization concept will make the transformation manageable.)

But solving the coupling using a platform unit creates process interdependencies. There are three types of process interdependencies pooled, sequential or reciprocal. The pooled and sequential interdependencies are one-way only so that they will lead to manageable coordination costs. Reciprocal interdependency is a two-way dependency where the output of subunit-1 becomes the input for subunit-2 and vice versa. Below you can see pictures of these dependencies.

Typical platform development leads to reciprocal interdependencies where, e.g., product A requires functionality to be added to the platform and orders that from the platform subunit. Platform subunit, having many requests, will use its own prioritization scheme, which will make the product unit wait for the functionality. When the functionality is added to the platform, the platform unit informs product A about this. In an optimistic case scenario, this will work, but in most cases, the requested functionality is not functioning as expected, and the functionality in the platform needs to be enhanced further. Coordinating this by planning is expensive and error-prone, leading to suboptimal results. Below is the scenario modeled as an interdependency graph.

The interdependency graph shows how work needs to be coordinated between several teams and across organizational boundaries, where each organization has its own planning focused on planning work with each organization's own teams. This is what makes coordinating work between BUs a complex solution.

When dealing with the platform subunit and reciprocal interdependencies, the advice that recommends containing the reciprocal interdependencies in the same subunit would lead to merging all BUs, which is seldom done, as discussed earlier.

An innovative alternative for merging the BUs and the platform subunit is introducing Floating Platform Teams (FPTe). Floating platform teams can move between product groups so that they work with the product teams for fixed intervals of development when there is a need to coordinate the platform work with BUs teams. The rest of the time, FPTe work in the platform subunits with the platform Product Owner and do tasks requiring long-term development before product teams can use the functionality. The change is reflected in below org chart where some platform teams have floated to work with BU teams.

Using FPTes requires a change in the goals of the platform organization shown in bold in the below Design Matrix. As described in modular organization design in the previous post, the platform unit becomes an input unit.

Floating platform teams will eliminate management of reciprocal dependencies on task level that is costly and error-prone. The coordination problem changes from which team is doing what to which teams need to collaborate and for how long. Therefore, the coordination will become the coordination of team interactions, improving the system's performance as a system's performance is mainly determined by how parts interact, not how well each part functions in isolation. Product Owners do the team allocation following the guidance of the division's product portfolio decisions which tends to be quite stable enabling FPTs to work for longer periods with same product teams. Interdependencies when using FPTe are pictured below, where the teams are moved to plan and work together, sharing the same backlog.

Organizing platform subunit using FPTes make it possible to float the capacity to develop shared functionality effortlessly, enabling the organization to adapt to changing priorities. There are two paths that an organization can take to evolve the FPTe since the concept works best when there is lots of coordination needed between platform and product groups.

The first is to move towards a commodity platform concept where most platform teams move permanently to the product group, and few remain to update the platform, or, in extreme cases, the platform unit is totally removed, and platform assets are developed using internal open source concept.

Second, the platform subunit can be transformed into real BU if the platform becomes sellable to outside customers. Then all FPTe will return to the platform unit permanently, and sales/marketing teams will be added. The only difference between other BUs in the organization is that platform BU has internal and external customers.

In this post, we covered several topics. First, we started by looking at how the coupling between subunits can be solved by introducing a platform unit. Then we showed that the platform subunit would create reciprocal interdependencies between other subunits. Next, we introduced the concept of floating platform teams (FPTe) to solve the interdependencies. Finally, we presented how FPTe can evolve towards a commodity platform or BU. FPTe increases the organization's adaptability and improves the interaction of the subunits, improving the development system's performance when the coordination of work between platform teams and product teams is the main challenge.

Some references and further reading on topics covered in this blog post:
1999, Re-Creating the Corporation: a design of organizations for the 21st century. Oxford Univ. Press: New York, R. Acoff
2018, Organization Design: Simplifying complex systems 2nd Edition. Routledge, Nicolay Worren
2023, Creating Agile Organizations: A systemic approach, Person Education, Cesário Ramos, Ilia Pavlichenko