Welcome to the second and last blog post in this series about human science and today we will go through the body of knowledge we stated yesterday and see what that means to make our set of principles updated as well as complete.
One remark to make is that the human science referred to, is the cognitive ability we have as human beings before we make the organisation and which give constraints how an organisation’s way of working can look like. This is key to understand, since that makes the set of principles valid for all organisations. And during evolution, the principles and their interplay, has co-evolved into what they are today, i.e., fully compatible which each other. A big difference between us humans and (most) other animals is that we can intentionally or mainly subconsciously violate our own cognitive abilities, which means organisational problems, where the violation is the root to the problems. These problems can therefore only be solved by fulfilling the cognitive abilities again, which Dr. Russell Ackoff called to dissolve problems. So, as Dave Snowden at Cognitive Edge often states; “humans are not ants”, since ants can only strictly follow their rules, but we can violate them, and if we do, we will cause ourselves trouble.
We need of course to respect our people, to listen to their opinions so we can make our organisation, our system better. Then they will care about the company and be great contributors for a long-term success, but if we not listen to our people, not only our system will not improve, but we disrespect our people as well. Toyota has respected their people since the start taking care of all suggestions (and I mean all), and this is of course one of the reasons for their success. Their team work and never-ending local continuous improvements within respective process, implemented continually and synchronised on the total plant together with problem-solving locally and on the wholeness has never stopped. To understand the difference of improvements and problem-solving is of course vital, see this series of blog posts for a deep explanation.
Note! Within the principle “Respect for people” is always the need of objectivity. Nothing is so dangerous as accepted unobjectivity, since it will lead to polarization in the organisation, a polarization that sooner or later will tear the organisation apart. An unobjective statement is not an opinion, it is only wrong.
Up to 15 employees per manager or project manager are normal manageable figures at many companies, and relate well to the number 15 [2]. Lower values are needed for teams that have the same skills working together on the same group task without unique sub-tasks, to avoid social loafing, see the Ringlemann effect [5].
Dunbar’s number [1] 150 also relates well to the number 15 [2]; a CEO for a small company with 14 persons in his management team, all of them responsible for a group of 14 persons, will give the total number of 211 as maximum for a small company, similar to a tribe (with many families) in ancient times. Passing more than 200 persons in a tribe, meant to split the tribes into two, which Spotify experienced when their Tech organisation became 200 people; people within the organisation could not recognise each other or remember the names, which effected the collaboration negatively [9]. So, for small companies becoming big ones, Dunbar’s number telling us that another hierarchical level is needed, meaning that we are leaving the flat hierarchy. To make a big tribe in ancient times with another hierarchical level, was most probably not possible, due to the tribe’s headman was leading through his power of persuasion, like a visionary leader, rather than clear authority to enforce his decisions [8].
Even when a small company becomes big, the broad competence can still be kept as a result of the introduction of projects, which is nurturing T-shaping, one of our principles. But remember that still today Ford is the role model for most of today’s business, emanating from its success story until the oil crisis 1973, when the market stopped with the double digits increase of sold cars every year. This implies that KPIs per silo and further down in the silo’s hierarchy, are still ruling, which automatically due to sub-optimisation, leads to specialisation and over time also loss of the broad competence for the employees. It can be stated like:
The easiest way to make an organisation non-adaptive, is to put KPIs on its parts.
Specialisation in turn, means many part-time resources to the projects. And since specialisation means less and less time for real work, the problem accelerates over time. Because, many times employees are also specialised within a group in the Line organisation, due to the unawareness of that specialisation is the root cause to its problems, not the panacea. Specialisation also within groups, means more and longer Mean queues, see this blog post. And the longer Mean queue for an employee, the more activities (objects) to juggle with and keep in mind, where the latter will have consequences due to our human abilities. And when stress comes into play, we already know that the number of objects that we can juggle with will decrease even more, which have connections to Miller’s magical number seven [3][4]. The effects of specialisation are new chains of symptoms that we can never foresee exactly, even if we can have a clue.
Structure is a way for us to reduce complexity where planning is an important part. But, for example hierarchies in organisations is another typical example, for dividing competences into appropriate groups following the numbers above. Making architectures is another way that we used for a long time to reduce complexity for a system product. When making the system product’s architecture and its part’s architectures, and at the same time putting up the team setups and their respective location relative to each other, it is important to consider Conway’s law [6], in order to avoid a crappy systemisation*. Since architectures follow the people structures in several organizations, that means that many architectures also follow the numbers 5 and 15 for people. In combination with Miller’s number, maybe this is not a coincidence, but instead an appropriate solution for us humans.
Visualisation is of course also is a way for us to reduce complexity, which is valid for all three structures, where the structures are easily understood with pictures. Words alone make it very difficult to understand architectures, organisational structures and time plans (incl. WBS-structures).
Chinese whispers [7] tell us to shorten our interaction chains as much as possible, and not build too high hierarchy levels especially when solving activities. Higher hierarchy levels introduce coordinators with even more filtering, not to say the negative increase of Project Administration waste. At the same time other human constraints, tell us that we must reduce the number of interaction chains that an employee is part of. Put together this tell us to use flatness in our organisation, with the team of teams and teams close to each other and no coordinators between the team of teams and the teams.
The above information about problem-solving, continual improvements, team sizes, teams close to each other in a flat hierarchy (our boat), an architecture for our system product and Conway’s law, gives us the following principles to add a new one and update two in our set of principles:
Principle: We need to take care about encountered product or organisational problems directly and also continually do improvements, as well as clearly understand the difference between them.
Principle: We need to have an organisational structure and control and responsibility over the system product’s architecture and its parts.
Principle: We need to have full-time members in our working teams**, in an as flat hierarchy as possible, following the numbers 5, 15 and 150, also in the light of Conway’s law.
Principle (updated): We need to nourish as short chains of interactions as possible; within the silos, between the nearby silos and cross-functional over all silos (end to end), as well as at all different levels of the organisation (so the activities with interdependencies easily can be solved).
Note! The second principle above says working teams, and should not be mixed up with a possible Line Organisation. Because in a big organisation, the Line Organisation hierarchy can still be very big, but that does not mean that the working teams need to mirror the Line Organisation’s hierarchy. See this blog post for a further elaboration regarding the Line Organisation vs the working teams.
In the picture below to be added to our picture of our set of principles, the above information about team sizes, teams close to each other in a flat hierarchy, an architecture and Conway’s law, would look like this.
Our root causes look like this:
One thing to mention is that it is a big difference between human science and other living science, and that is due to our human ability to have intention when we are doing things, which is a fantastic ability, as well as our adaptiveness. But that also means that we easily can break the laws or principles within our DNA, which animals cannot do. Termites must strictly follow what is in their own DNA, there is no room for any intentional behaviour that we humans can do. But, our strengths are also our weaknesses, which has been very revealing for our organisations the last decades, since we are violating principles without really understanding it, leading to failure in many organisations even though we try to adapt, especially in the organisations where reductionism reign.
This was all for this short series about human science and in tomorrow’s blog post we will wrap up our full set of principles; go through the parts of it, including the body of knowledge from above and then present the total picture of our set of principles, valid for any organisation.
Next “chapter” according to the reading proposal tree is the Principles from “to solve” blog post series, the middle part of our organisational start definition.
*Crappy systemisation happens easily in software product development, since the architecture with its connections between the parts are not visible, like it clearly is in hardware product development. Software product development with Agile development using T-shaped teams make crappy systemisation even easier, due to violation of Conway’s law [6].
**diversity must always be considered when putting the teams together.
References:
[1] Dunbar, Robin. Link copied 2018-09-14. https://en.wikipedia.org/wiki/Dunbar%27s_number
[2] Snowden, Dave. Link to blog post copied 2018-09-14.
http://cognitive-edge.com/blog/natural-numbers-networks-communities/
[3] Wikipedia. The magical number seven. Link copied 2021-10-25.
The Magical Number Seven, Plus or Minus Two – Wikipedia
[4] PNC – Proceedings of the National Academy of Sciences of the United States of America, Jeffrey N. Rouder, Richard D. Morey, Nelson Cowan, Christopher E. Zwilling, Candice C. Morey, and Michael S. Pratte, “An assessment of fixed-capacity models of visual working memory”. Link copied 2019-02-07.
https://www.pnas.org/content/105/16/5975
[5] Ringlemann, Max. Link copied 2018-09-14.
https://en.wikibooks.org/wiki/Managing_Groups_and_Teams/Social_Loafing
[6] Conway, Melvin. Link copied 2018-09-14.
https://en.wikipedia.org/wiki/Conway%27s_law
[7] Chinese whispers. Link copied 2018-09-14.
https://en.wikipedia.org/wiki/Chinese_whispers
[8] See tribe in the register. Link copied 2018-09-14. https://www2.palomar.edu/anthro/tutorials/cglossary.htm
[9] Spotify. Link copied 2018-12-09.
https://www.youtube.com/watch?v=ZZFc9Epznuc, at 28:05.