Bad Matters Worse

The bigger and more complex object we try to describe, the more problems we have accurately doing so. So what happens when we try to describe something that doesn’t exist using words that don’t really exist? Sort of a meta-non-existence if you will.

For example, how about the word “software”? What comes to mind? I can’t show you a pound of software. I can’t hear running software like I can a running engine. I can’t feel software like the resistance of the keys as I type this sentence. About all software can be is mind stuff.

Since we’re using mind stuff (words) to describe mind stuff (software), can we expect to have anything but confusion?

Sliding Down the Slippery Slope

But that doesn’t keep us from trying. So we borrow words from other activities and use them. Words like “software engineering”. Mary Shaw’s original paper is titled “Prospects for an Engineering Discipline of Software” but somehow the “Prospects” got lost, and software engineering/engineers is/are everywhere.

The difficulty arises from the mental image created with the word engineering. Engineering disciplines have centuries of use, most prior to the mathematical models and physical understanding we now have. Engineers use standard repeatable techniques to build real world objects with specified characteristics in predictable time frames. If the time frame needs to change, it’s because of phenomena visible to all (such as it rained for 40 days and we can’t build while it’s raining).

This same mental image can’t apply to creating software since the field:

• is still young (less than 100 years).
• we’re still learning how to do what we do.
• there is no physical basis.

but we use it anyway.

Since we have the engineer mental image, it naturally follows that software projects should be managed using the same techniques as other engineering disciplines creating the next mental image, software project management. And how well has this worked? Take a quick peek at Kelly Waters’ post on Most IT projects fail. It doesn’t look good from here.

So Why Don’t We Change?

The first reason we don’t change is mind share. We have organizations like the Project Management Institute and the Software Engineering Institute proscribing how Things Should Be Done, and certifying those who pass certain criteria as PMP® or a certain CMMI® level. Disclaimer I am not anti PMI or SEI. All things have their place. But we’re dealing with meta-mind-stuff and management often confuses certification with both the ability to deliver the project and suitability of the certification to the actual problem at hand.

Another reason we don’t change involves inertia. In this case I compute inertia as:

inertia = mind share * time;

The equation’s time component involves how long we’ve thought this way, and a second order effect on mind share as people who believe this way get promoted to positions of management, then upper management.

The third model lock in involves cognitive dissonance. Data says the way we current run software projects isn’t working. But mind share tells us this is the way to run software projects. Common ways to resolve the cognitive dissonance include:

• Admitting it didn’t work, but we’ll try harder next time.
• Ignoring the project failure data (could this be why we don’t do a good job with metrics?).
• Chastising those lazy, incompetent programmers.
• (insert your favorite here).

Perhaps the greatest barrier to change revolves around the question “Who loses?” Change always comes from below. No one dealt four aces asks for a re-deal. Anonymous.

Guiding the Runaway Train

We need to be aware and accept that we’re working with the wrong analogy or metaphor. Software involves some aspects of engineering, but it also involves aspects of art. Rather than latch onto an existing mental model, we need to create a new one for dealing with meta-mind-stuff. We start doing this by changing the words we use to describe what we do, why we do it, and for whom we do it. The current counter position to “Command and Control” project management is “Agile”. Unfortunately this creates dichotomous thinking when we’re really dealing with a continuous spectrum of management options.

But what I’ve heard, read, and experienced, Agile (hereby defined by me for the rest of this entry as incremental/iterative software development) has a better chance of working since it uses a different management model. Rather than working with single pass logic, agile methods advocate breaking a project in several pieces, completing each piece in a fixed period of time. This would change a single 12 month project into 12 one month projects. This provides the following advantages:

• The customer gets value every month, starting with the most valuable parts first.
• The team can review and learn from the previous month’s work prior to starting the current month’s work.
• Plans can be adjusted monthly as new information becomes available.
• The person in charge (customer, product owner, whatever name you like) can see how the project progresses.

The section “Loops All The Way Down” in A Multi-use Model contains a simplified model depicting this. You could expand the Daily Standup/Team combination into feedback loops as well, one for each team member. The loops center around:

• What did I do yesterday? (feedback)
• What’s blocking me? (environmental information)
• What will I do today? (set point for tomorrow’s stand up)

This helps answer everyone’s primary concern: What’s In It For Me (WIIFM)?

• Developers can focus on immediate tangible results.
• Customers know every iteration how well the team understood what the customer wanted.
• The person in charge has progress visibility unparalleled in Command and Control environments.

