Apparently, plenty. The software found one what it called “major” problem and dozens of minor ones. My system was “moderately fragmented,” which meant that the computer had to search through the disk to find different parts of a single file, an inefficient process. No problem—that’s what maintenance programs are for. It fixed the errors, defragmented my hard disk, and I was back in business.

What I didn’t anticipate was the radical improvement in the computer’s performance after I had done this housekeeping. It blazed! Programs launched in the wink of an eye, graphic-heavy web sites loaded in an instant. As I witnessed these feats, I was reminded of my amazement at how speedy the processor was when I first plugged the computer in.

The question that puzzled me was, why didn’t I notice the computer’s performance had degraded so much? After thinking it through, I concluded that, little by little, I had shifted my expectations. The decline had been gradual, and performance was still within acceptable limits, so I easily adapted to the slower access and load times. However, if I had continued to put off the maintenance process, the computer would have eventually crashed, which certainly would have gotten my attention and caused untold difficulties.

In this case, the consequences were reversible—I was quickly able to fix the system so that it ran as efficiently as ever. But when this dynamic occurs in other situations, it can be more difficult to diagnose and the results can be more damaging.

Lowering Performance Goals

In systems thinking terms, I had experienced an example of the “Drifting Goals” systems archetype. Systems archetypes are common patterns of behavior that occur in all kinds of settings. “Drifting Goals” involves lowering our performance goals rather than

Check-ups or maintenance programs use objective measures of a system’s performance to periodically diagnose problems that might not be apparent to someone on the inside.

taking corrective actions. Sometimes we do so because these actions are undesirable, as in the case of cutting expenses in order to reach profit goals. Sometimes we’re focused on other factors that seem more important; for example, we may be so caught up with efforts to boost sales that we fail to notice that quality has slipped. And sometimes, as I experienced with my computer, because our senses aren’t attuned to gradual changes over time, we just don’t notice that performance has degraded.

The parable of the “boiled frog” is often cited as an example of the “Drifting Goals” dynamic. According to the story, if you toss a frog into a pot of boiling water, it will immediately try to jump out. On the other hand, if you put it in cold water and then gradually raise the temperature, the frog will happily swim around until it—there’s no delicate way to put this—cooks. The frog’s survival instincts are geared toward detecting sudden changes, not incremental ones. Although this fable has been questioned by scientists, it vividly illustrates what I experienced with my computer —I likely would have noticed an abrupt decline in functioning but was unable to detect a slowdown over several months. Just as the frog adapts to the water temperature, I unconsciously lowered my expectations of the computer’s performance.

Adjusting our expectations isn’t always bad, but if we’re going to change our goals, we should do so consciously. The key is to know what our objectives are and to track performance vis-à-vis these benchmarks. To that end, most manufacturing companies have mechanisms in place for monitoring adherence to quality standards. Organizations also tend to stay on top of financial and sales goals through routine reporting and analysis.

When it’s not practical to measure performance on a continual basis, as with my computer, then a regular check-up may be in order (see “Maintaining Performance Goals” on p. 8). Check-ups or maintenance programs use objective measures of a system’s performance to periodically diagnose problems that might not be apparent to someone on the inside. For instance, in a physical examination, a doctor checks blood pressure, weight, cholesterol, and other levels to ensure that they remain within healthy limits. Unless a person has a health problem that requires continual monitoring, such as diabetes or high blood pressure, checking these functions daily or weekly would be onerous—for most people, once a year is often enough. But if we put off seeing our physician for too long, changes that we’ve gradually adapted to—low-grade fatigue or a persistent cough— may compound to become health crises.

MAINTAINING PERFORMANCE GOALS

In certain systems, such as my computer, actual performance begins to fall short of desired performance over time (B1). We may not notice the shift, because our senses aren’t attuned to gradual changes, so we unconsciously lower our expectations of the systems’ performance. Rather than changing our standards, a more productive approach is to consciously be aware of this dynamic and to institute a regular check-up or maintenance process (B2). By doing so, we bring actual performance back up to speed and keep our goals on track.

Organizational Check-ups

