Product Development Operating System Archives

Product Development Operating System Page 3

We’ve been talking about System Archetypes. These are the types of systems that recur in a number of environments and are easily recognizable. The system archetype we’re going to talk about today is called Eroding Goals. Eroding goals are caused by a delay in the results of the actions we take to improve something. If you recall, systems operate on feedback — positive and negative feedback — and delays in the cause and effect cycles between elements of the system.

So in eroding goals you start with some condition and an ambition to improve it. There is some gap between your condition and the goal. This gap causes a dynamic tension. Senge represents it well in his book, The Fifth Discipline, by showing a hand stretching a rubber band. The tension of that rubber band pulls up on the condition, but with the same force it puts pressure to pull down the goal. You have two possible results. You can either take action that will move the condition towards the goal or you can soften the goal and pull it down closer to your condition.

What happens in eroding goals is you start by taking positive action, doing the right thing, but there is a time delay between the activity you take and seeing the positive results of the action you take. This time delay, this lack of positive reinforcement of your action, causes a loss of commitment to the work you’re doing. To relieve the pressure you lower your goals to reduce the dynamic tension that’s in play.

An example of this might be if your company releases three new products each year and there’s a goal to increase this number to six. This goal drives increased investment as the company moves towards increasing the capacity and capability to release six new products. But there is a delay in the positive results from the actions taken to increase capacity. This lack of results causes those making the investment to lose confidence and commitment to the initiative. So, to avoid making increased investments — in their minds eye perhaps throwing good money after bad — they lower their goals from six to four; an incremental increase instead of a dramatic increase.

The antidote to eroding goals is simply setting good goals. The setting of good goals comes from a process called learning first. Study your situation; study the distance between your condition and your goal. Then make goals that are achievable. This ties directly to learning first, learning cycles, and the EAC promoted LAMDA learning tool. If you’re not familiar with the LAMDA learning tool, I suggest you look into it. One way of doing so is to contact EAC.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive. Follow Bill at http://www.twitter.com/systhinking

We’ve been talking about system archetypes and will focus on that topic again in this post. We’re going to look at the system archetype called “Shifting the Burden.” First, a little review. A system archetype is a system that recurs over and over in many different settings and industries.

Shifting the Burden centers around shifting the burden from solving a problem to solving a symptom. It starts with the awareness of a problem. The awareness comes from the observation of some symptom of that problem. At the point of observation you have a choice. You can either choose to put out the fire and resolve the symptom, or you can do a more protracted problem solving exercise and get to the root-cause and solve the problem. Under the time constraints of modern business we oftentimes choose the former and put out the fire. We measure success using the fact that the symptom goes away and we can get back to our urgent regular work.

Shifting the burden from solving a problem to solving a symptom results in an addiction cycle. We treat the symptom and, because we haven’t solved the problem, the problem recurs as a fire. As we rely more on solving symptoms instead of problems, more and more fires recur and we find ourselves in perpetual firefighting. As we are perpetually firefighting we have less time to spend on solving problems so we’re more inclined to solve symptoms. As we do this, our ability to actually root-cause problems and solve them at their root atrophies. It is a side affect of the addiction cycle.

For example, say you have a customer service group. Let’s say that over the course of the last three months the number of calls into the call center has increased by 25% and the customer service groups is suffering low morale because of it–long hours and hostile customers. The problem at this point really is unknown. No one has investigated it. It could be as simple as an unclear instruction manual for a new product that’s been released. But, in the interest in getting the call center morale problem resolved the company invests in capacity for the call center. With more people in the call center morale improves and the symptom goes away, but the underlying problem remains…probably to recur at some point in the near future.

The “Shifting the Burden” archetype has an antidote. The antidote is to recognize when you’re applying Band-Aids–to recognize when you’re just solving the symptom–and to follow up that with a deep root-cause problem solving exercise. Of course, to be able to do this, you need a competency and capability of solving root-cause problems. This could be PDCA or, as EAC promotes, the LAMDA learning cycle.

Today we are going to start talking about system archetypes and we’re going to deal with the easiest to understand — Escalation.

In escalation there are two players. Player one does something that is seen as a threat by player two and player two responds in kind by making a power move. Player one then perceives that power move as a threat, so they respond again in kind and do something that is perceived as a threat by player two. So it goes in a continuing pattern of “seen as threat…response > seen as threat…response” and the situation grows out of control. The situation escalates. It’s done through a series of power moves.

In an escalation system, both parties are operating from their mental models: a sense of righteousness. They believe they can’t give in. An example of escalation was seen in the 1980’s during the arms buildup between the United States and the Soviet Union. The Soviet Union would increase their nuclear arsenal and the U.S. would respond in kind and increase theirs. The U.S.’s increase was then seen as a threat to the Soviet Union who would then spend more money and increase theirs. Likewise we would respond in kind. On and on it went consuming critical national resources. Both countries locked into this system, unable to back down. Both were prisoners of the system. Eventually it led to bankruptcy of the Soviet Union and hyperinflation in the United States.

This kind of escalating system exists inside of our organizations. It exists between functional groups when one functional group takes an important position, but that position is seen as a threat to another group in the organization and they start escalating back and forth.

A trigger for an escalation can be simple. An example could be if your marketing group says they’ve learned something new about the market and need to introduce a new spec in the middle of a product development process. The engineering group might say, “We can’t! That change in spec will drive us back to square one. We can’t accommodate it and still be on time to market.” With these two righteous positions the interface between the two groups becomes a battle line. They go back and forth escalating, threatening and counter threatening each other.

