We people have since ancient times liked to work in guilds. This makes an aggregation of guilds to silos, and the aggregation of silos to a line hierarchy, a fully natural solution in order to reduce the complexity when having many people. We can simply always use this stable structure when we have many people in the organization to get an overview and understanding of the organization. This is valid even though our people are having the same competence or many different competences, and is also independent on what context our company is operating in, we still need to have a people structure, see this blog post for more information. The line hierarchy can therefore for these aspects be considered as a big resource pool.
For the line hierarchy construct, we of course always need to follow our organizational principles. The ones we especially need to focus on is the ones regarding the size of different people structures. The most important one is the principle about trust and sympathy, which means to have a maximum of 15 persons in a group of people, including a leader of the group. We also have the principle about the name and faces we can recognize and remember in one context, which means a maximum of 150 persons (known as Dunbar’s number) in a group of groups. Of course, the principle “Respect for people” is self-evident in any constellation of people, with two persons or more.
The line hierarchy is not only a people structure, but also, with start from the organizational purpose at the top management, responsible for the strategy and tactics, and also stability regarding the development of competency, number of resources, career, education, guild, salary and bonus, etc. It is worth mentioning that without this top-down structure of purpose and responsibility, it is impossible for an organization to achieve anything, since there is neither direction nor mandate for setting the direction*. The hierarchy has fixed this chaos for us humans for hundreds of thousands of years.
The line hierarchy, is therefore the basic fundament for any organization, which makes it possible to use in any context, and therefore also within any domain. The line hierarchy for big organizations, as stated above, is divided into silos, which are then divided into smaller and smaller, and more and more specialized entities, ending up in guilds. The different silos can be for example; administration, sourcing, production, system, design, integration, test, service, supply, in-house network and infrastructural operation, and many, many more. This construct is also very important for an organization to keep its specialist competence, which becomes obvious when having the complex context of product development, with the need of adding virtual delivery structures.
In a Clear context, like production or production-like, it may be possible that the line hierarchy is responsible also for the predefined (or clear) sub-deliveries from the respective “guild” (process), even though a team per guild, as a virtual delivery structure, many times can be a better solution to increase efficiency and effectiveness.
But, for Complex and Complicated contexts, like product development, a virtual delivery structure in combination with the stable line hierarchy, is a necessity. This, to avoid the classic sub-optimization, that not only starts when no one is responsible (no one takes responsibility) for the whole, but also when adding measurements, like KPIs, on the silos and their parts. For these contexts with higher complexity, when for example big products (systems) aredeveloped, hardware (electronics, buildings, bridges, vehicles, etc.) or software, we in both cases need a proper system architecture, when developing the system. We then also need competences and abilities, appropriate tools, test environments, educations, the total architecture and systems design, its maintenance, etc. to achieve the system architecture, systems test, etc., which also will be the responsibility for the managers within the silos in the line hierarchy. This means that we need guilds also for them as well, which in the end means silos of some kind, to be added to the line hierarchy.
Since the line hierarchy is a stable people structure and more like a resource pool, that also means that if we have problem with the deliveries or other organizational problems, reorganization of the line hierarchy will never be the long-run answer. That is why we continuously need to use the method SPPA, to be able to find and eliminate the root causes to our organizational problems, where the solution may be to fix the virtual delivery structure to become better, or add one, if it is missing.
A manager responsible for any kind of delivery team (I-shape or T-shape does not matter) is the same severe sub-optimization as a line hierarchy without virtual structures (like projects). It may even be a worse sub-optimization, especially regarding agile teams, since it is much easier to compare agile teams than hardware teams, since the latter normally are very different. When problems are raised within the agile team, the risk for favouritism or dominating behaviour from the manager, when everybody have the same manager, is increasing as well. Not to forget that many managers think that more specialization is the answer to many (or all) their problems, which will risk to hamper the necessary T-shaping within agile teams when things get tough. And finally, the risk of imitating other managers changes of their (agile) teams, even though the teams not having the same context; different challenging tasks, number of dependencies to other teams, or team of teams, experts, etc. Team with more complex context can have severe difficulties to solve their problems, with a manager “owning” the team, needing everything to look 100% perfect, where we under all circumstances must avoid using the team’s own measurements. This is actually very similar to the case when not having a team in a Clear context, since the concept of a manager “owning” a delivery team is always a very high risk.
These two examples, when having sub-optimization, show why it is necessary to always have a stable line hierarchy, and to add the virtual delivery structure when needed. A missing virtual delivery structure is the solution to many organizational problems, not only the obvious sub-optimization.
The next article in this series is about the need of doing a systems design in order to reduce transdisciplinary complexity /complicatedness, something that is a necessity for all domains of product development.
*This is easily forgotten in today’s transformation, many of them trying to remove the line hierarchy, or trying to soften the mandate of the line hierarchy, but without the line hierarchy it would not even be possible to get the mandate to do the transformation. Or undo it, if it did not work. We should reflect on this…