Tribes, guilds, squads… without any doubt the organization map of an «Agile company» shows some patterns that clearly reveal its nature. However, it has nothing to do with these catchy names from the wrongly called «Spotify’s model». Sadly, this non existing model has become a reference that is copied by almost any organization planning to launch an «Agile transformation».
We come across companies that believe that this organizational model with multiple roles and functions is the key to success of an agile organization. This belief explains why many companies embark on this journey to agility by developing training programs. Usually, they do that at the outset to ensure that all employees understand their new roles and accept them in the new organisation chart. Nothing to do with Agile nor with agility.
However, in most companies the implementation of a new organizational structure like this does not deliver the expected results. Neither does it improve the customer focus in the teams nor does it increase the company’s capacity to react to change in the environment.
There are a number of reasons for these shortcomings, but the root of them all lies in the mindset itself. It is usually characteristic for most organisational transformations, that companies invest huge efforts in copying the methodologies and imitating the behaviours of their referents.
On the other hand, very little time is invested in understanding the essence of the system, the values that underlie all these artefacts and methodologies. Often, we want to obtain the results of a system without the firm commitment to accept the values of the new working culture.
In this particular case, The key is to understand that this whole structure of roles and functions is not what makes Spotify an agile organization.
In reality, it’s just the opposite. The organization had an evolving mindset based on agile values and principles before it had all these functions. Then, all these roles emerged progressively in a specific moment of their evolution. As a matter of fact, the teams themselves and some leaders of the organization found that they were necessary to provide value. They experimented and learned as they have continued doing experiment after experiment. Today they might be dozens of experiments away from that. Therefore, copying that has absolutely no sense for any other organization.
In this sense, we specially like this reflection from Taiichi Ohno:
“Stop trying to borrow wisdom and think for yourself. Face your difficulties and think and think and think and solve your problems yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up.”
So, if not by way of describing roles and functions: how should the shaping of an agile organization begin?
The Agile Organization: next steps.
Well, in 1968, Dr Melvin Conway published an article to spread some characteristics of those organizations that are engaged in the design of systems.
In the article, Dr Conway explained that organizations intending to design complex systems are totally committed to copying their own internal communication structures into this design. According to Dr Conway, the product or service resulting from an enterprise reflects like a mirror in their organization chart.
First of all, we should start by thinking about the value of our operations and the needs of our customers. Instead of designing the organization chart like a puzzle, trying to integrate the new roles that Spotify and others have added, we should think how we may achieve this. This is the only way to get an organizational design that efficiently meets your needs.
It is very likely that the teams resulting from this analysis of value flows will be multidisciplinary teams focusing on this same value network. However, we should not fall into the trap of thinking that each team in the organization will adapt to this model. In some areas of the organization, the most efficient organizational model will be a completely different one, depending on the value contributed:
Dependencies between the teams.
Regarding relations between teams, we can differentiate the following relationship models:
Conclusions.
As explained in this article, it is obvious that organizational design can never be the result of copying the roles or artifacts others have built into their organization. After all, we cannot hope that everything will synchronize naturally as if it were a perfect gear.
Finally, as we learned from our colleague David P. Hanna, it is essential to recall that “all organizations are perfectly designed to obtain the results they obtain”.
Consequently, it makes sense to initiate an organizational design change by thinking about the purpose of the organization, the customer needs, and what are the results we want to achieve.