Sunday, June 03, 2007

Afterthought on feedback - for advanced students



(NOTE - This post is a continuation of an earlier post (Third kind of feedback discovered!) ,which is the next one DOWN below this one, due to the way weblogs post things.)

Now, I really have to confess that I over-simplified the design pattern that Nature uses a little. Just a little. What Nature actually uses is a whole nested set of ever larger control loops built on top of ever smaller control loops, stretching out of sight both upwards and downwards in scale. It's like that great scene in the 1954 classic sci fi movie "Forbidden Planet" where Leslie Nielson (then a serious actor) goes underground into the Krull city and looks up and down the levels of the "machine" that is running the planet and God knows what else.

So, think about diabetes "control" a little with me. Individual cells in the pancreas have jobs to do, generating insulin on command, and try to meet their production quotas, varying what they do based on information coming around their control loop of "more" or "less". -- like the hand on the spigot. Then, the whole pancreas has a job to do and decides "more or less" based on feedback from outside. Then, the whole endocrine system has a job to do and controls it based on feedback from outside. Then the human being has a life to lead, and modifies his eating and exercise based on feedback. Then the support-team has group feedback and modifies what they do based on that loop. Then the whole medical world monitors whether the recommended strategy works, and modifies what it recommends based on that, in a continuous control loop. Then, the society monitors whether the medical world is worth listening to or not, based on feedback of whether the advice given works in practice or not. Then, the economy goes up or down based on the health of the people and whether they control their diseases or not, in a continuous self-reflective loop.

As human beings, we are always in the middle of this hierarchy of control loops that stretch upwards and downwards. At a minimum, every level is trying to survive, which means fight off change, which means having a goal of stability and "normalcy" that it tries to bring itself back to after it has been "disturbed" by some outside event.

This is a very powerful mental model. This picture makes it "obvious" that if you take one person and try to change them, then let go, the next thing that will happen is that the next larger context and control loop will detect a departure from previous "normality" and try to push the person back to their old behavior and, being larger and more persistent than the person, will usually win.

So, it does little good to change "one person" in the doctor's office, then send them back to the old world of buddies and old ways of doing things, where they'll simply revert to their old behaviors.

The Institute of Medicine, in Crossing the Quality Chasm, has seen this phenomenon enough in the context of trying to change the behavior of a doctor (not a patient), that it recommended trying to focus on changing entire small teams ("microsystems") instead of trying to change one individual.

Well, from the many-level model, we can see that changing the team will help the individual maintain a new way of doing things, but now we've shifted the problem upwards one level, and need to zoom out our lens and see that we've only shifted the problem UP one level. Now, the "TEAM", surrounded by unchanged other peer-group TEAMS, will be caught up in a restoring force to normalcy and the old way of doing things -- so, we bought some time, but the change will get undone if we just let it go and stand back.

Well, what if we change all the TEAMS in a Department? Again, we buy some time and shift the problem up one more scale level, where the other departments' control loops will come along later and push back.

Etc. The shape of the beast we're trying to change is the whole hierarchy of life, even when we're trying to change the behavior of just one person, even if that person is us.

Anyway -- look forward to coming posts on:

What kind of behaviors SINGLE control-loops exhibit all the time. (Issues of stability,
reliability, "ringing", over-shooting the goal, speed of reaching the goal, agility, response time, stability under components degrading or failing, etc.) These are much of the substance of the first few chapters of "control system engineering" textbooks.

Then, what kind of behaviors and failure modes a nested hierarchy of control loops should have. If we hit it with a hammer, what would the ringing sound like?

Then, the fun stuff. If we find ourselves living inside such a nested hierarchy of control loops, and we want to make a change, what can we say with confidence won't work or might work or should work, based on theory -- and if we go look at what's actually happening, do we see that? How close to reality is this model?

Then, how does one "tune" this kind of engine, when it's mis-firing? Where do we stick the probes, what do we measure, what engine-computer do we feed that into, and what sort of advice for making changes would we expect to get back?

And then, of course, implementation. For our own life and our own company, what does this model suggest we should look at, and how do we need to push to stabilize the instabilities and to resolve the dysfunctions so that the engine stops backfiring and starts purring -- and we can DRIVE The BMW instead of continually tinkering with the engine.

(photos from Forbidden Planet lifted from this website. And, I agree, the move is not much fun to watch anymore because so much has improved since then - but it was a blockbuster when it came out and mesmerized all of us kids who dreamed of growing up to be like Leslie Nielson. Well, hmm... I still like the idea of having a starship. )

No comments: