Synergistic thinking - IV: Where does it matter?

Synergistic thinking - I
Synergistic thinking - II
Synergistic thinking - III

Just a refresher: Synergistic thinking is the mode of "what is" or "theory building" thinking or thinking about underlying principles. My theory is that synergistic thinking is naturally inherent in all of us; but it is something which we don't seem to recognize and harness its power systematically.

Some people seem to have a greater inclination towards synergistic thinking, than others. Unfortunately, this is often seen as a "disorder" of sorts. Synergistic thinking is characterized by multiple cogitative processes forking off simultaneously in different directions based on different facets of a problem. Each cogitative process tries to determine underlying principles according to the dimension that it is pursuing. These underlying principles that are unearthed typically conflict with one another and need to be refined.

Synergistic thinking stops when a "synergy" or "harmony" state is reached where the number of conflicts across the different facets are minimized.

Synergistic thinking is contrasted with the more conventional "how to" thinking -- or imperative thinking. Imperative thinking follows a single cogitative path (usually the path of least resistance or the currently most logical path). The goal of imperative thinking is to reach a particular conclusion that answers the question of what to do next.

Most professions predominantly require imperative thinking skills. If you are driving a bus, you need to know "how to" drive a bus. If you are providing phone-based support services, you need to know "how to" deal with customers. If you are an electrician fixing a high-voltage power line, you need to know "how to" go about the process (safety checks, etc.) If you are a doctor, you need to know "how to" systematically diagnose an ailment and "how to" prescribe a medicine. And so on.

However, underlying each of these "how to" skills is a body of "what is" knowledge, whose awareness makes the "how to" skills far better. If you understand the design principles of a bus, it makes learning "how to" drive a bus much easier. You know for example why you need to press the clutch for changing gears; you can decide on your own what needs to be done to increase mileage, etc. If you understand the design principles behind a high-voltage power line, you can understand the reasons behind the safety rules and regulations. When in doubt about compliance of a safety standard, you can refer to your underlying "what is" knowledge to take sensible decisions.

There are some professions however, which predominantly require "what is" skills. Academics is one, of course. But in recent times, increasing automation has resulted in the development of very large scale information systems. A typical large organization today has tens of thousands of machines and users and applications distributed all across the world and each having different resource requirements. In addition, there is this all pervasive problem of safety and security.

Increasingly such large-scale information systems are looking like a continuous game of policy formulation and enforcement. New security patches are released, new firewall rules are made, new access-control and privilege mechanisms are created every other day. In my opinion, this is an area where synergistic thinking skills are sorely required.

Similarly, drafting of a collaboration memorandum between companies, designing an insurance policy and its terms, designing a game and its rules -- all require a clear understanding of the underlying principles.

Unfortunately, we don't seem to recognize the inherent synergistic thinking skills that all of us possess and seek to develop them. Instead, we try to pose these "what is" problems as "how to" problems. We see people asking questions like: "How do we design a set of terms and conditions for this insurance scheme?" "How do we design the workflow for a large bank?"

There are no simple answers for such questions. In fact, some of the "how to" answers that I've seen for such questions look like: "Use design patterns" or "Use J2EE framework" or "Use Ruby on Rails" :-)

None of these will guarantee a solution. Unless you can understand "what is" the nature of the problem you are addressing, no point using any bleeding-edge technology. We need to be developing the appropriate thinking skills in order to address such problems.