As systems engineers, we frequently speak of seeing the big picture, taking the systems perspective, and holism. We talk about using multiple viewpoints to study problem and solution. We seek a lifecycle perspective to understand not only design but also production, operation, maintenance, retirement, and disposal. In fact, it is not a single perspective we need – or multiple perspectives from a single individual. The problems we address and systems we deliver are transdisciplinary in nature, requiring us to blend the insights, ideas, and perspectives of a diverse set of engineers, stakeholders, subject matter experts, and more.
While we explicitly speak of viewpoints and perspectives, we rarely speak of worldviews. Don Beck and Christopher Cowan, in their landmark book Spiral Dynamics, define a worldview as “a belief structure, organizing principle, a way of thinking and a mode of living.” Some consider worldviews a topic better left to philosophers and social scientists, but the worldview that underpins our thinking fundamentally shapes and constrains our perceptions. Worldviews not only affect the way we see both problem and solution, but they also drive the language we use, the positioning of ideas, and the way we hear others. Worldviews are inextricably embedded in our perceptions and in our ability to communicate and collaborate with those around us. Understanding the power of worldviews is essential for systems engineers who serve as the technical connective tissue of the team defining the problem, analyzing it from diverse perspectives, and identifying the best solution.
The French philosopher Edgar Morin writes:
…our thinking is ruled by a profound and hidden paradigm without our being aware of it. We believe we see what is real; but we see in reality only what this paradigm allows us to see, and we obscure what it requires us not to see.
As we become more aware of the connections and interdependencies in the world and in our systems, we recognize that such filters on our perception become critical limitations. As individuals, we can seek greater awareness of our governing paradigms and enrichment of our worldview to limit those perceptual problems. In doing so, we can seek to leverage the power of worldview to better “see what is real.” In connecting teams, we can also deliberately seek not only to blend perspectives and insights from diverse individuals, but also to leverage the power of their diverse worldviews. But that very power also represents peril. If worldviews rule how each of us sees reality from our perspective, our worldviews also implicitly constrain our ability to connect with others, creating barriers to truly blending multiple perspectives to see the right problem and deliver the right solution.
Signs of Trouble
So beyond enriching our understanding of the concept of worldview and being aware of its impact on our ability to understand complex problems and collaborate with others to deliver solutions, what should a systems engineer do? Because our worldview operates at such a deep level, it begins with an awareness of self. And, there are signs that we can watch for, signs that tell us when a worldview (either of an individual or a team) is fundamentally limiting our effectiveness.
In a previous discussion of the 5 perceptual positions, we noted that the second perceptual position is often mischaracterized and misunderstood. The first perceptual position is how we see a situation. Most frame the second perceptual position as “how I would see the situation if I were in their position.” In reality, the second perceptual position is not how I would see the situation from another’s position but how they see it from that position. What may sound like a minor difference in framing is actually a major difference in perception and empathy.
Often, this error manifests itself within the systems team itself. If we don’t seek to see the situation as others see it from their perspective, can we truly leverage their perspective, much less their worldview? Yet this first indicator of trouble seems ever present. As we know, most people do not listen to understand, but instead listen to respond – an indicator of not only poor communication but also an inhibitor to empathy, understanding, and the power of worldviews.
There is another, more insidious, way that this manifests itself – in the way systems teams perceive the intended users and customers for the systems of interest. If we do not seek to understand and appreciate the problem in the way users perceive it, can we truly empathize with them and develop a solution that they will use and appreciate? Too often, engineers and designers assume their users think exactly like they do or actively lament that the user community does not. Even more problematic is when a systems team seeks to develop a second generation system – one that takes the benefits delivered by an earlier solution and makes it accessible to a much larger audience – but fails to account for the perceptions and values of the larger audience. Regardless of whether that system is technically viable, it will ultimately fail to meet its objectives as the systems team failed to truly understand the problem space – in this case the part of the problem space relating to adoption.
Moving Forward
Then how do we move forward, particularly given the disconnect between the “hard sciences” in which engineers are educated and the “soft” aspects of perception, perspective, and worldview? Simply enough, it begins with awareness and appreciation – awareness of the concepts, awareness of the impact and limitations that our worldviews create, and appreciation of the importance – appreciation which is often hampered by terms such as “hard” and “soft.” If worldviews constrain our perception of reality, underpin our choice of language for problem and solution, and fundamentally impact the way we connect with others, achieving a greater understanding of these concepts is certainly worthy of investment.
Beyond understanding, we can seek to expand and enrich our own personal worldview. For those deeply immersed in math and science, the recommendation is often to engage other parts of the brain – through music, art, photography, or poetry. But in this case, engagement requires more than appreciation of the work of others. It means engaging yourself in playing music, creating art, taking photographs (which is far more than snapping pictures or selfies), or writing poetry. That art and poetry doesn’t have to be shared with others. It can be purely for the exploration and enrichment of self.
Most importantly (and perhaps most easily understood) is empathy – with our team members, with stakeholders, with users, and simply with one another. Seek to understand before seeking to be understood, make an effort to go deeper than listening to respond but listening to understand concept, perceptions, values, and perspectives. So while it may be easy to understand both empathy and its ability to help leverage the power of diverse worldviews, it requires deliberate effort. Often those same techniques that we use to elicit requirements – techniques such as asking the “5 why’s” to elicit the real requirement underlying the initial statement of need – can help us with empathy if they are taken not in a spirit of debate, but as part of the journey of discovery and mutual understanding.
As Einstein famously said, “We can’t solve problems by using the same kind of thinking we used when we created them.” Underlying that thinking is the worldview that spawned both problem definition and the corresponding solution. As systems engineers, we must be conscious of both the power and the peril in the worldviews that shape our thinking if we wish to be truly holistic in delivering systems that meet the user need free from unintended consequences.
(A hat tip to Dr. Duarte Gonçalves for his workshop “Personal Awareness for Complexity” which clarified the underlying concepts and put language to these challenges that I have been observing in the systems domain.)
Awesome read. Thanks for the article. Another inference that I make of this article is that no two systems engineers can ever be same, and the solution they develop for a common problem might be very different in its entirety, even if they use the exact same tools and techniques. Is this a prevalent notion in the systems engineering community?