How might we incorporate the idea of maintenance checks in an organizational setting? The goal is to cast light on changes that we may not perceive because they are so gradual while not becoming bogged down by burdensome reporting or monitoring tasks. This is especially true for areas that aren’t easy to measure, such as employee satisfaction, adherence to the corporate mission statement, or teamwork. In these cases, a maintenance process may be as simple as meeting with a partner every week to get an objective opinion of your progress on achieving a developmental goal or as complex as conducting quarterly employee surveys to evaluate morale.

Here are some ideas for making sure that performance stays steady over time:

• Identify variables that are important to organizational performance, especially those that aren’t usually on the radar scope, such as employee morale or use of productive conversation tools.
• Establish performance standards for these variables. Keep the standards visible.
• Track performance versus the standards.
• If it’s not possible or practical to track performance analytically, find a way to periodically collect input from an objective source—a learning partner, an outside coach or facilitator, a semi-annual employee survey. Experiment to find the right interval between “check-ups”—too often and you might find them more trouble than they are worth, too infrequent and problems might be on the verge of spinning out of control before you catch them.
• If you are tempted to shift a goal, be deliberate! Look into the causes and consequences of doing so before taking action.
• Learn from experience. If you’ve noticed unacceptable changes in a variable, design a maintenance program to keep it on track in the future.

If you follow these steps, you’re likely to keep your organization performing at high levels and avoid crashing the system or boiling the frog —things none of us want to do!

Janice Molloy is managing editor of The Systems Thinker and content director at Pegasus Communications, Inc.

The post Keeping Performance up to Speed appeared first on The Systems Thinker.

CLASHING GOALS

Quality and schedule sometimes conflict (B1 and B2 conflict with B4 and B5). The pressure to expedite a project increases the pressure to cut corners (B3) and lower the quality goal (B6). Over time, as the quality of our efforts declines, the quality goal declines, which reduces the gap. This leads to a further decrease in the quality of our efforts and a subsequent lowering of product quality (R7).

8:58, only to find that you are the first one there. You check your calendar to make sure that you have the right date, time, and place. Yep, you do. Around 9:05, some of your coworkers show up, and by 9:10, everyone has arrived for the “9 o’clock” meeting. So, what do you learn from this experience? Probably the same thing the others have already learned—that the, “real” starting time for meetings is never the stated time. This is a common example of the “Drifting Goals” archetypal structure.

Down the Slippery Slope

Many of us have had experiences similar to the one described above. As a group, we commit to a certain meeting time or project deadline with every intention of fulfilling that promise. Nevertheless, “life” intervenes in the form of traffic jams, more pressing deadlines, and urgent phone calls so we relax our standards around keeping the commitment. We think to ourselves, “The rest of the group is bound to be late, so I’ll spend one more minute polishing this presentation” or “Waiting an extra day for the new release won’t kill our customers!” We say 9:00 a.m., but, through our own tardiness or lack of reaction when others arrive late, we tacitly accept that it’s O. K. to begin the meeting no later than 9:05. Well, maybe 9:10, but we absolutely should start by 9:15. So, why don’t we just schedule the meeting for 9:15? Because then it’s likely to start at 9:30! This dynamic reminds us of the old adage “give him an inch, and he’ll take a mile.” It seems that once we compromise a little, we are headed down a slippery slope with no bottom in sight.

One obvious solution to drifting meeting times would be to establish accompany wide norm that meetings must begin as scheduled no matter what. Many groups have experimented with different incentives (or more accurately, disincentives) to encourage people to arrive on time ranging from monetary penalties to singing a song for being late with mixed results. For numerous organizations, though, delayed meetings are just a surface manifestation of a larger and potentially more serious pattern of drifting goals.

The Danger in Deadlines

Perhaps with things like meetings, it’s not such a big deal if everyone translates 9:00 to mean 9:15. The problem with such habits is that they have away of spreading to other areas, such as quality standards, new product launches, and marketing campaigns.

The danger lies in the tendency for all goals to drift, depending on the forces that are operating at the moment. In other words, we want a quality of 10, but when time is tight, we will settle for 9.5. If we are even more pressed,9.3 will do. And on it goes.