The words we choose to use when we propose changing will determine how successfully we create the new software development reality.

So many books, so little time! When Steve recently recommended The Art of Problem Solving by Russell L. Ackoff, I promptly ordered it from my friends at Amazon. Originally published in 1978, this book retains its relevance. The book has two parts: The Art and Applications.

The Art section provided smiles and provoked thinking. For example, I’ve stated that a problem is the difference between what I have, and what I want. For Ackhoff, problems arise when a choice exists. No choice, no problem. Hmmm. And how about the three possible outcomes, solved, resolved, and dissolved? This section includes anecdotes from Ackoff’s experience which are summarized with “Morals” such as:

• The end of one problem may be the beginning of another.
• It is easy to blame others for our own mistakes, but it is hard to correct them doing so.
• There is nothing so deceptive as an apparent truth.

The Applications section contains case studies amplifying the Art section contents. Other than the chapter “On Keeping Problems Solved”, this section didn’t do much for me.

I recommend this book to anyone involved with systems thinking. It discusses fundamental ideas that will aid in better thinking, which can only improve systems thinking.

Got a good book to recommend? Add a comment or send an email.

Mind reading happens when we “know” what someone else thinks. In business and personal relationships this occurs all the time. “The boss is mad at John.” “Stacy doesn’t like what she’s doing.” We see and hear things, and often assume that others there make the same conclusions and feel the same way we do.

When we’re correct, it saves time and effort. In instances involving small teams that have a large shared background, it’s conceivable that “mind reading” correctly occurs more often than not.

When we’re wrong, bad things happen from delivering software the user doesn’t want to creating interpersonal problems. A two person team I’m part of (that’s been together almost 19 year) occasionally requires “un-wrinkling” after one or the other mind reads.

While designing an application several years ago, I suggested we contact the user and see what he wanted. I literally heard: “I’ve been doing this longer than [the user] has been alive. I know what he wants.”

This brings us to the handy Data Question: “What have you seen or heard that makes you think … ?“¹ I use this question to help me understand how I know, and to learn how others know what they know. This questions removes the layers of cognitive filters, values, beliefs and shifts back to the primary experience.

The Data Question tends to be used historically. Something went wrong, and I’m trying to understand where, and why. Moving the question closer to the primary experience helps prevent lost time, effort, and hurt feelings.
‘
The Data Question and questions like “What does this look like to you?”, “How will we know when we’re done?” help prevent mind reading and lead to happier clients.

So, what do you use so you “know what you know?” Add a comment or send me an email.

¹ I first heard the Data Question from Jerry Weinberg.

Recently I spent two weeks in Berkeley CA helping a client upgrade one of their control systems. I wasn’t involved in creating the original system, but I do have experience with the software. We reverse engineered and re-created the system. Testing went well until the fateful day we hit the wall.

The task is simple enough. The operator makes a selection, which sets a boolean value TRUE. The control computer detects the FALSE-to-TRUE transition, and sets a local variable to TRUE. Six seconds later, the operator’s value gets set to FALSE. The value in the control computer remains TRUE until other events occur that set the variable to FALSE.

This was the map I used until things didn’t work. The communication between the two computers wasn’t happening like it did with the original system. The original communication protocol worked synchronously. The new communication protocol works asynchronously. This didn’t matter for most actions, but did create problems with this particular code section. And while we could bend, fold, and mutilate everything on the operator’s computer, we couldn’t make any changes on the control computer. To make matters more interesting, the interface logic occasionally worked. So my map was sometimes correct, and sometimes wrong!

After a day of testing, re-coding, and testing again, we finally resolved the issue so the interface reliably worked. The actual code changes were simple. We spent the majority of the day deciding if the map was correct and the territory wrong, or the territory was correct and the map needed changing.

Maps make it easier for us to work with the real world (whatever that may be). Some detailed information gets removed, but if the structure is similar to the territory, the map is useful. The problem is deciding when and how to change maps.

1. Something happens (Event)
2. We sense what happens (Object)
3. We recognize what happens (Description)
4. We generate meanings for what happens (Inferences)

This pattern was first published in 1933 in Korzybski’s Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics. From these abstractions we create the parallel experience in our mind that allows us to recreate the experience. Here is a review of the abstracting process.

