Blog /

Design an Adaptive Team-based Organization

Organizational Design Leading change Scaling Agile

27.4.2023 — Matrix organization has well-known problems. Combining Back-Front and Modular organization designs gives you options for creating adaptive organization, productive teamwork, and market focus.

Design an Adaptive Team-based Organization
Authors
Ran Nyman
Ran NymanFounding Partner
Ari Tikka
Ari TikkaFounding Partner

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.

image-10.png

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.)

Organizational Units

Goals

Support

Product A

Product B

Sales / Marketing

Provide cost effective support systems

X

Develop. launch and maintain product A

x

X

Develop, launch and maintain product B

x

X

Maximize profit or revenue for products A&B

x

X

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.)

image-7.png

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.

image-2.png

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.

Organizational Units

Goals

Support

Development

Sales / Marketing

Provide cost effective support systems

X

Develop, launch and maintain products

x

X

Maximize profit for products

x

X

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.

image-8.png

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.

Organizational Units

Goals

Support

Development

Products

Sales/Marketing

Provide cost effective support systems

X

Maximize competence utilization

x

X

Provide products that are sold externally

x

X

Market and sell products provided by output units

x

X

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.

image-9.png

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

Ran Nyman
Founding Partner

Ran is an experienced software professional who has worked since 1995 in professional software development field. Currently, Ran is working as a consultant and trainer in process improvement field helping large multinational organizations to move from sequential product development to more agile ways of working. The primary focus has been on how to move big products (over 100 people) to use Large-Scale Scrum (LeSS) and Lean. This work includes giving wide range of trainings, workshops, team coaching and management consulting.

All posts →

Ari Tikka
Founding Partner

Before finding Agile, Ari built software for embedded distributed fault tolerant software for seven years. For the next decade he worked as an organizational therapist with cultural change, teamwork and leadership. Since 2006 he has contributed to LeSS-flavoured Agile transformations including mechanical engineering, market automation, and embedded system development. For the last couple of years Ari had international coaching assignments ranging from teams to board.

All posts →