If you find yourself in a system of escalation, how do you get out of it? If you’ve recognized the system, that’s terrific, but how do you find your way out of it. In the archetype of escalation the way out is through dialogue. Between countries, on the international scale, the term dialogue is referred to as diplomacy. Inside of your organization dialogue is referred to as inquiry – learning and asking questions to understand the underpinnings of your partner’s position. Peter Senge calls this advocacy (within your position) with inquiry (looking to understand the position of your partner). If you’re wondering how to avoid escalating situations by asking meaningful questions to get to the heart of a matter, I recommend you read a terrific book by Michael J. Marquardt called Leading with Questions. If you learn to lead with questions you will always be able to find yourself out of organizational situations that are escalating out of control.

In our discussions of systems thinking, there is a critical fact that we haven’t touched on yet — In order to be able to work with systems, you need to be able to recognize them. Systems Thinking is oriented to the long term view. Generally we get caught up in the hubbub of the day to day. It’s easy for us to miss the operation of the system. It is like the parable of the boiled frog. By the time they discover the increasing heat in the pot, it’s too late for them to escape.

Feedback and time delays are what structure a system and provide its enduring status quo. These operate over long periods of time. If we’re unaware of how a system operates, if we don’t learn to see the system, then we end up being prisoners of the system; buffeted around by the forces of the system.

If we learn to see the system, we can take advantage of the forces of the system. We can learn to recognize the leverage points in the system. This is valuable if you want to do something to affect change within the system.

In learning to see systems there is a huge aid that comes from recurring fundamental systems. There are certain systems that recur in all kinds of industries and disciplines. These generic structures have come to be known as System Archetypes. Peter Senge, one of the thought leaders we commonly reference, says that only when we learn to think in terms of System Archetypes can we really operate in a way that makes systems thinking an effective agency for management.

Between now and the end of the year we’re going to talk about System Archetypes, how to recognize them, and how they give you insight into the systems within which you operate on a day-to-day basis.

Today I’d like to follow up on the last couple of posts. We’ve been talking about systems thinking and knowledge management. If you can think back to the very beginning of this video series we talked about a framework, developed at EAC, for looking at product development as a system. We call it the Product Development Operating System. The foundation of this system is the Information Flow management system. The idea is to present information where it’s needed, in a timely way, inside of your operation.

As Thomas Davenport pointed out, pure technology is not enough. Your knowledge management system needs to include other elements like Obeya rooms or even face-to-face communication.

Information, when presented and encountered by a human mind, has the opportunity to be converted into new knowledge. This happens inside another subsystem of the Product Development Operating System, the Continuous Improvement subsystem. The learning that occurs in the Continuous Improvement subsystem is applied in the Workflow subsystem where learning about product or technology is applied as innovation inside of product development.

The design of a system of flow, the presentation of information and its conversion to knowledge through your knowledge worker environment is a key factor in increasing productivity. When you look at your product development operation, can you see it as a system? Do you understand how the various elements interoperate? Are you getting the results that you want or do you find yourself fighting fires?

Contact us if you cannot see your system as a system and understand where your points of leverage are. We can help. We have a service product called the Product Development System Assessment. It not only baselines your current state, but it also presents a series of recommended improvements to move your system towards a more systematic operation and a healthier state. Our assessment service is designed to get you back on the road to higher productivity in your product development environment.

In our last post we talked about three authors whose work give good insight into systems thinking. I want to thank everyone that commented on that post. I’m glad you appreciated it. If any of you don’t know how to reach us and want to provide feedback, you can reach us at info@eacpds.com, or you can message me on my Twitter account @systhinking, or you can simply leave a message below.

The positive feedback from the three books we recommended led us to do another recommendation. These books are on subjects of knowledge work, knowledge management, and knowledge workers themselves.

The first of three authors I would like to recommend is Peter Drucker — probably the most prolific business writer of the 21^st century. Just before his death Druker published his final book titled Management Challenges for the 21^st Century. He called the primary challenge of the 21^st century is increasing the productivity of knowledge workers. He has a chapter inside that book devoted specifically to that topic. Very easy and good reading; easily absorbed.

Druckers work is followed up by the work of Dan Pink who wrote the book Drive. Drive talks about motivation of the knowledge worker. He reinforces the believe of Deming and Drucker that the traditional carrot and stick motivators are not only ineffective for knowledge works, but they’re actually counter productive and cause a reduction in productivity.

The third author I’d like to recommend is Thomas Davenport. He’s really taken the baton from Peter Drucker in the elaboration of the motivation and management of knowledge workers. Davenport has two very good books. One is Thinking for a Living and the other is Working Knowledge. These two books very carefully layout what constitutes a knowledge worker and what constitutes knowledge work. He talks about the distinctions between data, information, and knowledge. He starts making the management of knowledge as a system very clear. In his books he also emphasizes the inclusion of humans in a knowledge management system. Knowledge management has been a stumbling block for most companies in the 21^st century. It’s because we address it with technology solutions alone. Davenport points out that pure technology is not enough — that knowledge exists within the minds of human beings and to move to a pure technology solution – and exclude human beings – is to move away from a real knowledge management system.

In conclusion, the environment for knowledge workers and the knowledge management system are both systems that require very careful systems design.

Follow Bill at http://www.twitter.com/systhinking