We get information from the “real world” via our senses: hearing, seeing, touching, tasting and smelling. As we experience our world, we tend to store the the event information in our memory in the same “sense” that we experienced. We can see what happened, we might hear a loved one’s voice, or feel the chill in the air. I found this instrument a fun way to determine my preferred sensory intake channel. You can link to more information about Modalities and Representational Systems from the page. There are only 12 questions, so I wonder about how “accurate” the results are.

Like the MBTI, this way of looking at people’s differences helps me understand myself more than tell me the “truth” about you.

What do you think? Drop me a note!

I arrived just before the rescue truck. The SUV lay on its side in the ditch. The VFD had already set up traffic control and fire suppression. Using standard rescue techniques and tools, “Mom” and the kids shortly walked out of the SUV. Other than needing to by a new vehicle, this story ends happily. But what happened? The Highway Patrol report will include some phrase like “too fast for existing conditions”. “Mom” has probably driven this road most of her life. It’s rained before while “Mom” was driving. But today the amount of rain, the wash over the road and her speed created a new context that “Mom” couldn’t cope with successfully.

Like this accident most “interesting events” happen because someone, somewhere, at sometime, loses track of the context. Context involves us and everything we’re connected to. “Involves us” includes our mental models, our world view, and our actions. We started changing at conception. We continue to change until after we die. Along the way, we grow, we learn, we change. Accidents happen when we change, but the “everything else” hasn’t. Learning may create an accident that leads to personal growth. Personal growth might make us uneasy with our current friends.

“Everything we’re connected to” is the environment we exist in. Our family, our friends, our career, our hobbies, everything with which we come in contact is in a state of flux. If our world view limits how we see things, we’ll create accidents by missing opportunities or reacting to things that aren’t there. If we hold to mental models that no longer apply to our current situation, we’ll be out of context when we act. Behaving like a 10 year old doesn’t work well now that I’m pushing 50.

We need to learn from accidents. Learn about ourselves, our context, how they interact, and how to keep them synchronized.

©2005 – 2009 Don Gray, Gerald M. Weinberg

“The thought that disaster is impossible often leads to an unthinkable disaster.” – The Titanic Effect, The Secrets of Consulting, pg 95

Engelbert, the Software Engineering VP, sat quietly in his office pondering the current state of UberDenke’s next UDCRM release. Slowly he had realized the release wasn’t going to ship on time. There were many more errors than he planned for, and over half of the code had not even reached the testing group.

The more he thought about it, the more he felt trapped. The more trapped he felt, the more he wanted out. The more he wanted out, the more he felt trapped. And around, and around his feelings traveled in a vicious circle of trapped and wanting out. But there wasn’t anyway out.

Or was there? Engelbert’s thinking and actions have trapped him in a reinforcing feedback loop. His feelings are creating an emotional downward spiral that will continue until some system limit is encountered. The system limit may be the when he finally admits to others the release won’t ship on time. Perhaps his health (mental or physical) may break first. Or maybe he’ll change jobs.

We can all sympathize with Engelbert’s plight, because at some time or another, we’ve all been caught like this–a trap artistically summarized by Jean Paul Sartre’s depressing play about three people trapped in Hell, No Exit.

Engelbert set up his own No Exit hell right from the beginning, because he, like Sartre’s victims, had no exit strategy. An exit strategy is a planned set of activities to initiate when one party suspects that a relationship isn’t working, activities that should prevent the situation from becoming a hellish trap.

Dynamic Basics – Getting Started

The no-exit dynamic generally begins when two (or more) parties agree to work jointly on some project. Sometimes the agreement is not explicit, as often happens when the work of one party depends on another party’s output. This joint work could stem from a voluntary relationship (such as co-authoring articles) or perhaps from a management mandated decision. In Engelbert’s case, his manager told him to use a new process to build the next generation of their software product.

The parties start merrily to work under the agreement, and all goes well for a while. Next, life happens.

Perhaps the person with whom you agreed to write an article falls ill, changes jobs, or takes time away from the joint project to deal with pressing family problems.

Perhaps the other team at work discovers the problem is more difficult to solve than anticipated. Possibly another higher priority project siphons manpower from their team.

Or perhaps the dynamic starts up when the levels of commitment and interest are unbalanced, or when there is a different understanding of the agreement.

Locking In

The first slip or two may not create a problem. We use explanations like these:

