Saturday, April 26, 2008

Understanding vs. Procedure

I was an early adopter of broadband home internet. The first service that became available in my area was DSL and, at the beginning, it wasn't very reliable. The situation was complicated by the fact that I didn't have the standard configuration at the time. DSL was being sold as a way to connect your home computer (singular) to the internet. I was running a network of several computers behind my broadband connection.

Often, the service would go down. When it did, I would first make sure that the network and equipment were working on my side. Once I knew the problem was on the phone company side, I would call. The first level support personnel would run me through a checklist. These checklists assumed the standard, single computer configuration and were designed to rule out problems on my end. On my first calls, I tried to explain my situation and what I had done to diagnose the problem. This served no purpose. Often they asked me to do something that was inapplicable to my configuration. I would say things like "Let's pretend I've done that. What is the next step? " The first level support at that time could not affect anything in the phone company. If the scripted procedures failed, you were directed to second level support. Second level support had people who could get information about your actual connection and do some simple reconfiguration. On one occasion I got to a third level when the problem was failed hardware in a phone company facility.

At any given level in this hierarchy, there were standard procedures (ask this question, if the response is ...). The people who created the procedures understood the working of the system at that level and how to diagnose problems. That knowledge was codified into the procedures that could be followed by people who did not understand either the system or its failures. At each level the procedures were designed to attack particular problems. Presumably the first level support solved the most common problems, most of which had nothing to do with the phone company. The second level diagnosed less common problems where there were simple connection problems. The third level was reserved for more rare occurrences.

The introduction of procedures serves several functions. It codifies the most effective way to approach a particular problem. It also reduces the amount of thought necessary to perform the task, making it easier to find people who can perform it. Sometimes systems are so complex that a single person cannot understand the whole. Even in simpler systems, procedures allow people to concentrate all their energy on a particular part without having to understand all the relationships to other parts.

All of us reduce understanding to procedure. Consider a grocery list for dinner. I want salad, so put down greens, mushrooms, onion ... At the grocery store I do not have to consider the process of making the salad (though I may double check and modify based on what is available). The part of the process that is important in the store is buying the material. I can simply get the items on the list and be assured of success. In effect, I do the up front work of preparing the list (procedure) at a time and place where I can adequately consider the question, then I delegate the task to a less capable me who is distracted by the people and things in the grocery store.

In business, less skilled generally means cheaper. This drives a movement toward procedure instead of understanding. Because simple procedures require less thought and attention than complex procedures, the tendency is to make procedures as simple as possible. Forty years ago grocery store clerks had to type in every price and were expected to know the current price of all produce. By printing machine readable product identifiers on each item and computerizing the association between product and price, the clerks job has been reduced to scanning items and either remembering or looking up produce codes. The procedures have become simple enough so that customers are now doing it themselves.

A side effect of this tendency is that understanding is concentrated in fewer and fewer people. This is one of the drivers for the increasing income rift in the United States. A more fantastic danger was explored by Robert Heinlein in his Foundation Trilogy where people with understanding virtually vanished from a technological society. An actual example occurred in Cambodia where the Khmer Rouge killed the educated and were left with no one who could run or repair a water system. For the world as a whole, this is not likely to become a problem. The large population and increased wages attached to specialized understanding assures a continuous supply of the educated.

A more mundane and common side effect of reduction of understanding to procedure is nonsense. Some time ago I had the opportunity to examine, in detail, ordering and payment procedures at a number of companies. In broad outlines, the problem is clear. Someone in the company needs something. This could be a pencil or could be raw materials for a manufacturing process. The product is purchased from someplace, it arrives, is delivered internally, and paid for. In a large company this involves a number of independent areas. These include the person or department that needs the item, a procurement department, accounting, and receiving. Pretty universally, no one understood the whole process in detail. They simply followed the appropriate procedures. Over time, business needs change. When some department found the procedures no longer worked properly, they would force a change to fix their problem. Because systemic changes require coordination and approval, they are avoided by sensible people. All of the processes studied ended up with nonsensical procedures and supporting material.

If understanding can produce procedure, can procedure produce understanding? I think the answer is yes, but only understanding of the area covered by the procedure. From the first level support questions used by the phone company, it should be possible to induce a model of the home network connections to the phone company. From the second level procedures it should be possible to induce a model of the connection itself. More global understanding requires more global study.

Lest anyone feel smug about human (or their own) understanding, I have a simple contention. There is no single person who understands, in detail, what happens between when you type a letter on your keyboard and that letter appears in your word processor. There are people who understand key codes and processor interrupts. There are people who understand word processors and the mapping of characters to glyphs. There are few people who understand both of those, and there are many other layers in between (process swapping in the operating system, control of graphics devices ...).

