It is important to point out already from start, that the organizational purpose, common for the employees in the whole organization, directly gives us the context. But it is also important to point out that we in our organizational definition “People that interact to solve activities with interdependencies for a common purpose” also have an overviewing often silent purpose, that all organizations are striving for, independent of context and therefore domain independent as well. Because, no matter company, an overviewing purpose is to deliver the product to the customer, which are the functional requirement on our way of working. And to achieve happy customers and stakeholders, we also need to add performance qualities, or non-functional requirements, on our way of working. The performance non-functional requirements normally go without saying, which means they are acontextual, and often not mentioned in an organization’s vision, mission or purpose statements. These performance non-functional requirements are; efficiently making the right product(/service) right at the right time, and effectively the right product with the right quality, to the right price and to do it in a qualitative and sustainable way. They are also the trickiest one to achieve, since they are directly connected to the fulfilment level of the organizational principles. We also have desirable and mandatory non-functional requirements like; adaptive (different kinds of products), making life-cycle manageable and traceable products, scalable (for example different size of the tasks), problem solving oriented (solving root causes, i.e., no sub-optimization), cybersecure, etc.
The functional and non-functional requirements are self-evident for any organization, and therefore do not have any uncertainty, since all organizations striving for the fulfilment of them, and never change them. I.e., any implementation of a way of working is about reducing transdisciplinary complexity at the same time as the organizational principles are fulfilled, to get it well-functioning, not about reducing the uncertainty to get it well-functioning, i.e., the context is already set; like manufacturing or product development.
All employees in any organization also knows and understands these performance non-functional requirements. This means that the whole organization are really striving for the achievement of them, it is really in the nature of us humans, since it is our ability for system collaboration. The solution of the functional and performance requirements becomes our way of working, that in turn leads to the fulfilment of the overviewing organizational context-dependent purpose (intention, e.g., are we manufacturing or developing cars). This is important to point out, since it shall not be mixed with that there can be uncertainty in what product or service to make in product development, since that is taken care of by our way of working, and by that making the right product to the customer. It is worth mentioning that when making big systems, having a way of working that efficiently reduce the complexity in the product, i.e., making the product right, is the hard part. This compared to the uncertainty in what product to make that in big systems normally is very low, except the frontend, which means the industrial design and UX parts that need very fast feedback loops, but that also is the smaller part of the system, with low complexity as well. We have of course not forgotten the utterly important sustainable health for our employees, for example, satisfied and healthy employees working a sound number of hours per week and find their work fun and challenging. We have achieved a qualitative way of working, when our employees are not making unnecessary mistakes or getting unhealthy, which in turn means that our way of working needs to follow our organization principles. But, remember that sustainable health is an emergent property and never something we can wish for, and strongly dependent on our way of working, which we have shown before in this article. Note that we of course need to take care of the uncertainty of our planned activities, things can go wrong etc., as well as that progress of an initiative is required, and many times also need to be visualized. This is why we have planning and release management as well as follow-up, as sub-processes to our total PD process, sub-processes that in turn generates necessary intermediate artefacts, not directly related to the product itself.
Worth to note about a qualitative way of working is that standards often look at quality for a way of working as the importance of follow-up that you are following your own way of working. The problem with that approach is that if the way of working is mal-functioning, it is actually not worth anything if your way of working is certified, since it still is mal-functioning. This is especially problematic regarding functional safety or cyber security, since important verification of the parts and the whole, and the final validation of the whole, may then be omitted. This then gives a risk for a non-safe and non-cybersecure product from a certified way of working, with problems found very late, which puts the organization in a very difficult situation. Nowadays, with all new methods and frameworks, this is really treacherous.
Even if the talk about the purpose as direct requirements on the way of working, can be seen as very theoretical, it is still of utterly importance. This because it means that a top-down approach starting from the purpose, when making our way of working, is mandatory, since it is truly integration of parts, i.e., we have a hypothesis that the parts together will be a united, unified and well-functioning whole. We have never aggregation of the PD sub-processes of parts of the organization, to achieve a flourishing organization. We also need to start top-down from the purpose, so we are sure that the new way of working covers all phases that are necessary for the complete life-cycle of our products, from idea to full release. Otherwise, the risk is high that we think that we rapidly can validate our way of working over some iterations, just because we can do maintenance or add some simple new functionality in an existing systems architecture. But, that kind of work is non-complex and mostly non-complicated, where short feedback loops can be used (and should be used of course), but does not represent all phases needed in product development. And all phases must always be taken into account in a complex context like product development, especially for novel products and novel platforms. So, beware of this false validation of a method or framework, even if it looks very convincing.
This also means that we are dealing with systems design not only for our products when breaking down the requirements on the whole, but also for our way of working. Every system, especially a novel one, has a high degree of transdisciplinary complexity that needs to be reduced. But due to the coming deductions in System Collaboration Deductions, all made from our organizational principles, the possible solution space for our way of working for product development is reduced dramatically; as if we had a clear context from the beginning. But we will of course also use common sense and experience from the past way of working solutions, for rapidly achieve a fast, awesome and also understandable implementation of the organizational systems design for our new way of working. All these deductions, based on science, our organizational principles, give the mandatory prescriptions, which builds the SPPA, SOSD and TDSD methods.
First when we have the context, like production or product development, we can understand what parts we need in our way of working and how they should interact in order to have a proper way of working that will fulfil our organizational common purpose. This is especially important for product development, that is a complex context, meaning that all our organizational principles need to be fulfilled. Having the context, it in turn, gives us the “activated” organizational principles in the context, the “activated” principles for our people and activities. Remember that System Collaboration is focusing on organizations, but that the principles are valid for any human complex adaptive system (human CAS). The “activated” principles, together with the domain (prerequisites including market need, competence, tools, technology, etc.) will induce a complete way of working in any context, so the organizational purpose of the organisation can be achieved. This series will in its articles cover all pieces needed, all backed up by deductions, regarding the design of the new way of working. with an extra focus on product development, where the theories and deductions, are the foundation for complete product development methods, like TDSD mentioned above. Since this foundation is based on already existing science, these deductions, and not only the science, need to be followed by any way of working, to be able to work properly, which includes also implementations of waterfall and Lean Product Development.
One of the most important principles of our organizational principles is the need of structure and order for us humans, when systems get big, which regarding organizations means the line hierarchy itself and other people structures, the big products the organization is handling, as well as all the activities in the plan to be able to develop these big products. And it is no matter context; production or product development. When the system is big, it gets too complex for us humans to get it right if we not reduce the complexity by structure and order it, which means at least these negative things regarding organizations at neglection; we get a chaos with all the needed people for achieving our initiatives, we lose the Big Picture of what we are doing, our products, and where we are heading, we lose our ability to refactor the code and architecture for our system because it is too big, we lose our ability to understand when tests on the parts and different flows are not any longer representing tests on the whole, we do not have the ability to track the bugs to the requirements on higher levels, and we do not have the ability to keep all information about the system and its parts in our heads, etc.. The last one, in turn means that we cannot present our product to our colleagues only orally, in the same way as that it is too complex for them to understand, only by listening.
We will now, without being more prescriptive than needed, start with what is the prerequisites in order to have a proper foundation of a way of working in product development. This foundation is valid for all product development methods in any domain, and without following these prerequisites, the actual product development method will fail, or in best case be extremely inefficient, without possibility to compete.
To avoid the chaos with too many people, is the reason why line hierarchies have been implemented and used by us humans for probably hundreds of thousands of years. A line hierarchy of some kind, is a necessity, when we have many people with different competences, doing different activities to keep track of, needing different tools at different locations, since structures are something we humans can easily interpret. From start the line hierarchy was probably mostly informal and not visualized, but at least the last thousands of years it has been formal, and today, visual organization charts are a necessity for bigger organizations.
But, it is easy to forget that this planning to achieve this people structure already has been done, even though planning is pure common sense, which can be further read about in this blog post series about common sense (especially in part 2, 5 and 6). We shall neither forget the experience of working with the products in the organization, the formal and informal channels between the people, and how the right amount of specialized respective broad competence have been built over the years of work, not to forget which decisions that can be taken where, and how they are taken.
Due to the existence of a line hierarchy, with all things that are inherit and invisible above, it is therefore easily taken for granted. This is especially valid for today’s transformation to agile at scale, where this is not taken into account, and neither the very high risk for sub-optimization when not having a top-down approach, which has been mentioned several times before. We can reflect on the last one on the former section; if we decentralize the decisions too far, how can we later even roll back to the old way of working, if the transformation to for example agile at scale, where decentralization is a central message, fail?
Looking at other organizational principles for us humans to follow, except the one about the need of structure leading to the line hierarchy, we also need to follow the organizational principle for trust and sympathy, when we are setting up our line hierarchy. This means most of all the organizational principle of 15 persons as the maximum size in the line hierarchy. If the number 15 is only slightly reduced to fit also the capacity of a second line manager and above, this means that for second line managers having first line managers under themselves, we will also achieve Dunbar’s number of 150, making the people of group of groups feel united (10 groups, gives 1+ 10*15 = 151 people). The relationship between the human capability limitations of 15 and 150, is most probably stronger than we so far have been able to prove.
Now it is time to change the focus to our product, which we have just touch earlier. Originating from the organizational purpose of the organization, besides the context, it is of course important to also consider also the following for the products that are developed; safety criticality, security level, organization size, product size (a big system is normally backend heavy, as well as we have low uncertainty in what product we are going to do), life-cycle, modular platform or not, to be sure what to deliver or not, and the time to market aspect, since they all effect the way of working. Even if every initiative is unique, we can from the organizational purpose, leading to the initiatives we have in the road map, understand what we need to require on our way of working.
To be able to achieve also structure and order for our products, we need documented information and requirements traceability. To accomplish that, we in turn need a proper systems design, as well as proper systems test for big systems. If we have safety critical systems, or systems that need security, or require a platform, then we always need to be highly structured and ordered, which means a systems design and requirements traceability also for smaller systems. Safety, security and platform, specifically requires system test specifications for the whole system, the subsystems, and even the sub-subsystems, all which are the results from the systems design(s), which make an agile at scale approach with emergent architecture/design also on the whole more than inappropriate, of at least the above-mentioned reasons.
We can also add that big systems have a tendency to have a long life-cycle, which makes the systems design even more important, so we not end up with a dead product, after some years of adding on new functionality, where the latter always are needed. A dead product is a product that no one wants to touch, because no one knows what will happen if we make changes to it; especially at bug fixing, but also when adding new functionality. The product life-cycle must also be considered for small systems and organizations, meaning once again, that agile at scale approaches focusing on emergent architecture/design, also on big products, easily can become a Walk in the Dark.
All above regarding our products, means that we need to have a systems-designed architecture of our product in order to not only understand it when it is completed, but also while we are developing a novel product, get the Big Picture overview etc., as described earlier. But, for novel products we do not have the knowledge about how to directly make the system architecture, only a system sketch. Therefore, we first need to reduce the transdisciplinary complexity/ complicatedness in order to get a united and unified whole, which is what systems design and systems test for novel products is all about. We need to iteratively make analyses and syntheses, so we finally can achieve our proper system architecture, which for big systems will not only have sub-systems (components), but most probably also sub-sub-systems.
Now it is time to move our focus back on our people developing our new products, because in product development the line hierarchy itself is not enough when we are developing novel products. This is due to the upcoming sub-optimization in product development with no one having responsibility and mandate for the wholeness of an initiative. We therefore need a virtual delivery structure, where the line hierarchy is used as a kind of resource pool, which is also one some of the reasons for the introduction of projects in the 1950s.
The same organizational principles used for making the groups in the line hierarchy with the numbers 15 and 150 is of course also valid for the virtual delivery structures needed in product development. The virtual delivery structure can be more of a static kind, which often is used in software development or dynamic which is often used when developing novel products in hardware development. Putting the numbers 15 and 150 together gives us that the maximum size of huge initiatives can be around 2000 persons and still have a flat virtual delivery structure of only two levels for an initiative. Each part (team of teams) can then have the needed recognition relationship, and the parts together are connected with sympathy and trust (the 14 team of team leaders plus the initiative leader), which is connecting them closely. In this way we have reduced the intermediates to a minimum.
In order to avoid loss and corruption of information, which depends on our organizational principles about Miller’s number and Chinese Whispers, we need to reduce the number of intermediates. This is a big difference from the line hierarchy, that has no limitations in the number of levels or the number of people in the line hierarchy structure, as long as the number 15 is fulfilled. But when developing novel products, we need flat virtual delivery structures to achieve few intermediates, which means that we shall never make a copy of our line hierarchy structure, since this will increase information loss and corruption.
The need of a flat hierarchy of course needs to be combined not only with our organizational principles about the numbers 15 and 150, but also the exponentially increasing number of connections between individuals and teams, when individuals and teams are increasing. This automatically gives that the more transdisciplinary complexity we need to reduce, the smaller the teams need to be, to reduce the number of connections, as well as the information loss when having too many intermediates. To have only a few people is especially valid when the complexity is very high, normally early on when making the initiative. This is also only common sense, since we do not want to waste money or people, before we know what we shall do, how the solution should look like, or if the solution is even possible. But we can of course not force ourselves to have the flattest possible virtual delivery structure with two levels for a bigger initiative, if the number of teams on the lowest level has 25 teams, not fulfilling the principle of number 15!
Conway’s law also needs to be considered, since a sub-system (or sub-sub-system) will be handled by one team, an explicit and obvious solution in order to minimize intermediates and the need to know everything about the system. An interesting reflection is that this means that the number of sub-systems (and sub-sub-systems) in the system architecture also need to be even more restrictive than the number 15 (actually the reduction made to 10 in the example above). If we continue on that reflection, it is also interesting to think about how much easier it is to get a good overview and understanding of a system architecture or hierarchy, when the number of boxes in the hierarchy, is reduced, which most probably is not a coincidence. Our cognitive limitations are strongly connected to each other, intertwined in our DNA due to co-evolution!
For examples of different virtual delivery structures, please see this blog post, for a deep-dive about what happens when an organization grows from a small to a bigger one, and the need of keeping the virtual structure flat.
Due to the need of virtual cross-functional delivery structures for product development in bigger organizations, there is therefore automatically a need of a portfolio. The portfolio is strategical/tactical and is responsible for the road map, a rough middle- and long-term plan. The portfolio is also the important interface between the line hierarchy and the virtual delivery structures, even though the portfolio team itself also can be seen as a virtual structure. The portfolio is also responsible for, and keeping track of the thorough planning and prioritization of all the different on-going projects/initiatives in the organization. From the road map, the portfolio gives the responsibility for operating the initiatives to the virtual structures. The initiatives started by the portfolio need to follow the portfolio strategy, that in turn ensures strategic alignment with company goals, derived from the purpose of the organization. To reduce intermediates, a flat hierarchy is needed also for the portfolio, which means that a portfolio of portfolios is not to be recommended, due to need of two levels and the increased complexity that will follow.
The flatness for the virtual delivery structure, can in most cases be done with two levels of different kinds of capabilities.
The first level in the virtual delivery structure, the tactical/operational wholeness level takes care of the architecture, functional and non-functional requirements, the systems design, the systems test as well as the overall planning and coordination of respective initiatives and also sub-initiatives, if an initiative is very big.
The team of team-level below the wholeness level is operational, and implements the sub-systems of the initiatives, preferably a whole initiative if possible. The teams are also helping with the implementation of the code for the systems designed architectural skeleton and other wholeness level coding, if that capability is not completely available on the wholeness level.
Here is a summarizing picture, prerequisites for a flourishing product development, which from the deductions above, describes what we always need in our way of working for an organization developing products, in order to be able to cover the whole life-cycle of our products developed, and by that achieve a flourishing organization.
Now we will continue with some words of the need of planning. This, since planning is a necessity in order to reduce complexity and by that avoid chaos for us humans; who will do what and when will it be done, as well as doing a visual presentation of it. It is really important to treat planning as one of the most important activities in any organization, no matter context or domain, and therefore it is of utterly importance in any way of working. We need to do the planning, in order to be systematic, and get a structure, overview and order, wherever possible. By reducing the complexity with planning, it will not only be easier to find the best logical order so we can use our people the best and deliver our products as fast as possible, but also to follow the plan, especially if it is visual to everyone. The planning in any organization always needs to be top-down as well, starting with planning of all the initiatives, which means that for the portfolio in big product developing organization with multiple initiatives, a visualized road map is a necessity. The planning will then continue with the planning of each initiative, with a visualization of the activities and connections both between activities within the initiative, and to other initiatives.
As with all planning, it needs to be done in advance, preparing the next level, which goes for any way of working, once again no matter context or domain. It is common sense, that we always need the best logical order of the initiatives (or activities inside the initiatives), since the number of our people is not endless, as well as the ability and competence of each individual or team, is not endless. We will automatically break the latter, if we are only using a short-term planning section for all teams at the same time, and omit the middle- or long-term planning. This because, it will first of all lead to that we need all possible competence within the team due to the lack of middle- and long-term planning, which in the long-run leads to that our people will be half bad at everything. The risk is also high that we try to incorporate parts of the wholeness level competence, experience and skills within the teams, making us lose also the wholeness level understanding and capabilities as well, due to sub-optimization within each team. It is also a high risk that we lose the common sense that the wholeness level for big systems needs to be planned for first, as well as wholeness work need to some extent be done in advance before the work of the team of teams-level even can start. Because we do not want that to happen, we need to spread out the start of initiatives over time in order not to overuse parts of the organization, not dilute the competence, or lose the wholeness. This means that this logical order of our initiatives always needs to be implemented using Overlapping Concurrent Sequences, which is used both in production and in product development from start. Overlapping Concurrent Sequences is actually the solution to the root cause of starting too many of the same activities at the same time. Otherwise, we will run out of resources with the right competence, i.e., which means bad planning.
For every level, the planning will consist of more and more details, rough in the portfolio and its road map and with more and more details and accuracy in time of delivery, via the wholeness level, down to the teams, which can give the best time estimate of when the work can be finalized. If the initiatives are new big systems or are enhancement of existing big systems, we always need to iteratively make or there is (or should) already be a proper systems design.
Follow-up of the plans are of course always important in order to have early recognition of problems, that can be due to variability, Murphy’s law, mistakes, inexactness, or problems with the way of working. Follow-up to understand the progress are always important, and is also an important part in order to be able to improve the way of working. And remember that it is always our way of working that we can improve, and it is not about blaming the employees.
Now we really understand the importance of planning in any way of working, and why we always need the four parts of a line hierarchy, systems design, virtual delivery structures and a portfolio, in any way of working for the complex context of product development. This foundation, based on our organizational principles (science) and deductions from them, therefore need to be followed by any proper way of working for product development, no matter domain. This is due to that science always is a constraint, but always in a positive sense, helping us to avoid failure.
Now it is time to take a deep-dive into each of the four parts separately, and the first part is an article deep-diving into the line hierarchy.