• It’s only happened one time. (Not noticing prior behavior on the part of either party).
• Things are bound to get better. (Seeing through rose colored glasses)
• I’ve made a commitment, so I’d better not say anything. (The team player problem)
• They’ve got a plausible story. (Just one more chance).
• I’ve already invested so much, a little more investment and I’ll have what I want. (Good money after bad)

Whatever the reason–and there are hundreds of variations–the slips soon become the norm, not the exception. Since the slips happen individually, separated by days or weeks, the cumulative effect isn’t noticed until it’s too late to do anything reasonable about the slips. The more we become accustomed to the slips, the more tolerant we become as new slips occur. It’s not that Engelbert is stupid. It’s just that he lacked foresight, or was too optimistic. If he had known when starting development that the project would slip several times, he could have planned differently.

Failing to take early action sets the precedent for continuing failure to act. Failing to act causes negative feelings to accumulate. The negative feelings are there from the first slip, but they are ignored or suppressed until the accumulated value becomes greater than we can tolerate. When we finally surface the negative feelings, we feel trapped by our previous actions. We’ve become locked in the reinforcing feedback loop of simultaneously wanting out and feeling trapped.

In this dynamic the system continues accumulating more negative feelings until the system experiences a catastrophic collapse. Engelbert may be fired, or quit, or get sick, or ship a system that drives his company out of business.

Setting up the Exit

So, what’s the solution? The first step to exiting the reinforcing feedback loop is to become congruent by balancing the factors of yourself, the other party or parties, and the context in which the dynamic is taking place. Most commonly, in this type of a feedback loop, the other becomes lost. As you try to cope with the situation, you start blaming the other person for the problem, and that only tightens the loop. Responding incongruently like this creates stress and does nothing to improve the situation or help find an exit from the loop.

Becoming congruent allows you to be centered in your actions. Being centered opens a range of responses you can use to change your view, each of which might break the trap. By changing your view of the situation, we can see possible interventions that will change the loop dynamics. Among such interventions are these:

• Changing how you see your contribution to the problem.
• Determining why you feel like you’re trapped.
• Obtaining a better understanding of what you heard during the “agreement” process.
• Bringing in a third party who adds a compensating loop. Sometimes you do this by just letting the loop escalate until someone else is affected, often by not trying so hard on your side. This is an example of:
• Doing the opposite of what you’ve been doing. This personally applies Marvin’s Fourth Great Secret, “If what they’ve been doing hasn’t solved the problem, tell them to do something else.” The Secret of Consulting, pg 41

Exiting the Loop

No self-reinforcing loop can last forever. Sooner or later, one way or the other, the loop will exit. If no action is taken, the reinforcing loop will continue its downward spiral until some other part of the system collapses:

• Personal health (mental / physical) will deteriorate until the exit happens. (This is breakdown of the self.)
• The interpersonal relationship will decay and animosity replaces the original camaraderie. (This is breakdown of the relationship with other.)
• A third party starts to be affected and intervenes. Of course, this is the result some people are hoping for (if we make enough noise, Mommy will stop the fight). But, you can also encourage it. (This is where the context intervenes.)

Another exit option is to become centered, congruent and work on changing the loop dynamics. The key here is to recognize the No Exit dynamic early, and take corrective action quickly. Your plans and strategies must be flexible. While the goal can be constant (exiting the loop), life continually changes, so fixed plans inevitably become obsolete or, even worse, counter-productive.

When the loop finally exits, there are several possible outcomes:

• An intervention works and the joint effort continues
• The “healthy” participant becomes “sick” and the effort ends due to lack of effort
• One person takes over the entire effort

This applies to multiple party systems (two or more). In addition to software development this could include:

• marriage and other long term interpersonal relationships
• business ventures
• article or book writing
• sports or other activities you are doing “for fun.”

An Ounce of Prevention

Next time, Engelbert should consider prevention interventions. Prevention interventions can be used to prevent the No Exit dynamic from happening in the first place. Or if it starts anyway, they provide an agreement among the parties as to how to handle it–if you like, a meta-agreement, or agreement on the limits of our agreement and what we’ll do when we reach them.

In a crisis, it’s much easier to stop and think if you have provided time in your plan for stopping to think. If you haven’t, one party will say, “Here you tell me that we’re behind schedule, but you’re adding this thinking-bit to the schedule. That doesn’t make sense.” With that easy dismissal, everyone quickly hurries back to their unproductive panic.

Examples of advance preparation of exit strategies include:

