Design an Adaptive Team-based Organization

Background

In Agile, the main design principle is to use teams as fundamental building blocks of an organization. Recommended teams are cross-functional feature teams that are extensively covered here. Team composition deals with the lowest level of organization but leaves the rest open.

This post will open up a few alternative ways of creating multidimensional organizations. It will not cover matrix organization which is quite well known but not well defined (read more here), and its problems are well-analyzed, e.g. here.

Instead, this post will go through two other multidimensional models front-back and modular organizational design. When designing an organization, three views need to be handled the alignment of goals of each unit, the process interdependencies, and the coordination of work. This post focuses on aligning goals, and the next post deals with interdependencies. Luckily coordination of work is covered, e.g., in LeSS, which gives good advice on managing the coordination of work by using many different collaboration and coordination techniques; you can read more about them here.

Front-Back Model

A way of creating a multidimensional organization is using a front-back model. Typical front units are market and sales-focused, and back units are product-development-focused. One of the advantages of the front-back model is that there is no need for dual reporting, which is one of the main problems of traditional matrix organization. An example of the front-back model is in a hierarchy chart below, with one front unit focused on sales and marketing and two product units concentrating on building products.

Looking only at the hierarchy chart does not reveal the coupling (goal conflicts) of organizational design. An organizational design analysis using a Design Matrix visualizes the coupling between units. The front-back model Design Matrix is below. Unit goals are in the leftmost column, and the second row shows organizational units. X in the matrix marks which unit is mainly responsible. A small x indicates coupling (goal conflict) between units. And we can see that the only unit that has coupling between other units is the support unit, which is done to avoid duplication of support in each unit separately. (Moving support can be done if the coupling between the support unit hinders other units' performance.)

The table shows that units pursuing their goals do not jeopardize other units' goals. However, this does not mean that would not be process interdependencies between units. For example, the marketing unit depends on products units do deliver products that they market. This easily leads to product units pushing products to market without a clear view of customers' needs. One way to solve this is to create an organizational structure where the market units can drive product development efforts toward market and customer needs.

Using the following organizational structure, we can mitigate the pushing from development units by having Product Owners from front units collaborate with the development unit teams. (You can read more about Product Owner role here and Area Product Owner here.)

The front unit (blue) sells and markets both products and can deliver effective solutions by combining them. Front units are responsible for focusing the product units on providing products the market needs. Back units (yellow) are responsible for developing products based on the market/customer insight that Product Owners are bringing and using to prioritize the work toward product units.

This structure is optimized toward a stable product environment where there is no need to move teams between product units or coordinate work across different products. Coordinating work across other units leads to delays and typically requires dedicated coordinators. In addition, the growth of coordination cost tends to rise exponentially leading to coordination chaos.

Front-Back and Modular Model Combination

Reallocating teams will lead to restructuring, which is always time-consuming and leads to moving teams from one manager to another, which impacts relationships between managers and teams. On the front side, Product Owners and Area Product Owners can be much more freely allocated to work with different products. Still, to achieve similar flexibility on the back end side, we need to look for inspiration from modular organization design and remove the specific product focus from the development side. The organizational chart of this kind of organization is below.

In this setup, teams can freely be assigned to work with different products so the organization can focus on high-value work and be adaptable. The coupling table is below.

The risk in this hybrid setup is insufficient focus on building and maintaining products from market/sales unit. However, this is compensated by the development unit, which has a long-term goal of maintaining the product.

In organizations that need long-term product focus from the Product Owner side and a significant amount of adaptability, moving towards a more modular organization and introducing product dimension organization could be more beneficial.

Modular Organization with Product Dimension

In modular organization, the organization is formed from three different types of units. Market units (blue) focus on selling products and bringing customer insight towards the organization, output units (green) create sellable products, and input units (yellow) build people and resources for the organization to operate. In a pure modular organization, the Product Owner and Area Product Owner would be located in the Development organization. Still, in our experience, it will move POs too far away from the business, limiting their decision-making power in driving the development toward real business needs.

In the design matrix, the responsibilities of units are slightly modified to avoid coupling (goal conflicts). However, the main change is to the development organization that focuses now solely on improving the capabilities of the development organization and does not anymore focus on developing and launching products. That responsibility is moved to the Product organization.

Now new products can be launched just by having a PO who starts working towards product vision and gets teams from the development organization. So creating, moving development focus, and killing products is a lightweight operation since it just requires reallocating Teams to different products and returning PO to the product management organization to help other POs.

Modular Organization

In the above setup, there is lots of decision power with the Products EVP, and in case the CEO wants to have more say on which kind of products to focus on, the following structure can give more control to him/her. The coupling matrix would be almost identical only Products units have been split so it’s omitted.

This longish post shows a different way of organizing product development based on multidimensional organizational structures. Unfortunately, it leaves out many practical details to keep it readable in one go. Of course, when engaging in actual organizational design, all the omitted details must be handled. However, focusing on the critical design principles presented in this post will help you create a genuinely adaptable organization.

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