Design an Adaptive Team-based organisation
Original article by Ran Nyman for Society for Adaptive Organisations.
Background
In Agile, the main design principle is to use teams as fundamental building blocks of an organisation. Recommended teams are cross-functional feature teams that are extensively covered “here”. Team composition deals with the lowest level of organisation but leaves the rest open.
This post will open up a few alternative ways of creating multidimensional organisations. It will not cover matrix organisation 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 organisational design. When designing an organisation, 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 organisation 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 organisation. 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 organisational design. An organisational 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 organisational 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 organisational structure where the market units can drive product development efforts toward market and customer needs.
Using the following organisational 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 organisation design and remove the specific product focus from the development side. The organisational chart of this kind of organisation is below.
In this setup, teams can freely be assigned to work with different products so the organisation 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 organisations that need long-term product focus from the Product Owner side and a significant amount of adaptability, moving towards a more modular organisation and introducing product dimension organisation could be more beneficial.
Modular organisation with Product Dimension
In a modular organisation, the organisation is formed from three different types of units. Market units (blue) focus on selling products and bringing customer insight towards the organisation, output units (green) create sellable products, and input units (yellow) build people and resources for the organisation to operate. In a pure modular organisation, the Product Owner and Area Product Owner would be located in the Development organisation. 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 organisation that focuses now solely on improving the capabilities of the development organisation and does not anymore focus on developing and launching products. That responsibility is moved to the Product organisation.
Now new products can be launched just by having a PO who starts working towards product vision and gets teams from the development organisation. 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 organisation to help other POs
Modular organisation
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 organisational structures. Unfortunately, it leaves out many practical details to keep it readable in one go. Of course, when engaging in actual organisational 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 organisation.
Some references and further reading on topics covered in this blog post: 1999, Re-Creating the Corporation: a design of organisations for the 21st century. Oxford Univ. Press: New York, R. Acoff 2018, organisation Design: Simplifying complex systems 2nd Edition. Routledge, Nicolay Worren
About the Society
The Society for Adaptive Organisations e.V. is a coalition of leading European organisational developers, coaches, and trainers, working to create unified quality standards for education and training in organisational development and supporting companies in uncertain markets. The goal is to help organisations achieve greater customer focus, effectiveness, and resilience.