• Periodic check-ins
• Gate points where either party can exit the activity, if they’re not perfunctory so you can really exit at these points
• Better understanding and more explicit statement of each party’s expectations, along with a process by which expectations can be modified along with the plans that were based on them.

A well-designed system will set some limits at the beginning, limits that are not vulnerable to a buildup of tolerance.

Third Party Interventions

Most parents have learned some dos and don’ts about what to do when they witness such a no-exit loop. If you find yourself on the outside looking in, you might apply one of these principles:

• Know when to enter (never do unless you’re asked for help, though you can encourage the parties to ask you).
• Prevent damage (whatever that is) to others.
• Decide it’s not your problem and walk away, letting the nature of the no-exit loop take its course.
• Avoid creating addiction (co-dependent) dynamics.
• Avoid using fixes that accentuate the dynamics, unless you want to make it worse so it will crash more quickly or lead to enough pain that the parties will work out their own solution.
• Be careful not to prevent natural learning.
• Look for interventions that remove barriers and/or increase resource states.

Exit Levels

In deciding about intervening, choose which of three Exit Levels you’re seeking:

• First exit is when participants realize how much pain the feedback loop is causing and figure out a way to break out for themselves.
• The second exit is out of the situation (as when the parties concur that the agreement has failed). This may lead to a new agreement, or an exit agreement where they continue the relationship with each other.
• The third exit is where one party opts out of the system by ending the relationship.

Of course, the best exit is the one you have planned for before you ever get started. Unfortunately, there’s a prevalent romantic notion that real relationships shouldn’t need a pre-nuptial agreement. As Engelbert’s boss argues when he tries to set up some exit strategies before his next project, “Thinking of possible failure is negative thinking. It’s just that kind of thinking that guarantees we’re going to fail. Just like you did that last time.”

Of course, the last time, they had no such exit strategy, so their failure was much more costly and painful than it need have been. That’s The Titanic Effect: The thought that disaster is impossible often leads to an unthinkable disaster–”Why would we need lifeboats on an unsinkable ship?”

I’ll never forget that morning even though it happened a quarter of a century ago.   I was a programmer helping start up a new factory, and things had been going OK.  Not great, but OK.  I decided that morning on the way to the factory I was going to stay calm and not let anyone “get to me”.  Right.

Karla, the process engineer descended with a litany of things that were wrong before I completely cleared the door into the control room.  Before Karla could finish, the control room operators started interrupting with needs that had to be addressed before we could start the day’s trial production.  Did I lose my implacable calm?  Faster than a snow ball melts in North Carolina on the Fourth of July.

What I didn’t understand at the time is that models governed my behavior.  Unlike the models we were using to create the control software, these models were hidden from my view.  Later in my career I started finding the tools that would help expose these implicit models, and help me make changes that would amplify my effectiveness.

Manifest Models

Modeling is an integral part of our daily lives and is the way by which we transform the chaotic into the structured. – Kostere, Malatesta

“Modeling” is the name we give to the activity of organizing events into patterns, and patterns into structures.  These structures are referred to as “models”.

Some models are based on our physical environment.  The model we use for time is based on the earth’s motion in space.  We call a day one rotation on its axis.  A year is one revolution of the earth around the sun. Sir Isaac Newton defined four laws which model motion in the 17^th century that remain largely intact today.

Using instruments, we measure the events that form the basis of physical models.  As we improve our instruments, we improve our understanding of events, then patterns of events, then what pattern changes mean to the overall model.  We soon discover that models that adequately describe events at one level, fail at some other level and need to be replaced.  For instance, at a given level we replace the certainty of Newton with the un-certainty of Heisenberg.

Models to automate manufacturing processes or describe work as it flows through an organization are explicitly built.  I worked on a project where the engineering firm built a scale model of the electrical cogeneration plant, complete with all the pipes 2” and larger.  This model was used in the bidding, construction, and final acceptance of the plant.  A different r project didn’t correctly model the sample flow through the Quality Laboratory.  Actions were occurring at the wrong time or location for where the samples were in the analytical process.  The project was a disaster until the software model was corrected to reflect the physical process.

Environmental and expressly built models are manifest models.  We build these models by observing events, noticing patterns, and organizing the patterns into models.  While a model should account for what has happened, the real power of a model is its ability to predict what will happen given a set of input conditions.  A model’s prediction ability is based on how well it corresponds to its domain, and its ability to deal with the inputs.

We can play “what if” games.  The results of the “what if” games then feed back into our model definition.  We can examine the events to verify we understand them correctly.  Maybe the model needs adjustments.