5 comments:

sf said...

I think the "procedures" for imparting education at any level
meant as training ground for employment often discourage understanding. It is too much of a hassle to try to explain for the explainers, too much of a hassle to truly understand for the learner.
I am often guilty of taking the easy way out. Take technology. Usually, I'm in a hurry and just want to know the formula to get something to work.
In an ideal world, I would really want to understand the concept, knowing that gives me what I really need - learning to fish as opposed to being handed one on a circuit platter.
sarah

Silver Gerety said...

I think you might like this book:

Essence of Decision: Explaining the Cuban Missile Crisis - Graham Allison and Philip Zelikow

Masasa said...

Also interesting from the system in which I work, the dynamic human system of a congregation.

I like your description of levels in procedure that go from very, very specialized to more global understanding (and I relate to this, as I too have been dealing with an inefficient phone company system that inevitably, when I call, wastes my time at lower levels that often are inapplicable to my situation before I am finally brought to the second or third level, the third usually involving someone with global knowledge coming to my home and doing things we could have done via the phone if I was speakingon the phone in the first place with someone who had global knowledge-- end of rant).

In my previous congregation, there was only one administrative staff person. Actually, two if you count the bookeeper. But for those tasks beyond the specialized financial end of things, this single administrative staff person was able to collect a very global perspective. Adding to her advantage, she had the global perspective of being a church member, someone who was interested in our ministry as a whole, and someone who kept herself in touch with the latest developments in organizational dynamics, systems theories, and so forth.

Her contributions to our team went beyond tasks and into the realm of making efficient change possible as needed.

In my new congregation, there are two administrative staff people (three if you count the bookeeper). Here, all administrative issues are divided into two levels of procedural tasks.

In this system, I am frequently treated by the administrative staff like I have a third head because I am frequently finding myself responding to procedural "nonsense." You describe it well here:

"Over time, business needs change. When some department found the procedures no longer worked properly, they would force a change to fix their problem. Because systemic changes require coordination and approval, they are avoided by sensible people. All of the processes studied ended up with nonsensical procedures and supporting material."

Another side effect can be noted. It complicates my life as a person whose thinking must be global because it requires an additional level of specialization on my part. I need to break down all my administrative business into two columns of tasks: each cared for by a different administrative staff person. When I bring it to one or the other, rather than passing information back and forth between each other as needed, they frequently bring it back to me and ask me to divide it up for them because they don't have the understanding of the ministry as a whole to divide it up themselves.

Here, I think inter-system communication is at fault. The specialists could remain specialists but have a global sensibility if there was greater all-staff communication. If we sat down for a monthly or twice monthly staff meeting, and actually had to hear what others were up to in our work, we'd be able to apply more global understanding to procedural specialities.

Masasa said...

P.S. Silver, it would be great to see you start blogging again!

Lynnet said...

As you point out, one reason for procedures is so that lower-skilled (lower-paid) people can be hired to answer the phone or email, and this does make some kind of sense, since "is it plugged in?" is probably the most frequently-useful suggestion.

But too often, this protocol ends up wasting a lot of time for both customer and service staff, and causing an understandable level of frustration if not outright anger on the part of the customer whose intelligence is being insulted.

It can be worse if the service person on the phone barely speaks basic English, or uses a headset that makes their words incomprehensible, or talks so fast that the customer is forced to ask them to repeat every sentence.

There needs to be some kind of compromise between efficient (cheap) service and a basic level of respect for the customer and their time. All too often the compromise is toward cheap. It is a sign that many companies do not want to spend ANY time training their personnel, indicating lack of respect for customer and personnel alike.

One of my pet peeves is the automated message that croons "Your call is VERY important to us" over and over again during a 30 to 45 minute wait on hold. Well, if my call was important to you, you'd hire enough staff to cover the workload....

But, back to your central theme, computers make it possible, and even easy, to continue the most baroque and inefficient methods of handling complicated procedures, and make it difficult and expensive to improve procedures for the benefit of all involved. The designers who understood the system when it was written are probably long gone, and nobody else understands it, or is ever likely to. Sometimes the best solution is just to chuck it and start over, but it's hard for management to justify the expense.

It's difficult to see a solution to this lack of understanding. Entropy keeps increasing, even (or especially) in software, so software systems get bigger and weirder all the time. All that saves us is that the hardware is getting faster fast enough to keep up (though maybe not with MS Vista).