Some standards are more important to maintain than others. For example, new product launches generally need to stay on schedule so the company can fulfill advanced sales. But more often than not, deadlines beg into slip, often because people are juggling multiple demands. When this happens, the project manager has at least two choices about how to address the gap between the desired and actual deadline (see “Clashing Goals”). One way is to simply delay the launch date(B1), which is not an acceptable alter-native in most cases. Another way is to increase the amount of effort or resources devoted to the project so that progress can be made faster and the launch date can be met (B2). If management makes it clear that the deadline must be maintained at all costs, then this second scenario will likely occur. But if the organization doesn’t allocate the resources needed to expedite the project, people in the system must find other ways to reach the goal. One solution is to reduce the quality of efforts on the project; that is, to cut corners, which will lower the time required to produce the end-product (B3).

In some cases, taking such a shortcut makes sense in order to get acritical product out on time, even though the quality may not be up to our usual standards. The problem with this approach is that it rarely remains an isolated event, but rather becomes apart of the way we do things. The next time we get into a time bind, we may “cheat” a little on quality again because it worked the last time. So by setting rigid deadlines in isolation of other factors, we can actually create undesirable long-term outcomes, such as lower-quality products.

Competing Goals

The “Drifting Goals” phenomenon occurs more often when we are juggling competing objectives than when we are trying to meet a single target. Ideally, we would like to produce a high-quality product on schedule every time, but what happens when these two requirements seem to conflict (when B1and B2 conflict with B4 and B5)? In “Clashing Goals,” we see that the pressure to expedite a project does two things. It increases the pressure to lower the quality goal (B6)and it lessens the quality of the efforts that we can put forth. Over time, this decline in quality of efforts also has a negative effect on the quality goal itself, which creates a dangerous reinforcing dynamic. Specifically, as the quality of our efforts declines, the quality goal declines, which reduces the gap. This leads to a further decrease in the quality of our effort sand a subsequent lowering of product quality (R7).

The figure “Drifting Goals over Time” shows the long-term dynamics of this structure at work. The quality goal appears to stay stable for periods of time and drops slowly relative to the wider swings of the actual quality of efforts. This dynamic serves to mask the long-term downward trend, which is why this archetype is often referred to as the “Boiled Frog Syndrome.” The changes in the goal are slow enough that nobody detects the dangerous trend until the company is in serious, “hot water.

Identifying Interdependent Goals

DRIFTING GOALS OVER TIME

The quality goal appears to stay stable for periods of time and drops slowly relative to the wider swings of the actual quality of efforts. This dynamic serves to mask the long-term downward trend.

Returning to our original example, people in organizations constantly juggle the competing goals of getting to meetings on time and attending to a whole slew of tasks they need to accomplish. One leverage point would be to emphasize the importance of actually starting as scheduled and to ask what it would take for everyone to keep that commitment. We may discover that 9 a.m. is not the best time to accomplish this goal because there are too many other competing variables—traffic, urgent messages to return, and problems to troubleshoot. It may be that gathering at lunch time will make the goal more achievable, especially if lunch is provided! Lunch or no lunch, the principle is to establish the importance of meeting a specific goal in the context of multiple goals, and then to set up structures to minimize the conflicts between competing demands and priorities.

The post Drifting Goals: The Challenge of Conflicting Priorities appeared first on The Systems Thinker.

A Starting Point for Theory-Building

Quality pioneer Dr. Edwards Deming once said, “No theory, no learning.” In order to make sense of our experience of the world, we must be able to relate that experience to some coherent explanatory story. Without a working theory, we have no means to integrate our differing experiences into a common picture. In the absence of full knowledge about a system, we must create a theory about what we don’t know, based on what we currently do know.

Each systems archetype embodies a particular theory about dynamic behavior that can serve as a starting point for selecting and formulating raw data into a coherent set of interrelationships. Once those relationships are made explicit and precise, the “theory” of the archetype can then further guide us in our data-gathering process to test the causal relationships through direct observation, data analysis, or group deliberation.