Another reason to study manifest models is we use the same actions to create implicit models.  Unlike manifest models, we don’t explicitly build implicit models.  Yet understanding our implicit models provides the opportunities for personal growth, improved inter-personal relationships, and the leverage for creating new realities.

Implicit Models

We start building implicit models when we’re born. Take the example of disappointed child and harried parent at the grocery store.  The child wails and screams.  The parent unwilling to deal with a “scene” acquiesces to the child and gives the child get what they want. After this happens a few times, pattern forms, and eventually a model of “If I scream and yell, I get what I want.”  Now imagine this child as a manager who’s project is late, bug ridden, and over budget.  Quess how the manager might respond to the situation?

Like manifest models, implicit models organize our experience.  These models guide our behavior. Our new experiences tend to validate the system which in turn is used to predict the result of future experiences, which in turn validates, which in turn predicts …  The difference between manifest and implicit models is we are generally not aware of implicit models.

This suggests that we take actions, have interpersonal relationships, and interact with our reality in an “auto-pilot” mode.  This is not necessarily bad.  In today’s world, it is not possible to deal with every datum, examine every event, and ponder each interaction.  Using models allows us to respond with appropriate behavior without the need of exploring all the possibilities available.

While generating behavior that is appropriate, implicit models limit our available responses for a given event.  Input events similar to previous evetns will be filtered, processed, and responded to without regard to changes in the experience, changes in ourselves, or changes in the environment.  Failing to take these changes into account can create inappropriate behavior and inter-personal interactions that are out of balance.

In extreme cases, implicit models exist as “survival rules” or self-fulfilling prophecies.  When these models exist, our behavior becomes incongruent.  Valid input is ignored. Our actions are single minded, and the results of our actions are the opposite of what we actually would like to have happen.

How do we build these models we use to interface with the rest of the world?

Building Models²

Model – a small copy or imitation of an existing object. Webster’s New World Dictionary

We abstract our experience and condense it into a models.  The models are simpler than our experience.  This reduces the data we need to process.  Properly created models are useful for ordering information, understanding events and predicting the future.

There are four basic modeling methods:

1. Deletion
2. Construction
3. Distortion
4. Generalization

Deletion leaves information out of the model.  If we don’t remove some of the information, we’re doing all the processing and work, which defeats the purpose of creating models.  We delete information based on our interests, energy level and experience.

Construction is deletion’s compliment.  We put information into our model that wasn’t in the original experience. I once spent an afternoon with a tool that was smart enough to tell me I was doing something wrong, but not smart enough to tell me what.  It turned out the problem was a loop index declared as [_i], but used in the code as [i].  I was glad to find it, even though I wasn’t sure if my problem was mentally deleting the “_” in the declaration, or adding the “_” to the code.

Distortion is blending experiences, (de)emphasizing some parts, or otherwise altering the original experience. Distortion is the basis of creativity as well as paranoia.¹

Generalization is creating a model from one experience and using it to represent an entire group of similar experiences. The potential problem is the single instance may not be truly representative of the entire group.

So how do we interact with our world, process the experiences, and end up with implicit models?  The process involves input filters, abstracting, and interacting with our environment.

Getting the Experience

… there is an irreducible difference between the world and our experience of it.  We as human beings do not operate directly on the world.  Each of us creates a representation of the world in which we live that is, we create a map or model which we use to generate our behavior. Our representation of the world determines to a large degree what our experience of the world will be, how we will perceive the world, what choices we will see available to us as we live in the world. Bandler and Grinder, The Structure of Magic.

Input Filters³

I know you think you understand what I said, but I’m not sure you understand that what you heard is not what I meant. – Anon.

Let’s agree there is a physical world.  We can touch, see, hear, smell, and taste things in this world.  These senses, which can be very developed, have limits.  We only see the “white light” part of the electromagnetic spectrum.  Infrared and ultra-violet are beyond our visual limits.  Our hearing is limited to 20 – 20,000 Hz.  Many animals, including Sarah (my German Shepard) can detect sound beyond this frequency range.  So the first type of input filters is neurological based.  These filters, are common to Homo sapiens, and start the process of permuting the physical world into a map (or model) of the physical world.

In addition to existing in a physical world, we exist in a social world.  Initially our biological family comprises this world. As we get older, our social world expands to include playmates, classroom friends, and work relationships.  During this socialization process, we learn language, accepted ways of perceiving, and other socially agreed upon “truths”.  Language modifies our world mental model based on how we abstract from the sensory experience. Common “truths” might include:

