Systems and Issues
I hate politics—especially national politics. I believe both parties are taking us down a road away from what the Founding Fathers had in mind when the pledged their lives, their fortunes, and their sacred honor to the defense of what is right and good. One's moving a bit faster than the other, but the direction is the same.
How do I keep getting drawn into taking emotional stands on political matters? Kicking myself last week for allowing myself to hyperventilate on yet one more political issue, it suddenly struck me: I can be emotionally manipulated because when an issue is raised, I focus entirely upon its details.
So, Issue A: Any idiot can see that the only proper perspective is pro! Issue B? You'd have to be a fool to think anything but con! And so on.
The flash of revelation I had was that my emotional responses to issues were "handles" —levers by which I could be easily manipulated. They turned me into what Lenin called a "useful idiot."
What I should be focusing on instead is the systems in the contexts of which the issues are being raised. In politics, people are convinced that what is under consideration, what is in play, and what they can influence, are issues. But in fact, issues are only tokens in the game.
Politics is actually about systems. The systems' control of issues and people, and their interaction with one another, are the mechanisms of political reality. Moreover, political systems are layered and secretive to a degree largely unimagined by the average person. Who or what is causing any given direction or set of events cannot easily be described—even in those rare instances when it can be discerned.
I don't pretend that this nugget has given me total enlightenment about the political scene. But it has helped me get some perspective on the matters at hand.
The application of this reframing to engineering should be clear; people are people, whether they are politicians, engineers, or managers. As an engineering professional, are the trees obscuring my view of the forest? Am I allowing issues to draw my attention away from the more-important context of my work?
In engineering terms, there is a big difference between an issue and the system of which it is a part. An issue is an unresolved question. A system is "an assemblage of inter-related elements comprising a unified whole" (Wikipedia). This is not semantic buck-passing; the notion of a "unified whole" implies a function, and the "assemblage of inter-related elements" says that the functioning of any of the parts affects other parts.
CAD models are often treated as systems. In an electronic packaging situation, we note that the case that is supposed to enclose a printed-circuit board is too small for the board; so we make the case a bit bigger. The CAD system allows it; we haven't violated any geometry rules in so doing.
But that resizing may have profound effects on the product of which the board and case are only a part. The "ripple effect" of such a change can be chaotic—and expensive. By resolving an issue—"need more room for the PCB" —and ignoring the larger context of the product system, we wreak havoc in the project.
Another way of looking at this is as a manifestation of the "not my table" problem. One of my favorite old cartoons shows a fancy restaurant, in which a large curtain has caught fire. A diner hollers to a waiter, "The curtain's on fire!" "Sorry, sir; not my table," responds the indifferent waiter. It is possible—not in your organization, of course, but in others—for people to elevate the observance of boundaries above common sense.
Read the post-accident investigation reports from any engineering failure—the two Space Shuttles; the Kansas City Hyatt Regency pedestrian bridge; Three-Mile Island—and you will learn eye-opening lessons in the subtleties of blame-avoidance. Everyone is so careful to point out how they fulfilled their own duties, so the responsibility for systemic failures cannot be laid at their door.
Perhaps it's time for some holonic thinking. Engineering consultant and researcher Dan Appleton points out: "To paraphrase Alvin Toffler: today's concept of the enterprise is obsolete. Instead of rigid conventional departments, the form is divided into a highly flexible structure composed of "framework" and "modules." Instead of being treated as an isolated unit, it is pictured as part of numerous shifting "constellations" of related and continuously self-optimizing companies, organizations, and agencies. The enterprise is a "holon," an entity that is, at the same time, a whole unto itself and a part (as in proton or neutron) of many other wholes. Its continuing challenge is to optimize its own behavior. The framework is the thin coordinative wiring that strings together a set of temporary, modular units. The constellation consists of the company and the independent or semi-autonomous outside organizations on which it relies."
This brings me back to the theme of my recent book: "Structure is Destiny: The Dandelion Paradox." If we are to maximize systems thinking and minimize issue-based disasters, we need organizational structures that avoid the "not my table" problem. It is an organizational issue, and one we'd better face, as our lives and work get more and more complex.
Interested in a "Management by Respect" workshop, based on application of "Structure is Destiny" concepts to human relationships in business? Write to me, [email protected] . To get the book, go to www.lulu.com/joelorr.
is an author, consultant, and public speaker. He consults to Fortune 500 companies, high-tech startups, and government agencies on CAE issues. He is the founder of the League for Engineering Automation Productivity (LEAP) and has been an Autodesk Distinguished Fellow and the Bentley Engineering Laureate. A long-time Computer-Aided Engineering columnist, in the CAD/CAM monthly e-mail newsletter, Dr. Orr will continue with his reflections on all aspects of engineering. Contact him at [email protected] or visit his Web site: www.joelorr.com