Home

News

Syllabus Online Textbook About Us Link Search

Are Problems Solvable?

   Problems are results we don't like. However, what causes the results? We obviously can't "solve" a problem by running time back and changing the circumstances that produced the undesirable result. This fact logically implies that only can we change the effects of the problem, or we wish to avoid a similar result from happening in the future. Either way "solve the problem" means that we act to modify the likely outcomes in the future. We become  "managers." Our solution rests on the kind of process that produced the undesirable result.

    "Problem solving" is a highly valued skill, and many people are proficient in certain kinds of systems. Usually, they typically gain this reputation when the solution is within a relatively simple subsystem of a larger complex system. Consider a familiar scenario. We want some money from our checking account. This is a problem. We go to the ATM, insert our card and PIN, punch the appropriate buttons and we get some cash. The machine solved our problem. If the machine malfunctions and indicates that we are an unknown account, we go to a human teller, and they perform some routine checks that the ATM cannot perform, but this takes a bit more time before we get our cash. The teller can solve more complex problems, but the effort requires a small amount of additional time. If the teller finds we have insufficient funds, we borrow some money to get some cash. The teller refers us to a loan officer who will perform more complex checks, present the request to a loan committee which considers the request with respect to the intended use of the money and our projected ability to repay it, then passes judgment whether we will be awarded the loan, and, finally, whether we eventually will get the cash, or not. This is more complex, and takes much more time. There is something like a geometrically increasing amount of time and information required as the complexity increases incrementally.

    Each banking subsystem becomes more complex, adding increasing possibilities of significant delays before we get our "problem" solved. In the meantime, our need for a solution may change. Transmitting this additional information into the system, modifying the relationships in the complex system that has the solution to our problem is likely to slow the progress even further. Furthermore, we have certain time limits within which the problem needs to be solved. A bureaucracy is not designed to cope with rapidly changing needs. If the problem doesn't fit the decision channels (responsibility and authority) and give the correct responses at the checkpoints, a solution is progressively less likely to emerge. 

The banking system has been organized to perform certain functions well, provided we are presenting to this system problems that it is designed to to solve. Deviations from this system result in a rejection by the system, unless an unusual employee is willing to step outside and use personal judgment to act on our behalf. These people address complexity by taking personal responsibility to decide with unique criteria, rather than rely on "the rules." Often we find individuals that function "strictly by the book." They are unable or unwilling to function otherwise. It is "safe" to hide behind the rules in the book, which keeps them from "making mistakes" in the "game" defined by the rules. In such a narrow context, their decisions produce dependable results, but not necessarily solutions. If they are promoted by dependability, they will have risen in the system, but eventually the criterion changes to decisions that are "beneficial" in uncommon events. A bureaucracy values dependability since it is usually designed to be predictable, rather than innovative. Such people are promoted until there is a limit based on inability to be creative, or adaptive, and create solutions for the unexpected situation. They rise beyond their limit for competent to be creative and produce appropriate, unusual action. They are examples of how "Peter's Principle" works in bureaucracies. The bank represents a subsystem of our society, which is a subsystem of our species, which is a subsystem of our ecosystem. Compared to managing natural resources, banking involves problems in a more predictable system -- less complex, more manageable by rules.

    An ecosystem is better designed than bureaucracies for solving complex problems. A "Peter's Principle" individual in ecosystems becomes "dinner" and is consumed rather than becoming entrenched in a job beyond their level of competency. In a bureaucracy, they are protected from accountability until retirement or death from "natural causes." (Rarely do disgruntled customers or clients of a bureaucracy insist on functional accountability.) In an ecosystem the other organisms would exercise the "natural" accountability option -- kill and eat the bureaucrat. 

    Problems in natural resource management are often addressed as if they were problems for a bureaucracy. As a society we seem to believe that solutions require more technology, labor and expenditure of money, instead of creativity in unusual situations. Typically the bureaucratic approach creates more problems than are solved, disrupts the ecosystem's organization, and causes the loss of many ecosystem services that we use without recognizing them. 

    For ecosystem management -- natural resource management -- problems are best viewed as symptoms, and the solutions will come automatically when we understand the system conditions that underlie their appearance and place them in some coordinated mutual interrelationship. Effectiveness is measured as much by the nature of new problems that arise from an action as by the reduction in the problem treated. The effective manager uses less effort, but well directed "nudges" that allow the ecosystem functions to respond as they are organized. Problematic symptoms may disappear more slowly, but new problems are less intense and require only small managerial input to maintain a good system.

Last modified 01/19/05


©Obtain Permission. 
Last modified 11/25/2008