We people have always liked to work in guilds, making the division of the line hierarchy into silos to a fully natural solution to reduce the complexity, the need of structuring when we have many people in the organization, see this blog post for more information. The line hierarchy, which is context independent, is the basic fundament for any organization, which makes it possible to use in any context, and therefore also within any domain. The line hierarchy is divided into silos, and then divided into smaller and smaller, and more and more specialized entities, which is important for the organization to keep its specialist competence. When product developing big systems, it does not matter if it is hardware (electronics, buildings, bridges, vehicles, etc.) or software, since in both cases we need a proper systems design and systems test, when developing the system. This means that we need these competences, and we need guilds also for them, which means silos of some kind, maybe one for each of them. The line hierarchy is not only a people structure, but also responsible for the strategical and the tactical, and also stability regarding the development of competency, number of resources, career, education, guild, salary and bonus, etc., i.e., like a big resource pool. In a Clear context, like production, it is also possible that the line hierarchy is responsible also for the deliveries, see the coming chapter about virtual delivery structures for a deep-dive. But, for Complex and Complicated contexts, a virtual deliver structure is needed to avoid classic sub-optimization. We also need appropriate tools, test environments, educations, the total architecture and systems design, etc. that also will be the responsibility for the managers within the silos. The silos of the line hierarchy can be for example; administration, sourcing, production, system, design, integration, test, service, supply, in-house network and infrastructural operation, and many, many more.
Since the line hierarchy is not responsible for deliveries to customers, that also means that if we have problems with the deliveries, reorganization will most probably not help, but we of course always need the root causes to our problems to be sure.
Note! 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 regarding agile teams, since it is much easier to compare the teams, in comparison with hardware teams, that normally are very different. When problems are raised within the team, the risk for favouritism or dominating behaviour from the manager, since everybody have the same manager, is increasing as well. Not to forget that many managers think that more specialization is the answer to everything, 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 have not 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.
The next blog post in the SOSD series is about the need of a systems design in all domains of product development.
C u soon :-).