I am sure you have not forgotten our start organisation definition “People that interact to solve activities with interdependencies to achieve the purpose.”, that needed to be short just to be sure not to add any principles we did not need. After we derived the principles that the market needed, the definition helped us to finalise our set of principles. That was done by looking into the interwoven history of the market and the organisations up until today in even more depth, and at the same time take our evolutionary prerequisites into account. Where the latter is critical since it is built on our ability to solve problems, and where our evolutionary prerequisites are not different today or in ancient times.
And now when we have our set of principles, it implies that we can make our total organisation definition for a flourishing organisation, with only the derived necessary parts.
Here are first all the principles in our set of principles.
Principle: We need to respect our people.
Principle: We need to have a common vocabulary.
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 be able to work in parallel (if needed).
Principle: We need to be able to work incrementally (if possible).
Principle: We need to have timely* Integration Events** end to end – (to get just-in-time* feedback).
Principle: We need to have end to end control*** of our activities and their interdependencies, especially them on the critical line, when we are developing our system product and its deliverables, both short-term and long-term and timely updated, as well as on the different levels of our organisation.
Principle: We need to have the right competence and information to be able to make our system product and its deliverables.
Principle: We need to nourish broad competence, when needed in the end to end flow, to achieve better flexibility short-term (spanning from the needed T-shape when solving different interdependent activities in product development, to the needed multi-I-shape in production when solving different independent activities).
Principle: 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, including the customer and end user (so the activities with interdependencies easily can be solved).
Principle: We need to have 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.
Of course, the full organisation definition can be derived from our set of principles in many different ways, but here is one universal version for a flourishing organisation:
Respected people with a common vocabulary, working full-time in a flat hierarchy of teams**** founded on the numbers 5, 15 and 150, also in the light of Conway’s law, with the right specialist competence, and understanding the Cynefin™ framework and Conway’s law, that iteratively and in parallel if needed, interact freely and end to end over the whole organisation in as short chains of interactions as possible, giving them the necessary broad competence to also directly take care of organisational problems as well as do continual improvements, and therefore be able to efficiently and effectively solve, by also exploring in close collaboration with the customer and end user to gain new knowledge, activities with interdependencies, fully planned and under control, to be able to build the system product or service, incrementally if possible, always with the appropriate architecture under control and responsibility and always with timely Integration Events***** with verification and validation depending on context, to get just-in-time feedback, where also the long-term critical line, activities, interdependencies and Integration Events are fully under control, and visualised as well, to achieve the purpose.
And the saying, “A picture says more than a thousand words”, is probably right this time as well. But, the organisation definition is not too long for memorisation, especially not if we just need to remember our set of principles, right!
But, why not only use our set of principles? The reason is that there is too many home-made principles in too many methods and frameworks nowadays. But, just because someone calls something a principle, it does not make this something change to a principle. A principle is only a principle when it is grounded in science, meaning it is valid in every context, it is context-free. And if we state that our principle is something we need to do, then it is a method, and methods are not context-free, they fit into one of the different domains in the Cynefin Framework. So, by using an organisation definition as above, there is easier to avoid home-made principles, since the organisation definition is really all we need regarding our people and the activities they are solving. And when “principles” start with verbs like reduce, manage, decentralize, build, apply, etc., they are fake, and instead clearly are context-specific, non-universal and home-made methods.
Our set of principles and our organisation definition are also good so we can see through this massive overflow of information, an increasing amount of aggregated Best practices, that is claimed to present the wholeness. And with the ease of updating a home page to add more information, without our set of principles and organisation definition, it is hard to see through. Add to this also people that are very skilled in talking, sales-man bringing us gold and green Forests, con men and panacea peddlers, as Dr. Russell Ackoff would have stated it. The methods and frameworks become gigant smorgasbord of Best practices that the organisation can pick from, but nowhere is stated which pieces fit together. Not even the author can show which pieces fit together. They cannot even show if there is pieces that fit together. So beware ouch there.
Some of you maybe wonder why there is not stated in any principle, or in our organisation definition about our people to have; engagement, trust, (intrinsic) motivation, responsibility, etc. or why not state that the information is open, transparent, etc. The reason is simply that it is one of the key things when thinking about our organisation as a system, because we are making a flourishing organisation from start with our set of principles. And since all our people are our organisation, it is in fact our people that are making the organisation flourishing, the principles are only the enablers, so the former above is the result from all interactions in our organisation, the latter are more depending on context, since transparency are not always good. This will be thoroughly handled in later blog posts handling mindset, culture and values, and when our Prefilled Root Cause Analysis Map will help us open our eyes even more.
In earlier blog posts we showed that for achieving more speed, parallel work is needed, but what does parallel work really mean? How can for example waterfall way of working with its phases that need to be in consecutive order with handovers between the phases, really work in parallel? And how does the work inside a phase look like? And how big is really the difference between work with I-shaped or T-shaped teams. Is sequential or parallel to be preferred in a certain context? Can you say that someone of them is better than the other? Can you work with them intertwined? Or are they always intertwined?
There are many questions, and from tomorrow and for some days, a series of blog posts will deeply analyse sequential and parallel work. C u tomorrow.
*according to context and the needed flexibility, which means that we need to understand, nourish and be able to do work in every domain of the Cynefin™ framework, and also recognize and promptly respond to context switches, deliberate or accidental.
**in manufacturing we have Aggregation Points, which is a special case of Integration Events taking zero time.
***since variability always is around, we need to handle it with over-capacity or/and time plan margins, see this blog post for a further elaboration of queues and variability.
****diversity must always be considered when putting the teams together.
*****an Integration Event does not explicitly need to be an integration between different parts, it can also be the integration of the code to maintrack, getting feedback or discussing with the customer or getting feedback at a demo. Aggregation Points like in production are a subdomain of Integration Events, in fact an Integration Event taking zero time.