• Boys are better at math.
• Girls are better at cooking.
• Programmers are introverts.

These social filters move our mental models further from the physical world.  They are common not to all homosapiens, but to a group of homosapiens.  Unlike neurological filters that are essentially unchangeable, social filters are learned, new filters can be learned, and old filters can be “un”-learned.

Neurological filters define us as a species.  Social filters define us as a culture.  Our personal history defines us uniquely, and moves our mental model furthest from the physical world.  None of us has the exact same set of experiences. Therefore none of us has exactly the same mental world model.  The model differences are based on our interests, habits, likes, dislikes, and rules for behavior.  Like social filters, we have the ability to change these parts of our models.

Levels of Abstraction

A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. – A. Korzybski, Science & Sanity, 5^th Ed., p 58

Perhaps the most profound cause of differences in our mental models comes from how we abstract information from the physical world.  Korzybski identifies “at least three different levels of abstractions: the seen, experienced, lower order abstractions (un-speakable); then the descriptive level, and finally, the inferential levels.”⁴ It is in the third order abstraction (inferential levels) area that individual characteristics have the most impact.  Even though two people see the same event in the physical world, by the time the final abstracting is complete, the mental model of the event may be completely different.

Another way of viewing the abstraction process is looking at the modeling levels that separate us from the physical world.³ Our sensory experiences, how we individually experience the sensory experience (apply our likes, dislikes, etc), and what expressions are available in our language all affect our mental world model.

Each of these levels is meta- to the modeling level that is the next level below it.  Without careful inspection of the nature, assumptions and structure of each level, differences between the physical world and our implicit models of that world aggregate and compound.

Language
Experience of ExperienceSensory
Experience
Physical World

By the time we talk about an experience, we’re three levels of filtering and abstracting from the actual experience.  Some useful techniques to help untangle confusion are the Satir Interaction Model⁵ and the Inference Ladder⁶.

Interacting With Our Environment

Our interaction with our environment is not a one-way conduit.  Our models are built by abstracting information from the environment using modeling methods.  These models then form our reality, which is the basis for our actions.  Our actions in turn affect our environment.  This in turn affects our models.  The feedback between our models and our environment can either reinforce (agree with) or balance (disagree with) our mental models.  The selection between reinforcing and balancing feedback is determined by how we choose to view the feedback.

Extra special events can have an impact on our mental models.  I once gave a presentation that received less than glowing reviews.  As I considered the event, how much significance did I place in the data?  Was it a statistical “blip” that could be safely ignored?  If so, I could keep my model of my presentation as “sterling” and reinforce the model by discounting the input.  Or I could choose to accept the input as valid and modify at least the presentation, if not my delivery style.  Of course, I could choose to modify both.

The risk in using special events (or data) to build or modify models is the tendency towards using construction, and creating a model that doesn’t fit the general class that the event belongs to.  This can be avoided by looking at the events (or data) over time.  This allows a series of events to regress towards their normal value.

Looking at events over time allows us to consider the time frame.  We learn about simple cause and effect in school. In the interests of finishing the labs on time, cause and effect are usually closely coupled in time.  For some systems this is a valid time frame.  Other systems, especially systems with large numbers of people, the time between cause and effect can be quite long.  Consider when events happen, and whether or not that makes sense if you decide to use them to modify your mental models.

Another trap in acquiring information from our environment is one-sided events.  This is gathering input in such a way that no matter what happens, it results in reinforcing our mental models.  This would be like the person who “misbehaves” in meetings to get attention.  When considering using an event, ask yourself, “Does this event reinforce my mental model?”, and then “Does the opposite of this event also support my mental model?”  If both answers are yes, you are taking a single view of the event.

It usually takes some kind of a crisis to point out that a model is not working. If we continue to use a model that is no longer working, we create incongruent interactions.  We do or say things that create negative feelings between us and the people we’re interacting with, or generate the opposite results of what we really want.  These negative and opposite reactions eventually result in crisisses of varying magnitudes.  As Jerry Weinberg says, “A crisis is simply the end of an illusion.”

Explicitly Building Implicit Models

“We want a set of mental models that are realistic and useful, and provide ourselves and others with the greatest possible happiness and well-being. We can do this by looking dispassionately at our mental models, seeing them as a system and choosing what models to adopt, rather than holding those we already have regardless.” – O’Connor & McDermott