Each systems archetype also offers prescriptions for effective action. When we recognize a specific archetype at work, we can use the theory of that archetype to begin exploring that particular system or problem and work toward an intervention.

For example, if we are looking at a potential “Limits to Success” situation, the theory of that archetype suggests eliminating the potential balancing processes that are constraining growth, rather than pushing harder on the growth processes. Similarly, the “Shifting the Burden” theory warns against the possibility of a short-term fix becoming entrenched as an addictive pattern (see “Archetypes as Dynamic Theories” on pp. 9–10 for a list of each archetype and its corresponding theory).

Systems archetypes thus provide a good starting theory from which we can develop further insights into the nature of a particular system. The diagram that results from working with an archetype should not be viewed as the “truth,” however, but rather a good working model of what we know at any point in time. As an illustration, let’s look at how the “Success to the Successful” archetype can be used to create a working theory of an issue of technology transfer.

, “Success to the Successful” Example

An information systems (IS) group inside a large organization was having problems introducing a new email system to enhance company communications. Although the new system was much more efficient and reliable, very few people in the company were willing to switch from their existing email systems. The situation sounded like a “Success to the Successful” structure, so the group chose that archetype as its starting point.

'SUCCESS TO SUCCESSFUL' EMAIL

Starting with the “Success to the Successful” storyline (top), the IS team created a core dynamic theory linking the success of the old email systems with the success of the new system (middle). They then identified structural interventions they could make to use the success of the old systems to fuel the acceptance of the new one (loops B5 and B6, bottom).

The theory of this archetype (see “‘Success to the Successful’ Email” on p. 8) is that if one person, group, or idea (, “A”) is given more attention, resources, time, or practice than an alternative (, “B”), A will have a higher likelihood of succeeding than B (assuming that the two are more or less equal). The reason is that the initial success of A justifies devoting more of whatever is needed to keep A successful, usually at the expense of B (loop R1). As B gets fewer resources, B’s success continues to diminish, which further justifies allocating more resources to A (loop R2). The predicted outcome of this structure is that A will succeed and B will most likely fail.

When the IS team members mapped out their issue into this archetype, their experience corroborated the relationships identified in the loops (see “Core Dynamic Theory”). The archetype helped paint a common picture of the larger “elephant” that the group was dealing with, and clearly stated the problem: given that the existing email systems had such a head start in this structure, the attempts to convince people to use the new system were likely to fail.

Furthermore, the more time that passed, the harder it would be to ever shift from the existing systems to the new one.

Using the “Core Dynamic Theory” diagram as a common starting point, group members then explored how to use the success of the existing system to somehow drive the success of the new one (see “Extended Dynamic Theory”). They hypothesized that creating a link between “Usefulness of Existing Email” and “Usefulness of New Email” (loop B5) and/or a link between “Use of Existing Email” and “Usefulness of New Email” (loop B6) could create counterbalancing forces that would fuel the success loop of the new system. Their challenge thus became to find ways in which the current system could be used to help people appreciate the utility of the new system, rather than just trying to change their perceptions by pointing out the limitations of the existing system.

Managers As Researchers and Theory Builders

Total Quality tools such as statistical process control, Pareto charts, and check sheets enable frontline workers to become much more systematic in their problem solving and learning. With these tools, they become researchers and theory builders of their own production process, gaining insight into how the current systems work.

Similarly, systems archetypes can enable managers to become theory builders of the policy- and decision-making processes in their organizations, exploring why the systems behave the way they do. As the IS story illustrates, these archetypes can be used to create rich frameworks for continually testing strategies, policies, and decisions that then inform managers of improvements in the organization. Rather than simply applying generic theories and frameworks like Band-Aids on a company’s own specific issues, managers must take the best of the new ideas available and then build a workable theory for their own organization. Through an ongoing process of theory building, managers can develop an intuitive knowledge of why their organizations work the way they do, leading to more effective, coordinated action.

ARCHETYPES AS DYNAMIC THEORIES

Limits to success dynamic theory

The post Systems Archetypes as Dynamic Theories appeared first on The Systems Thinker.