Product Development Archives

Product Development Page 20

Today we continue our discussion about System Archetypes with an archetype known as “Accidental Adversaries.” This system starts with two partners working to cooperate, but it leads to a negative outcome. The cooperation comes from each partner filling a need of the other. But, once the cooperation or system is put in place, each of them looks to individually optimize their part of the operation — a local optimization. This local optimization has unintended negative consequences for the partner. As each partner feels the negative consequence of what the other is doing, feelings erode, the partnership dissolves, and both sides feel the other side is inconsiderate and taking advantage of them.

The classic example used to highlight Accidental Adversaries is that of Walmart and Proctor & Gamble. Walmart needed product for their shelves and P&G needed distribution for their products. So the two companies cooperated. Once the cooperation was in place P&G tried to improve their position by running a lot of specials and sales. This created extra work and costs for Walmart. Walmart tried to recover those costs by buying extra quantities of the discounted product, stockpiling, and then burning through their inventory after the prices went up — selling them at full price to make extra profit and recover the burden put on them by the sales themselves. Proctor & Gamble then started running more sales to move more product and make up for the loss, and this turned into a cycle. Both sides felt the other side was operating against their interest and this cooperative venture became an adversarial relationship.

We see something similar happening in our organizations. Let’s use the relationship between marketing and engineering as an example. Marketing needs some organization to realize their vision and design. Engineering needs someone to come up with a vision and awareness of what the market needs in order to execute and do their work. As marketing learns, deep into a development project, some new information, they will try feeding it into a project. This is often called scope creep. Engineering will try their best to fulfill the new requirement. However, it may cause a problem for engineering. It may cause a project to be late. So, engineering puts in place some rigid rule like a spec freeze. Marketing, losing the flexibility of the process, will amp up its early requirements and put in stretch goals instead real goals. The idea being that if engineering can meet the stretch goals, then the product will still be strongly competitive in the market place. This cycle repeats itself and marketing and engineering find them selves in an adversarial relationship.

The antidote for this archetype is dialogue — continuing dialogue about the cooperation throughout the entire life of the system. Dialogue can’t end once the initial system in place. There needs to be ongoing dialogue between marketing and engineering. This is part of the design of the interface between the two groups. To come full circle, design of the interface is one of the key elements of systems and systems thinking…the topic that we’re heavily focused on in this series.

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. 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.

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.