Welcome back. Today we will continue with more of the common senses that are independent of scaling.
Common sense: A top-down structure is important
If we look into the life of ants, which looks totally chaotic, science can now show that during evolution, ants have evolved and have today a set of pre-programmed rules [1]. The ants obey under these rules to be able to structure their nests, organise themselves in a structured way in the nests and to be able to find food. But, at the same time, these rules have enough flexibility so the ants can adapt to the environment and survive in a variety of different locations. All put together, these different structures; architecture, organizational structure and planning structure are necessary to secure the birth of coming generations of ants.
Even though we humans are very different from ants, structures for us are equally important and through history we have understood how to take care about different situations, since we have learnt that non-structure easily leads to chaos. Architecture (for both the product and the locations for the people developing and producing it), organisational structure (one for stability and if new products another one is needed as well) and the structure we get when we are planning the activities, have been used by our ancestors for several millenniums. All these structures are realized from a top-down approach, especially evident if the organisation is into new product development. The difference regarding structure between ants and us, is that the rules for ants are pre-programmed, but we humans can think ourselves, which gives us the possibility to make any structure. But still, we are not machines or computers, which means that if we aim for efficiency and effectiveness in our organisations, we need to be careful, so we only make structures that are appropriate for our own limitations. See this blog post regarding for example respect, Miller’s magical number seven, Chinese whispers and the other magic numbers 15 and 150 in human science.
If we look at the size of an organisation, the organisational structure is less important if the organisation is small. But, if we look at architecture for our product or service and the planning of it, these structures are equally important, no matter if the organisation is only one person or millions. The architecture can though be affected of the organisational structure, see this blog post about Conway’s law in human science.
Common sense: Planning need to be done top-down
No matter size of an initiative, or an initial activity, a planning needs to be done top-down, in order to make smaller activities. In an easy context, we do not need new knowledge, so it is just to divide into smaller activities, solve them one by one, and aggregate them to a whole.
But, if the initiative or other of the sub-activities are complex like in new product development, we need new knowledge in order to solve them, by experimentation or reducing the complexity by making smaller part, which giving smaller activities. The latter can be done through a systems design, where the output are smaller activities (with smaller parts as output), that not only fit together as when aggregating, but also integrates to a unified whole.
We can take an example of a Scrum team with a Scrum Master and a Product Owner, that all together are responsible for a product. They are doing the top-down planning and taking care of the needed systems design from the requirements, which also need to be done top-down. The systems design generates an architecture and parts that integrates to a unified whole, as well as all activities needed for design, tests and verification on the whole product.
This means that planning and systems design is done top-down, iteratively and intertwined when an initiative is broken down into smaller activities (smaller parts of the product), to later be integrated, validated and verified (bottom-up)
Common sense: Team sizes should be around 10-15 people
If we continue on the common sense of an organisational structure, we will have the group sizes in the organisation, which also goes well together with our social ability and wish to be part of something. A group of people of around 10-15 people, is what we normally have today regardless if we look at a line manager’s, a project manager’s or a team manager’s group of people. If the group of people gets bigger, it will be difficult to manage, which our ancestors found out a long time ago, see this blog post about sympathy, trust, social loafing and Dunbar’s number in human science, see this blog post for detailed information.
We can also add that the structure of the different groups within an organisation, have since ancient time been divided into a guild system. This in order to keep track of the competences needed for fulfilment of the aim of the organisation. Note that the organisational setup of guilds with their different competences, must not mixed up with the actual work done to achieve something in the organisation. This is especially true for product development of both software and hardware and their combinations, where the working teams can consist of a suitable number of people with different competences from the guild setup in the line hierarchy. This setup is used to be able to maximise organisational flexibility towards market changes and is further elaborated on in this blog post.
Once again, the top-down approach is necessary, i.e., it needs to follow the top-down approach when by systems design dividing the product in smaller parts, in order to not forget important competences, like generalists and cross-functional transdisciplinary competences.
Common sense: High complexity requires experimentation
High complexity can shortly be described as that we do not understand what we see, which makes it impossible to plan the future, without adding a tremendous time buffer and too many risks in the plan. So, when having high complexity, we need to experiment to gain new knowledge, where we have two kinds of complexity, disciplinary and transdisciplinary. The former means the we dig down into a discipline, making research to find new science, or new technology. The latter means experimentation be on an architectural level, where we experiment with architectural components and flows through the system. This in order to get fast feedback so that we can see that we reduced the transdisciplinary complexity correct when we integrated the parts. This mean that we experimenting with the systems design and we are doing a kind of skeleton of our system.
But, the treatment of complexity when not understanding the problem that we see in our organisation vs our product or service, has of some reason become extremely different. One reason for this difference, is that as humans we can adapt to the situation when having organisational problems, but the product cannot adapt, even though we cleverly add more and more safe-to-fail add-ons to our products and services. But the problem is that even if we humans sometimes can adapt to deficiencies in our way of working, but not always fast enough if the built-in deficiency in our way of working happened a long time ago, affecting the whole delivery.
So, when having a problem with our products or services that we did not foresee and cannot understand why we got them, we normally in our setup task force, firstly ask multiple why in order to try to find the root cause(s). Of course, the root cause(s) can be simple mistakes, but if not, the root cause(s) can sometimes show that we need to experiment to gain knowledge so we can solve the root cause to the problem in the product or service. This is also how the laws of science evolve, experimentation is needed when we do not understand or we need to confirm a proposition, which give us new knowledge and new scientific laws, see this blog post for an elaboration on the evolved science of understanding blood.
But, when having an organisational problem, the question why is too seldom asked, which means that we are only trying to solve organisational symptoms, and as we know, any symptom is impossible to solve directly. Symptoms are not only impossible to solve due to all other symptoms it generates, but if we still try, we will get solutions that are more impossible to master. Unfortunately, this means that if the “solution” when trying to solve symptoms, is formed to a method, it gets so complicated (not complex), that we or the inventor of it, cannot see it through. And if we are unlucky, we buy the method and implement it, even though we never asked why on our own original organisational problems. As you understand, by looking around on transformations of way of working in different organisations, not asking why on the problems, is unfortunately very common, which means unsolved root causes, built-into our way of working. This will lead to big short-term fails for the organisation to deliver what promised, and long-term, if the root cause is neglection of reducing this transdisciplinary complexity, it will lead to a self-induced extinct.
So, before we experiment, we always need to ask several why on the original problem, the common sense we discussed earlier, to get the root cause(s), and then and only then if we cannot solve it (them), we start our experimentation. This is further elaborated on in this series of blog posts regarding our problem-solving ability and how to boost it.
That was all for today’s blog post, c u tomorrow again for a continuation and more common sense we all have.
References:
[1] Snowden, Dave. Blog post. Link copied 2019-07-08.
https://cognitive-edge.com/blog/xmas-2017-i-introduction/