Coming to the end of an illusion offers us a chance to reconsider the events, reorganize the patterns, and reconstruct our models to generate a different outcome.  To do this, we need to be aware of the models we use, and how we would like to change existing models or add new ones.

Identifying Models in Action

There are at least three ways to determine when a non-working model is in action:

1. Incongruent interpersonal actions.  This is the domain of dysfunctional groups such as software development teams, and dysfunction between groups (development and testing).  While in theory all are striving to the same goal, blaming, placating, and super-reasonable acts are the avenue of action.
2. Incongruent intrapersonal feelings.  These are the “I’ll just sit here and quietly stew” feelings.  Coming home from a recent trip, my mental model of when to stop for gas didn’t agree with the driver’s.  I just sat there quietly stewing.
3. Language⁷

• Judgments are authoritative statements about second order reality, the world of meaning, not physical fact.
• Absolute words such as “ought”, “should”, “must”, and “cannot”.
• Universal words such “all”, “every”, “never”.

When you notice these events (or words), you can be sure mental models are in play, and have a choice to accept or to change your mental models.

Modifying Mental Models

Our mental models originally made our lives better.  They helped organize information, allowed us to explain events, and predict the future results.  Therefore the first action to take is to ask yourself, “What does this model get me?”  Once you understand the plus side, you can determine if you want to change your mental model.

If you decide that you would like a different outcome than what your current model is providing, continue by determining what sort of an outcome you would like to have. Outcomes should be a positive statement.  “Being more centered in my relationships ” is an positive outcome that can be expressed in terms of feelings.  “Not fighting with my team-mates” is a negative expression. Progress for (not) negative goals is more difficult to verify.  Perhaps you can find an outcome that keeps the benefits of the current model and add the benefits of the new model.

Once a new outcome is chosen, destabilize the current model.  If incongruence helped identify the model, the energy created may be enough to start the migration to the new model.  You can use questions to help with the change.  Question your assumptions about the model, the meaning of the model, or for what else you might be able to use the new model.

Once you’ve started the movement toward a new model, be sure to check the environment for feedback.  As you stay aware of regression, time-focus and one-sided events, consider how you use the feedback to reinforce or balance the new model.  Our models for a system, and we can modify this system to create more fulfilled lives.

¹ The Art of Systems Thinking, Joseph O’Connor & Ian McDermott ©1997, pg 69
² This section draws on The Structure of Magic, Bandler and Grinder, ©1975  pp 8 – 13 Experience As An Active Process
³ Maps, Models, and the Structure of Reality, Kim Kostere, Linda Malatesta ©1990,  pp 6 – 13
⁴ In Science And Sanity (5^th Ed.), Alfred Korzybski, ©1994, pg 444
⁵For an excellent presentation on the Satir Interaction Model see Quality Software Management, Vol 2, First Order Measurement by Jerry Weinberg.
⁶ The Fifth Discipline Fieldbook, Peter Senge et al., ©1994, pg 242
⁷ The Art of Systems Thinking, op cit pg 106

from The Art of Systems Thinking

How to have Rigid, Limiting Mental Models

1.   Insist that your ideas are how reality ‘really’ is.
2.   Have a narrow set of interests to ensure you delete a lot of experiences.
3.  Do not tolerate ambiguity; jump to conclusions as fast as possible.
4.  Whenever people and events do not behave as you expect, have a fund of creative explanations.
5.  Use lots of modal operators and never question them.
6.  Use many universals and do not admit exceptions.
7.  Be quick to generalize from one example.
8.  Set up plenty of one-sided, unfocused experiences to provide evidence for your ideas.
9.  Blame failures on individuals (don’t forget yourself).
10.  Think in straight lines of cause and effect.
11. Never by curious.
12. Never update your beliefs in the light of experience.

How to have Systemic Mental Models

1.   Admit your mental models are your best guess at the moment and be on the lookout for better ones.
2.   Have wide interests.
3.  Be comfortable with ambiguity.
4.  Be curious about, and pay particular attention to, experiences that seem to contradict your mental models.
5.  Have a wide time horizon to look for feedback.
6.  When confronted with a problem, look at the assumptions you are making about the situation as well as the situation itself.
7.  Look for relationships, how events fit together.
8.  Look for loops and circles of cause and effect, the effect of one cause being the cause of another effect.